Going Dijit-al: Migrating to Dojo 0.9 from 0.4

I have been using Dojo for some aspects of a commercial product to avoid the ugliness of JSF. However, some of the less desirable aspects of Dojo 0.4 have been recently addressed in a huge refactor being called Dojo 0.9. In order to take advantage of the big improvements - cardinal among these being consistent look & feel from the Dijit (Dojo Widget) package - I need to migrate our existing Dojo-dependent code over to Dojo 0.9. Apparently this is a fairly simple undertaking, but I have more ambitious goals than simply porting the code so it works. Dojo 0.9 has formalized and cleaned up the whole dojo.data package and data binding in general.

I would very much like for our Dojo Widgets to take advantage of this. Unfortunately, as of now, the Ajax fetching of data is mixed into these widgets directly. On top of that the Dojo 0.9 Beta refactor does not have the Grid dijit implemented so my heavy use of FilteringTable would require some temporary hacks to get working. It is still in for the Dojo 0.9 release later this month. Given my dislike of hacks I will port what I can around the FilteringTable's and leave them as placeholders for the time being. It looks like widgetsInTemplate is not working either so I will need to manually construct sub-widgets in my templates.

On the upside Dojo 0.9 introduces the dijit.Declaration widget which allows in-page refactoring of common components. It is an in-place widget declaration that can be immediately used within the same page for template-only widgets. Some of the Dojo Widgets I created could probably be done this way, but most of them rely heavily on maintaining instance-like state. It is however, an excellent launching point for refactoring existing repetitive HTML into something like a "function" instead of having to leap directly into making a full-blown widget to achieve the same effect.

So far the refactoring process has been painful, but mainly because of the terribly naive design decisions I made in my first round of Dojo-based development. A healthy dose of data bindings to separate the data management from the presentation should make the widgets easier to understand.

Java Developer... Meet JavaScript

You've seen it around, it's been exhaulted as the saviour of web-based interaction, dragged through the mud as a security disaster suitable only for newbies and script-kiddies, and recently recast by some as the foundation of Web 2.0. It's none of the above, yet lends to all of them for good or ill.

Why am I posting this? I am posting it because I believe that the J2EE community has been unwilling to seriously adopt JavaScript as a foundational component of their development. With tools such as The Dojo Toolkit it is now possible for Java-centric developers such as myself to develop in JavaScript without our heads exploding with worry about global-scope collisions and undeclared dependencies. In fact, I'd wager that a Java developer who invests his Digg time instead on learning Dojo and by proxy JavaScript itself, will find Java less and less compelling as the power of closures, true Aspect-Oriented Programming, and literal object and regular expression syntax sinks in.

A simple example of JavaScript's powerful literal syntax: "CustNH".split(/(?=[A-Z])/) returns ["Cust","N","H"]. This is effectively a very concise CamelCase parser.

Imagine now that you are using this string to drive an Autocompleter such as the one from script.aculo.us. You can now do completion from CamelCase to search an API to give a result like CustomNavigationHandler (for those familiar with JavaServer Faces).

That's just a trivial example but it illustrates how concise JavaScript is. In my next post I will discuss why UI events are best handled by the client-side and explore the idea of using Dojo and a RESTful JSON Server to push the Controller and Template Rendering responsibilities to the client.

Conclusion: JavaScript is well worth the effort to learn.

See: A re-introduction to JavaScript on Mozilla's site for a cross-browser intro to JavaScript.