Dojo: The Definitive Guide

Dijit Lifecycle Methods

Let's now turn our attention to the central dijit lifecycle methods that _Widget provides. As you're about to see, _Widget packs a lot of power with only minimal effort required on your part. By simply including it as the primary superclass ancestor in the inheritance hierarchy, your subclass has immediate access to the standard dijit lifecycle methods it provides, and you may override any of these method stubs to produce custom behavior during the construction and destruction of the dijit.

For example, _Widget provides stubs to override before a dijit appears on screen, immediately after a dijit becomes visible, and when a dijit is just about to be destroyed. Each of these choke points can be immensely valuable times to synchronize with the server-side model, explicitly destroy objects (so as to avoid well-known memory leaks), or do some tactical DOM manipulation. Regardless of the particulars for each and every situation, this is boilerplate that you don't have to write; it's already in place, and you can use it if and when you need it.

To introduce what _Widget offers, Example 12-1 shows a simple class that defines a class inheriting from _Widget and overriding the key methods involved in construction and destruction to produce debugging messages in the Firebug console. As you know from the last chapter, this file would be named Foo.js, and would be located in a directory named after the module—nothing more than a class mapped to a namespace.

The key point ...