Lifecycle of The Dojo Widget Events

The document summarizes the lifecycle of Dojo widget events in 3 sentences: 1) The constructor is called before any HTML attributes or properties are passed to initialize instance variables, but widgets are not yet created. 2) PostMixInProperties is called after properties are mixed in, before rendering, allowing logic to alter rendering. 3) startup is called last after child widgets render, allowing container widgets to finish post-rendering like setting child sizes.

Uploaded by

rkadiamzenithcad

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOC, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

174 views3 pages

Lifecycle of The Dojo Widget Events

Uploaded by

rkadiamzenithcad

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOC, PDF, TXT or read online on Scribd

You are on page 1/ 3

Lifecycle of the Dojo widget events

I was recently developing yet another dojo widget and wanted to quickly post a short writeup of the life cycle of the dojo widget as described in Dojo documentation. http://docs.dojocampus.org/dijit/_Widget So here we go: constructor: constructor is called before any HTML attribute passed on the html definition or any property given during construction of the widget is passed to the variables on the object. This method could be used to initialize any local / instance variables. Widgets were not created at this time so don't try to execute any widget logic, thought you can still lookup the dom node and set any dom node specific attributes - pre initialization. parameters are mixed into the widget instance: if your widget has an instance variable: e.g. dojo.declare("widget.MyWidget", [dijit._Widget], { // instance variable cssClass: false }); it will be set if: 1. The HTML provided has the same attribute: <div cssclass="..."/> 2. During explicit, programmatic creation of the widget the parameters passed to constructor contain the same parameter name: var widget = new widget.MyWidget({cssClass:'test'}); postMixInProperties: The method will be called after the properties were mixed in. This method is called before any rendering takes place (this does not correspond to standard Dom rendering, so if you are using div with dojoType your div will be rendered but all the templating and additional nodes will not be created yet). Thus, if you need to add some specific logic to alter the rendering this is the place to add code. buildRendering: This method is called when widget needs to render all the required dom nodes. This method is used in case the dynamic elements needs to be created to change the look and feel of the control from it's original form. if used dijit._Templated will override this method to add the template rendering that is provided by your widget. setters are called: after rendering is done the setters are called so if you need to alter the widget after it was rendered you can provide the setter for your attribute and adjust the component based on what is set. I usually add a flag in my widget that distinguish if the setter is called before the widget is fully created or if the action is based on the attr call to the widget that was already created.

Example: if you have a markup definition like this: <div dojotype="widget.MyWidget" cssclass="test"> and in your js definition you have a setter: _setCssClassAttr: function(cssClass) { } this method will be called in two cases: (Three really; one is explicit ._setCssClassAttr call - which is possible but not recommended as it does not follow the standard. Any method starting with _ is a private method). 1. When the widget is originaly getting created; 2. When the programmer explicitly calls .attr("cssClass", "test123"); on the widget instance. Thus, in setter if you need to do some action only if the widget was already created, e.g. hide / show some parts of the widget, you should create an instance variable in your widget that is by default set to false and will be set to true after the widget is created (in one of two methods that are following). The setter, in it's case, will check if the flag is set to true: If true, that means that the widget was already created and initialized and the action could be performed, If false, then this widget is still going through initialization and the different action could be performed (e.g. in case of container having it's width setter called -if widget is not created yet we could for example perform size calculation later in life cycle when all the children are already created, however if container is already created then we need to resize the children right away as the other methods in life cycle will not be called anymore). postCreate: This is a method that by default does not have any implementation but could be overriden by the child widget that needs to do some post initialization and does not care about child widgets or assumes that there will be no children for this widget. As mentioned before, this method will be called before the children of the widget were initialized so don't try to access any children in this method. However all the initialization and rendering of the widget is done so you can apply final touches here (for example setting the value of the textbox or doing final dom rendering changes). startup: This is a last method in the initialization process. It is called after all the child widgets are rendered so it's good for a container widget to finish it's post rendering here. This is where the container widgets could for example set sizes of their children relative to it's own size. destroy: method is used in case the widget needs to perform some cleanup before it can

be removed. If for example control created some dom nodes that are not children of this node (e.g. a hidden fields appended to the bottom of the document) it can destroy these noted here so there would not be some confusion or garbage staying behind. This method is also called by destroyDescendants and destroyRecursive of the parent nodes. Last note. If you are overriding any of the methods and want to call the parent's version of the method use build in function this.inherited(arguments); like in following example: postCreate: function() { this.inherited(arguments); } where arguments is a variable in the _Widget class that stores arguments passed to the function if any