HTML-based Widgets | Why Dojo?

What makes a good web application framework?

Rapid database prototyping, rich extensibility, support for SOA? Not for me (well I am partial to database prototyping, you have me there). I look primarily for a framework that makes it easy to quickly build ad-hoc screens and then easily refactor generally useful pieces of these into reusable widgets. To these ends my colleagues chose Apache's JSF (JavaServer Faces) implementation, MyFaces, prior to my joining the company. Based on my research they made an exceptional choice for building ad-hoc screens since MyFaces Tomahawk provides a good set of widgets (which JSF calls Components) which make it easier to write tidy JSPs.

However, since JSF Components are authored in Java (a procedural programming language) to generate primarily HTML (a declarative presentation language) you have two problems: template refactoring is non-trivial (JSP to Java is best and is still not cut-and-paste), and JSF components need to be recompiled to see changes (stalls quick tweaks by requiring context or server restart). This is before having to deal with further layers of "control" like the TLD which specifies which components actually exist and what attributes are legal (why is it that this cannot be specified in the Java source of the component). Bottom line, JSF promotes DRY (Don't Repeat Yourself) development, but makes it challenging to manage by distributing the authoritative sources of various rules across many Java and XML files.

If there were an easy way in JavaScript to use HTML as a template language I could easily refactor parts of pages written in HTML (my prototyping language of choice) into reusable widgets and never need to recompile to see changes. I set to researching a way to do components using HTML templates. I looked at many popular JavaScript libraries like Mootools, script.aculo.us, and MochiKit. I also looked at server-side frameworks like The Django Project and Ruby on Rails whose components can easily be written using the primary template language and be changed without server restarts. Those JavaScript toolkits all lacked the notion of UI components. They focussed instead on adding client-side flash like effects and autocompletion to existing pages. An admirable goal, but not what I was looking for. Django and Rails both made template refactoring relatively easy, but I found Rails partials easier to author than Django tags. Other aspects of template refactoring like common base layouts were clear wins for Django as was its insistence on not allowing arbitrary code in the template. However, they both lacked JSF's clean separation of logic and presentation.

Then I found Dojo, which solved all my problems. The Dojo Toolkit has an HTML+CSS -based template-driven Widget system. It puts logic in JavaScript-based widget objects and presentation in HTML and CSS. All I need to do is take the snippets I like from my prototype, make widgets of them, and replace them in the prototype with references to the widgets created. That much is manifestly obvious and no different from any other framework available. Dojo differs in the ease with which this refactoring is performed:

Example directory structure with page.html as the refactored prototype:
project:
    page.html
    scripts:
        dojo:
            dojo.js
            [...]
        custom:
            manifest.js
            widget:
                BlogPost.js
                [...]
            templates:
                BlogPost.html
                BlogPost.css
                [...]
Example template for BlogPost (custom/templates/BlogPost.html):
Example widget source for BlogPost (custom/widget/BlogPost.js:
Manifest file to link widget names to modules:
Example usage of BlogPost widget in page.html:

What do we get for all that work?

That's not really a lot of messing around and you get a pretty clean BlogPost widget out of the mix. We have a dojoAttachPoint called containerNode to support the isContainer property. This is also available to custom.widget.BlogPost as this.containerNode. If you wanted to you could call the JavaScript version of Textile to generate the HTML representation of Textile supplied in the tag body.

Any other common patterns in your site can be refactored and even improved in this way. New approaches to interaction and modularity can be discovered in the process, as demonstrated with the possibility of Textiling the tag body to provide even simpler markup and support for styling verbose content.

How do Dojo Widgets work (in short)?

The presentation files are linked very explicitly to the widget JS through templatePath and templateCssPath. When a page is loaded the Dojo parser scans the DOM for elements with a dojoType attribute. Any of those found trigger a lookup of the appropriate Widget JS. If the Widget is not already loaded into the runtime it is fetched using Ajax. The Widget JS triggers a request for the HTML and CSS template files (which are likely cached if the user has encountered this widget before). In short, you load dojo.js in the head of your page and let it do the rest. No other work required if you are using the existing library of Dojo Widgets.

Oh, and by the way, Dojo effectively makes server-side templating unnecessary so you can static host the entire presentation tier of your application and gain some potentially large bandwidth benefits.