Article: Using Dojo to React to Page Load and Unload

jminatel · January 31st, 2009, 02:57 PM

This article is exerpted from chapter 3 "Handling Events" of the Wrox book The Concise Guide to Dojo by Leslie Michael Orchard and is reused by permission of the publisher. This may not be reused without publisher permission.
Reacting to Page Load and Unload

Reacting to the successful load and unload of a page are two basic event hooks that are the most convenient in setting up and tearing down a user interface. Dojo offers two methods to allow registration of handlers on these events, named dojo.addOnLoad() and dojo.addOnUnload(), used like so:

javascript Code:

dojo.addOnLoad(function() {
console.log("** Inline onload handler fired!");
});
 
dojo.addOnUnload(function() {
alert("** Inline onunload handler fired!");
});

If you havenât before, now would be a good time to install Firebug (http://getfirebug.com) - or for all other browsers, ensure that isDebug is set to true in your djConfig. This will ensure that you see the output of these console.log() statements, which are used throughout this chapter to illustrate some of the less visible aspects of Dojoâs event handling.
Each of the inline anonymous functions in the preceding code will be called when the page loads up and is navigated away from, respectively. Using console.log() in the page load handler will cause a message to appear either in your Firebug log, or in the on-page debug log supplied by the version of Firebug Lite that comes with Dojo.
The page unload handler opts for an alert(), because it temporarily interrupts the transition to the next pageâa console.log() statementâs output would be lost before you could see it as the browser loads the next page. Once you understand how this works, you may want to comment out this alert(), mainly because it makes each page reload a bit tedious as you play with the code.
Another way to register handlers for page load and unload is to use object methods, like this:

javascript Code:

dojo.declare('decafbad.eventsanim.events.pageHandlers', null, {
handleOnLoad: function() {
// this == handlers
console.log("** Object onload handler fired!");
},
handleOnUnload: function() {
// this == handlers
//alert("** Object onunload handler fired!");
console.log("** Object onunload handler fired!");
}
});
var handlers = new decafbad.eventsanim.events.pageHandlers();
 
dojo.addOnLoad(handlers, 'handleOnLoad');
dojo.addOnUnload(handlers, 'handleOnUnload');

Note that in this case, the context for this within these functions is automatically set to a reference to handlers, thus keeping them in their original object context.

The window.onload Problem

Something very interesting about dojo.addOnLoad() is that it fires registered handlers after the successful load of the DOM, Dojo, and its initial batch of dojo.require() statementsâbut before all the CSS and images included on the page have loaded in.
This is important, because a simple window.onload handler fires after every referenced asset on the page has arrived.
The distinction is useful, because it allows you to get page initialization done earlier. Widgets can be constructed, events wired up, and page changes applied before more visual styling takes effectâthus hopefully preempting any confusing flashes of content or other ugly intermediate setup artifacts that appear while long-loading images roll in.
The other thing worth reinforcing is that dojo.addOnLoad() fires after Dojo has loaded.
This is important because Dojo may still be finishing up some loading tasks even after the native window.onload event has fired. Dojo may still be working on resolving a few last remaining dojo.require() statements, or any number of other things. For this reason dojo.addOnLoad() is really a replacement for window.onload in the Dojo context.