Tuesday, May 23rd, 2006

The Dojo Toolkit in Practice

Category: Articles, Dojo

We have posted a new article on using the Dojo Toolkit in a project.

The article discusses a piece of a project that uses Ajax to create a responsive itinerary viewer. The article was just updated for the latest Dojo 0.3 release.


When you start to build an Ajax application, you quickly run into situations where you feel like you are reinventing the wheel. The XMLHttpRequest object is what a lot of developers jump on when they think about Ajax, but that is just the start, and is the easy part.

There are lots of annoyances when you build JavaScript rich applications. Browser compatibility and degradation, messing with the DOM, and dealing with bleeding edge hacks such as offline storage all come up.

This article is going to introduce you to a toolkit that is much more than an XHR wrapper. It is the type of toolkit that everyone should be using if they are developing a rich Ajax application. Without it, you are a crippled developer.

Rather than listing out the APIs available in The Dojo Toolkit, we will look at a simple slice of an application, to see parts and pieces of the library in action.

We will discuss:

  • What this Dojo thing is?
  • Setting up Dojo
  • DOM and HTML Effects in practice
  • Ajax remote calls via dojo.io.bind()
  • Drag and Drop operations

View a nicer PDF Version of Article

Download Source Code

Posted by Dion Almaer at 3:05 pm

3.8 rating from 112 votes


Comments feed TrackBack URI

[…] The good folks over at Ajaxian have just posted a new article outlining how Dojo helped them through a project. […]

Pingback by dojo.foo » New Article: “The Dojo Toolkit In Practice” — May 23, 2006

Great Article, but if this Dojo framework is soo great, why do some people stil opt to not use it?
Perhaps just me, but I would like to see a little objectivity in this matter.
The article and this entry has that ‘Dojo 4 Life’ kinda feel to it.

Comment by Hans Duedal — May 23, 2006

In light of the previous comment, how does prototype compare with dojo?

Comment by Ken — May 23, 2006

Perhaps somebody should post an article on “Why won’t my HTML validate when using dojo?” Ya know for being such purists when it comes to javascript these guys don’t seem to give a dittly squat about HTML standards, and there is absolutely no reason for it.
Somewhere someday somebody will write a framework that combines the best of dojo and prototype!!!

Comment by Vance Dubberly — May 23, 2006

Hans: the same reason some ppl use Python instead of Ruby, or SWT instead of Swing in Java. It depends on personal preference, the task in front of you, your experience, your teammates, etc, etc. In other words, use the right tool for the right job in the right context.

Comment by Rob Sanheim — May 23, 2006


This article is not meant to be “use Dojo not Prototype”. We use Prototype and lots of other Ajax frameworks.

However, this came from part of a project that happened to use Dojo, and we wanted to share some info.



Comment by Dion Almaer — May 23, 2006

Vance: Dojo is a full toolkit. It provides tools to help do your work. It doesnt have to be looked at as a pre-packaged javascript app development solution. If you dont like the widget system (I assume its the configuration of widgets via custom attributes you’re objecting to), you are free to roll your own. Or just don’t use the parser, and instantiate your widgets directly through script. There’s lots of good reasons to choose one library/toolkit over another, but this isn’t really an issue here IMO.


Comment by Sam — May 23, 2006

It looks like in the example the tag is hard coded to file:///usr/local/lib/javascript/dojo/dojo-0.3/dojo.js when this should be scripts/dojo-0.3.js in case people are having trouble using the example.

Comment by Charlie — May 23, 2006

Nice to see more tutorials and articles about Dojo. :)

Comment by Gonzalo — May 23, 2006

The link to the PDF version in the XML feed is broken.

Comment by Kunal — May 24, 2006

I’m afraid that there are too many tutorials and articles about Dojo, scattered all over the net. Some of them are very intelligently written (articles listed on Dojo Documentation) but devoted to single aspect (BTW, they are not referred from new Dojo page), some of them only introductory, partial (like Manual “Dojo Reference Documentation” – listing mostly undocumented word), unfinished (DojoDotBook) or even vanishing (HelloWorld). There are a lot of brilliant and advanced articles scattered here and there, but there is no single coherent manual containing not mostly trivial samples or not mostly general philosophy or not mostly skeleton chapters. I’m bored of reading “Hi, we have (found, written) one more Dojo article”. With project of such maturity (1 year and a half!) and such wide range of designed applicability, I think I do not expect too much regarding documentation.
From many posts and blogs I’ve seen that Alex from Dojo is so puristic about JavaScript pollution made e.g. by Prototype (I agree with him). But in the same time he is so relaxed about polluting HTML with undocumented attributes in Dojo. It seems that I will not use any of these libraries, choosing e.g. MochiKit or JQuery instead. I’m afraid it is too risky to cooperate with even such brilliant programists like Sam or Alex if they do not care about standards regarding them embarassing. Yes, Dojo HTML can validate (with use of namespaces and class declarations), but Dojo templates (e.g. for widgets provided with the package) are written using non-standard attributes like dojoAttachPoint, dojoAttachEvent or even strange __doClobber__ (regarded as syntax error in some HTML editors). So whether you want or not, agree with Alex or not, when using Dojo you have to accept non-standard HTML (at least when using Dojo built-in widgets).

