- The Book of Dojo
- Quick Installation
- Hello World
- Debugging Tutorial
- Introduction
- Part 1: Life With Dojo
- Part 2: Dijit
- Part 3: JavaScript With Dojo and Dijit
- Part 4: Testing, Tuning and Debugging
- Part 5: DojoX
- The Dojo Book, 0.4
The Widget Life-cycle
Submitted by samiam on Wed, 09/26/2007 - 18:52.
The lifecycle of a widget decribes the phases of its creation and destruction which you can hook into. Its useful to understand exactly what happens when. Whether you are sub-classing an existing widget, using dojo/method script blocks, or passing in method overrides to the constructor, these are your entry points for making a widget do what you want it to do.
Note: some aspects of the widget lifecycle have changed post the 0.9 release; please consult the 0.9 to 1.0 porting guide.
Widgets are classes, created with dojo.declare. All widgets inherit from dijit._Widget, and most get the _Templated mixin. That provides you the following extension points (methods) you can override and provide implementation for:
- constructor
- Your constructor method will be called before the parameters are mixed into the widget, and can be used to initialize arrays, etc.
- parameters are mixed into the widget instance
- This is when attributes in the markup (ex: <button iconClass=...>) are mixed in or, if you are instantiating directly, the properties object you passed into the constructor (ex: new dijit.form.Button({label: "hi"})). This step itself is not overridable, but you can play with the result in...
- postMixInProperties
- If you provide a postMixInProperties method for your widget, it will be invoked before rendering occurs, and before any dom nodes are created. If you need to add or change the instance's properties before the widget is rendered - this is the place to do it.
- buildRendering
- _Templated provides an implementation of buildRendering that most times will do what you need. The template is fetched/read, nodes created and events hooked up during buildRendering. If you dont mixin _Templated (and most OOTB dijits do) and want to handle rendering yourself (e.g. to really streamline a simple widget, or even use a different templating system) this is where you'd do it.
- postCreate
- This is typically the workhorse of a custom widget. The widget has been rendered (but note that sub-widgets in the containerNode have not!)
- startup
- If you need to be sure parsing and creation of any child widgets is complete, use startup.
- destroy
- Implement destroy if you have special tear-down work to do (the superclasses will take care of most of it for you; be sure to call this.inherited(arguments);)
In all cases its good practice to assume that you are overriding a method that may do something important in a class up the inheritance chain. So, call the superclass' method before or after your own code. E.g.
postCreate: function() {
// do my stuff, then...
this.inherited("postCreate", arguments);
}
// do my stuff, then...
this.inherited("postCreate", arguments);
}
- Printer-friendly version
- Login or register to post comments
- Unsubscribe post