This article describes how the _ wdgietbase module in the dijit package works and how it works as the basis for all widgets in the dojo toolkit.
Difficulty: Moderate dojo version: 1.7 Author: Tom trenka Translator: Oliver original link: http://dojotoolkit.org/documentation/tutorials/1.7/understanding_widgetbase/
The basic architecture of the dijit package and the ability to create custom widgets depend heavily on a base class defined in the dijit/_ widgetbase module. Although there are other common modules that are very valuable in developing Dojo-based Web applications (such as the dojo parser and dijit template systems ), however, this _ widgetbase is used to create any custom widgets. In this article, you will learn how the widget infrastructure works.
Note: you may be familiar with the dijit/_ widget module if you have experience using the early dojo version. Although dijit/_ widet still exists and inherits dijit/_ widgetbase, it is best to directly inherit djit/_ widgetbase when writing your own widgets. Dijit/_ widget is likely to be removed from dojo2.0.
To understand the dijit system, the most important thing is to understand the lifecycle of a widget. This lifecycle is mainly about the initialization process of widgets. That is to say, from creating a widget to being fully usable by your application, to destroying the widget and Its DOM nodes.
Note: The underline "_" was added before widgets and widgetbase because they should not be directly instantiated, but should be inherited through the declare mechanism of dojo.
The methods in _ widgetbase can be divided into two main lines: A group of methods called sequentially during creation, and a set of methods for getting/setting properties with the smallest data binding during the use of widgets. Now let's take a look at the creation process of widgets.
In the dijit life cycle, any widget with the _ widgetbase class will call several specific functions in sequence during its initialization. The following lists the functions in the call order:
- Constructor (All prototypes are common and called during initialization)
- Postscript (All prototypes declared by declare are generic)
- Create
- Postmixinproperties
- Buildrendering
- Postcreate
- Startup
View the examples of these methods to deal with the following:
- When to define the Initial Value
- How to create a visual representation of an initial value
- These visualizations indicate when to connect to the DOM tree.
- When to execute code that depends on the DOM node connected to the DOM tree
When creating a custom widget, postcreate () is the most important method to remember. This method is called when all properties of a widget have been defined and the DOM structure of the widget has been created (but before it is connected to the main DOM tree. This method is important because it is the main place for developers, that is, you, to make final adjustments before the widget is finally presented to users. These adjustments include setting any custom attributes. When developing a custom widget, most (if not all) Customization will appear in this function.
Startup () may be the second important function in the dijit lifecycle: startup. This method is called after the DOM structure of the widget is connected to the main DOM tree. Before this function, all child widgets of This widget have been created and started. This function is very useful for composite widgets (such as layout widgets.
Note: When initializing a widget programmatically, you must call the startup method and place the widget in the document DOM tree before calling it. It is a common mistake to forget to call the startup method after creating a widget. This will make you crazy because you don't understand why the widget is not properly displayed.
In addition to the initialization method, dijit/_ widgetbase also defines some destruction methods (listed in the call order ):
- Destroyrecursive
- Destroydescendants
- Destroy
- Uninitialize
- Destroyrendering
When creating your own widgets, any necessary custom destruction actions should be defined in the destroy method (do not forget to call this. inherited (arguments )). The destroy method provided by dijit can automatically process DOM nodes and most objects. Therefore, you do not have to write these logics from the beginning.
Note: Although destroy is the core method for destroying widgets, it is best to call destroyrecursive when explicitly destroying a widget. This method ensures that all child widgets of the widget are also destroyed.
A widget referenced by a DOM node is usually a user interface, so most of them have a DOM structure. _ Widgetbase defines a table attribute called domnode, which is a reference to the DOM node that contains the entire widget. If you need to perform some operations on the DOM tree of the widget (for example, moving the entire widget to another position of the DOM tree), you can get reference of this node at any time. This reference already exists when postcreate is called.
In addition to the domnode attribute, some widgets also define the containernode attribute. This is a reference to an internal node of the widget. This node contains HTML content or even other widgets, which are often defined out of your widget declaration, for example, a sub-widget created through declaration.
Note: we will discuss the importance of the containernode attribute in another tutorial. Currently, you only need to know that this attribute exists in some Widgets. (Note that it exists in all widgets inherited from dijit/_ container ).
Besides the initialization and destruction methods, getter and setter also predefines the attributes required by many widgets and a complete set of mechanisms for defining getter and setter attributes, this mechanism works through standard get and set methods, which are defined in all widgets. You can use this mechanism by adding a private method containing the following signature mode in the Code:
// The "foo" attribute of your Widget: // custom getter_getfooattr: function () {/* do something and return a value */}, // custom setter_setfooattr: function (value) {/* do something to set a value */}
Once these method pairs are declared using this method, you can use the standard get and set methods of _ widgetbase to access your custom attributes. For example, in the preceding example, you can write:
// Assume that the widget instance is named mywidget: // obtain the value of the "foo" attribute: VaR value = mywidget. get ("foo"); // set the value of the "foo" attribute: mywidget. set ("foo", somevalue );This standard allows other widgets or control logic to interact with a widget in a unified manner, when an attribute is accessed, it provides you with the ability to execute custom logic (such as modifying a DOM segment ), or call other methods (such as triggering an event or notification ). Assume that your widget has a custom attribute value, and you want to notify others when the value is changed (You may define an onchange method ):
// Assume that our attribute is called "value": _ setvalueattr: function (value) {This. onchange (this. value, value); this. _ set ("value", value) ;}, // a function onchange: function (oldvalue, newvalue) used for dojo/on ){}
As you can see, this mechanism makes it very convenient to customize the behaviors of getter and setter.
Note: When writing your own widgets, you should create corresponding getter and setter methods for any situations that require special logic to obtain and modify custom attributes. When using your own widgets, you must always use the get () and set () methods to access properties. Only in this way can the custom getter and setter logic be correctly called. In addition, when creating a custom setter method, you should always use the internal _ set method to update the internal value, so that the watch method of dojo/stateful can work normally. This dojo/stateful is also the base class inherited by all widgets.
At the end of listening to events and themes, _ widgetbase provides encapsulation for the two most important event mechanisms of dojo: On () and subscribe. These methods are mainly for convenience, and secondly for the convenience of accurately initializing and destroying widgets. You do not need to define these methods by yourself. They are all directly available.
It is easy to use. On () and. subscribe:
// Assume we have a Button widget called "BTN", // and we want the button to listen to the "bar" event on FOO: BTN. on (Foo, "bar", function () {// note that "bar" is executed in the BTN context! This. Set ("something", somethingfromfoo );});Topic subscription (through the pub/sub system of dojo) can also be implemented in a similar way.
The benefit of defining on and subscribe in the widget infrastructure is that the widget can track all its events and topic subscriptions, ensure that the widgets are properly unbound (or subscribed) when they are destroyed to avoid Memory leakage.
At the end of the predefined attributes and methods, _ widgetbase provides a set of predefined attributes and corresponding getter and setter (if needed ):
- ID: the unique string used to identify the widget
- Lang: A rarely used string attribute that overwrites the default dojo locale
- Dir: Useful when bidi is required
- Class: the HTML class attribute of the domnode of the widget
- Style: the HTML style attribute of the domnode of the widget.
- Title: generally refers to the native tooltip HTML title attribute.
- Baseclass: the root CSS class of the widget
- Srcnoderef: A Dom node that exists before the widget is "controlled" (if any ). Note that the attributes of some widgets (such as template widgets) will be reset after postcreate, because the original node has been discarded.
Conclusion As you can see, the dijit _ widgetbase base class provides a solid foundation for creating and using widgets, covering all aspects of widgets (lifecycle, Dom node reference, getter and setter, predefined attributes and events ). We have seen that the postcreate () method of a widget is the most important life cycle method when developing custom widgets, and how critical it is to call startup () when instantiating widgets programmatically. We also introduced the getter/setter mechanism of dijit and the importance of the domnode attribute of a widget.