Comment by Krzysztof — May 24, 2006

To the oh-my-god-it-doesnt-validate comment: Calidation is only a tool, not a goal in itself. Using custom attributes is FINE and doesnt cause any concerns or incompatibilities as far as the browser-rendering goes. The concern is to make the HTML compatible in all browsers and dojo does a magnificent job and alot effort is put into it.

Comment by Andy — May 24, 2006

The article states

If XHR is not supported, Dojo can drop down to using a hidden iframe to get the remote call

Is this true? It appears that if ActiveX is turned off for IE Dojo just throws the error: XMLHTTP not available: Automation server can’t create object. How hard would it be to gracefully degrade to an iframe transport in this case instead of throwing the error?

Comment by John — May 25, 2006

The provided code doesn’t work. As someone pointed out, the js file is hardcoded. Secondly, the name of the js file is wrong. Another minor point, there are to html files, one with .2 version, one without…which one is the right one?

I appreciate articles such as these, but perhaps a little more care will keep newbies such as my self sane. I shouldn’t have to drop to my souped up firefox+venkman+firebug+webtools+superman+spiderman+hell-boy to try out examples from an intro article :)

Comment by falcon — May 25, 2006

Krzysztof: agreed that a more coherent, centralized doc approach woudl be helpful for many of the librarie we discuss, dojo and prototype included. its the standard open source problem – developers typically don’t want to write docs (and aren’t good at it, either), so the docs lag behind the code and are typically fragmented and incomplete.

People just need to step up and start consolidating things and updating old outdated docs, if needed. We have some books on the horizon that should also help the situation.

Comment by Rob Sanheim — May 25, 2006

[…] Webdesigner Lesefutter Die Macher des für alle Ajax-Wütigen unverzichtbaren Ajaxian-Blogs haben ein wunderbares PDF für den Einstieg in das Dojo-JavaScript-Toolkit zusammen- und online-gestellt. Erklärt wird die Dojo-Philosophie, sowie anhand eines beschaulichen Drag-n-Drop Web-Anwendung die dahinter werkelnde Technik. Selbst für Hype-Verschläfer verständlich. […]

Pingback by popnutten :: le blog plus cool :: Webdesigner Lesefutter — June 5, 2006

while i haven’t yet used dojo in the development of any real world apps, i have experimented with it and find it to be one of the most mature dhtml/ajax/javascript packages around. i also like many features of mochikit and jquery and prototype/scriptaculous, and have been working on an abstraction layer using dojo as a base package with the ability to integrate useful portions of these other ‘packages’ without clobbering the namespace and/or breaking any native functionality. overall, dojo seems to provide the best framework for implementing the functionality you need at the level you require, although i am not fully committed and do not expect to be until i have implemented a fully cross-browser real-world application using this framework.

i concur with john regarding the iframe transport. an iframe transport implementation which suitably mimics xmlhttp in cases when it is unavailable would be handy (as opposed to a dojo-dedicated method).

overall, seems to be really good stuff and very well written.

Comment by stefan — June 20, 2006

From what I can tell, Dojo does not (but really should) drop back to an alternative transport if XHR does not work. I would like to see it drop back to the specified alternative transport of my choice; I do not believe this is currently available as a feature.

On the otherhand, for my project, I simply switched out XHR with JSscriptIO (a cross-domain alternative transport offered with dojo.io) and it worked great in all cases, ActiveX or no. Solved my problem and I’m off to other things.

From what I could gather, and this is not definative, (but I did ask and received no reply to the alternative) dojo.io.iframe support at this time is limited or used primarily for file uploads and I did not see any other unit test cases that led me to believe otherwise, and I was not able to get the iframe transport to work for a simple GET (ala, JSRS). Those of us familiar with using JSRS will probably be disappointed with the current dojo iframe transport functionality, but as I mentioned first, the scriptIO transport worked flawlessly for me, and worked around the very real limitation of XHR; XHR ONLY WORKS WITH THE SAME SOURCE THE PUSHED THE ORIGINAL PAGE! Will not work with other servers on the same domain, as do iframes (limited only by the browser’s own security model).

So in my case, this was easily solved and actually enhanced by the fact that the scriptIO transport supports even cross-domain Ajax appliations.

Kudos to the Dojo team and community; Dojo absolutely stands out as the Open Source toolkit of choice for enterprise developers that need to support multiple browsers on multiple platforms, having a very broad set of widgets to choose from and a community of users that is growing exponentially every day.

Comment by Jeff Papineau — June 20, 2006

Unable to unzip the source code. Please post information as to how to get the source code

Comment by Rajkumar Vakkada — October 10, 2006

Leave a comment

You must be logged in to post a comment.