Matt Prokes

[digg=http://digg.com/programming/Why_I_am_on_the_fence_about_jbind_for_jquery] DEJA VU?!?! doesn’t the dom already do this?

So then why are we doing this modeling in jbind?

The history, I was recently introduced to a tool for binding data to a markup template called jbind. While in theory its not a bad idea I get this weird feeling we shouldn’t be using it, ESPECIALLY if you are using jQuery and even more funny its a jQuery plugin .

So let me explain the reasoning for this feeling, in html we have these neat things called classes. Classes allow you to effectivly “tag” markup as being a “grouping” of data. From there you simply just execute a property selector query and wala you got your data. Its very nice from a WYSIWYG perspective. Now jbind is mainly for automatic binding of data to a templated record set, and then the syntactical niceness is created around each record upon population.

That is great and all, except there is a requirement to generate a type of in-script model-view combo. jBind functionality can be effectivly implemented without the requirement of the library if perhaps a bit better judgement is used during the creation of the webapplicaton.

So to prove my point, lets give an example of what jbind would be best applied. A tableset of data.

This effectively says create a parent div, create 2 children, and inject the value of blah and cool into those children. What happens is jbind will runs through all nodes, and identify where to put data. While this is great if you are doing nothing with the data and the nodes that you are binding, it sucks for all other cases.

This is because you need to create a sort of “event callback” if you need to do more to the node upon the data injection, and then do even more work just to pull the data back out again, modify it. We are not even talking about adding events to the dynamically created nodes, which also will require more work.

What if we did this:

What happens here is you var x = $(‘.parent:first’).clone(), and inject the data into the template like this, x.children(‘.blah’).text(value); and x.children(‘.cool’).text(value);

Finally appending it to $(‘.parent:first’).parent.append(x);

This is nice because you do not need event callbacks on node creation; the data manipulation, as well as binding of events to the created nodes can happen on the clone as always. You also have html that has classes on it, and can later be queried for further manipulation, or just seeing what data is within that scope. The idea from what I percieve as far as jbind goes is to remove the need for classes, why, I don’t know classes are great.

So to conclude, I am not saying jBind is bad really, it is more efficient if you want to spit some json data out in the wild without doing anything extra. Prototyping for instance may be served well with this solution. Though I would argue that if you are not doing anything other then that, then maybe you shouldn’t be doing your stuff in js in the first place and maybe just do it through the back end. On the other hand, if you are going to need to modify the data, add events to dynamically created nodes, etc..

Then it is likely jbind will not be for you, and will just end up being more work then it is worth, since dom has a solution to this that is already pretty good, and much lighter and flexible then anything jbind is offering at the moment in many respects.

Posted in Javascript | No Comments »

For those that do not yet know, I work for internet broadcasting. An awesome company out in st. paul, minnesota. While working on some very large scale webapps, an annoyance came to light. Namely coding in styling directly to your webapplication.

Why is this a big no-no?

Well when css came out the big great thing about it is that people had their own language to specify, and seperate look and feel configurations, as well as the ability to take action on specific events like hover. This was a great idea simply because all this data was configuration and NOT code. Also it allowed people like designers to have a single point to go to if they wanted to make a red box green.

CSS was and still is great. So what happened?

DHTML happened. While a great idea dhtml put styling back into code (namely javascript), and css never adapted for this change. Stuff like webanimations started happening and there was no way to put that into css because css isn’t extensible in that way. So what did we as developers do? Well the only thing we could, we tried to put as much in css, and all the dynamic stuff got crammed into code!

But I have a solution for those of you that work on large scale webapps.

Introducing CSSPlusPlus.js!

What is it?: CSSPlusPlus.js allows you to in-a-way extend CSS through custom pseudo classes and property’s!
- Allowing for you to cram all sorts of configuration information, animation info and styling into one easy to use location. Think spring (sorta) for webapplications.

Ok Enough Talk Lets Roll To A Useful Example.

First you need to go out and get CSSPlusPlus.js, its under the MIT license so no worries.
You can find it here: http://www.webactivelabs.com/js/CSSPlusPlus.js

I know the namespace is pretty generic, feel free to rename it if you need to. Anyway Lets start off by creating a simple webapplication for creating boxes. I will also be using jquery for this example to show a practical use, in animation.

What it would look like:
BoxCreator.html
BoxCreator.js

Excellent, humm, if we investigate the box creator you will notice that I have coded in an animation height and width to expand out to, as well as some coloring information, and even a error message.

Humm thats alot of domain specific data coded directly in, what if this was a large scale application, how would we find this in the future? Surfing the code? Find? There must be a better way. Well lets start off by taking out all width and height information. For boxes.

What it would look like:
BoxCreator.html
BoxCreator.js

//Add a pseudo class to listen for!
CSS.addPseudoClassListener(‘boxcreator’,createBoxStyle);

BoxCreatorConfig.css.js

//The CSS parser at work for a custom pseudo-class :boxcreator
CSS.parse(‘.box:boxcreator {height:30px; width:400px; color:purple;}’);

Mmmmm, thats much better, humm.. but we still have some error messages. Lets say that we have a large amount of error messages that we want to keep track of, or we just other configuration data. Humm what if the designers do not like the wording of the messages? Well lets pull those out to, and send the designers the file and go have some coffee.

What it would look like:
BoxCreator.js

BoxCreatorConfig.css.js

//Any number of rules can be defined in a single parse.
CSS.parse(
‘.box:boxcreator {height:30px; width:400px; color:purple;amount:5;}’,
‘*:error{error123:crazy beefy cow!;}’
);

Alright, time to show the company the wonderful box creator that we made, lets go out and take a look at it.

BoxCreator.html

Thats all there is to it!

Whats actually happening here? I am not advocating that you dump all of your css into this tool, though styles that you do not listen for actually flow through the system and get spit out as an inline style tag. The custom css that you are defining is NOT actually real css, its just recognized by a simple glorified css parser that looks for property’s and pseudo classes. In a way it is similar to a sax parser, only for css instead. There is no magic, more like cloak and dagger.

If its a pseudo class listener:
The entire property’s list gets turned into json object and sent to the callback, as well as the selector that was defined for that pseudo class.

If its a property listener:
Just that property gets sent to the callback along with the selector, the rest of the property’s not being listened on get sent to a inline style tag, as standard css.

The Good:
Its just a glorified parser, but the designers won’t know the difference, and its efficient (I am all for tricking designers). Infact if you define custom css and do not listen for it, then it will flow through the system and get spit out in the style tags and the browser simply won’t do anything with that css. Many of you will say whats the point of this, I can create property files right now as a json object.

Yet that will require designers to learn a new language, as well as possibly breaking your app by coding native js. Also the syntax and the readability of this method is superior to that of a json property file in the context of applying a custom css action. Lastly, the pseudo class can be used on any selector, its not a one shot deal.

Example:
#button1:fadeButton {fade-to:green;}
#button2:fadeButton {fade-to:red;}

This method could also be used to fix things like hover, without hacking like crazy. Its in javascript.. but if you are designing a webapp, then that webapp is in javascript anyway. Plus you can be sure you won’t need to find the next greatest css hack when vendors decided to release the next greatest and latest. I advocate coding as much as you feel certain will be supported now, and in the future in css. Then maybe keeping your life simple, and using the parser for the rest .

The Bad:
There is a very small amount of parsing happening, I emphasize small. If you compare the amount of processing used for this method of specifying property’s; I would compare it to 1/1000th of the processing required to cause a animation to happen in the browser, and it only happens once. For those of you that are speed demons, and have to squeeze every last bit of performance out of your code then this might not be the solution for you. But in my case its a perfect fit. Secondly,

I wouldn’t on a regular basis define standard css through this interface unless you know what you are doing, or the definitions are placed in the document head. The reasoning is that your styling won’t be placed in the document until the script loads keep in mind. So IF you place your script tag AFTER your html structure, you will see the action of the standard css being applied to that structure once the js is loaded, which again is AFTER the html structure is displayed.

Anyway, use it at your own discretion, and have fun.

Your Friendly Developer,
~Matt Prokes

Posted in Javascript | 3 Comments »