Orange is my favorite color

I’ve been reading the Dojo-interest mailing list for about two weeks and this quandry, or some variation, has come up 5 times already:

I have a body onload and now Dojo doesn’t work!

In my application, I had some pages with body onLoad specified. Dojo, however, attaches itself behind the scenes to this for its internal initialization. If you provide your own explicit onload, you will break the Dojo startup (and vice versa?).

There are two ways you should attach a function to onload:

Use dojo.event.connect:
start = function() { // do some stuff };
dojo.event.connect(window, "onload", "start");

Or using dojo.addOnLoad:
start = function() { // do some stuff };
dojo.addOnLoad(start);

Note the differences in passing by name and passing by reference (lack of quotes around start in the second example). If you’re going to use Dojo, ditch your window.onload and body.onload and use Dojo.event.connect instead. Just wholesale replace your hardcoded onloads with the Dojo way and everything will jive.

The event system is relatively well documented in this article.

4 Comments

  1. Nathan Dintenfass said:

    on July 30, 2006 at 4:09 pm

    Is it just me, or do I hear a lot about battling javascript libraries of late? Seems like to do truly interesting things various libraries perform gymnastics of one kind or another, and there really isn’t a good way to deal with conflicts. “Hijacking” the onload event for the body is probably really “good” for dojo internals to make things automagical, but it’s not like having body onload events is some obscure thing for a web page to do — thus, to use dojo you could be in a world of hurt if you have lots of page-level-customized body onloads. Perhaps more importantly, what about the hapless developer who inherits your code and doesn’t understand the various nuances — in this case it seems you’d have to have a pretty deep understanding of what is going on to debug why adding a seemingly innocent body onload is suddenly breaking lots of stuff. Or, am I not seeing the big picture here?

  2. brian said:

    on August 1, 2006 at 8:15 am

    It’s true to some degree that in order to move to a library like Dojo that you need to sort of “accept it”. The good news is that the only real conflict that Dojo has (that I have come across so far) is with the onload where it is initialized.

    There are some other projects out there that have “LifeWith*” sites like Life With Qmail and Life With DJBDNS. I think Dojo would benefit from a similar site or even PHP-style annotated documentation.

    The amount of things that Dojo can do for you is really incredible. Every time I am thinking about “how should I do this?”, I run a search through the source or Google and sure enough, Dojo has something sweet already baked in like dojo.style.getOuterHeight() for retrieving the combined height of an element or dojo.lfx.highlight() to highlight and fade an element on screen.

    There hasn’t really been a comprehensive library like Dojo before (that I’m aware of) so it takes some time in order to get accustomed to fully leveraging it.

    So, no, I don’t think that you need to know too much. So long as you avoid the onload hijacking, the rest of it kind of falls into place. I am only sprinkling Dojo around my existing application but you do, in my opinion, need to adjust your thinking into embracing it to really make gains.

  3. Roland said:

    on August 4, 2006 at 3:26 pm

    I agree with Brian. I’ve built quite some large, rich client experience applications using the browser and javascript since 2000, and I’m used to building stuff from scratch.

    I used to build everything myself because existing libraries were really just to invasisve or not flexible enough. Lately I’ve been looking for alternatives and I checked out YUI and Dojo.

    Although YUI looks promising and has good documentation, it just lacks a lot of functionality I need, and it just is not flexible enough.

    Dojo on the other hand really seems very promising – the one thing that’s missing badly IMO is the documentation. But that’s growing rapidly, and i’m actually already confident enough the indeed make the choice to embrace Dojo, and put up with the onload stuff.

    Note however that the migration path from <body onload=”func()”> to dojo is really a nobrainer, (dojo.addOnLoad(func);). It should not take much effort to convert.

    Actually, most people that build pages with javascript widgets will probably’ve looked for a solution to initialize all their stuff without breaking the other initialization code – this is about as good as it gets, and Im thankful for dojo to offer a solution that works and remains extensible.

    Cheers,

    Roland

  4. Kaleb Walton said:

    on January 25, 2007 at 7:21 pm

    I’ve become a pretty strong proponent of YUI and YUI-EXT. Since Dojo is contributed by so many individuals it’s challenging for them to maintain consistency across their widgets and API. If you’re comparing and contrasting some of the frameworks out there you may find one of my recent blog posts of interest.

{ RSS feed for comments on this post}