Developing advanced Tutorials Using Dojo's AJAX applications, part 8th: Dijit Development Best Practices

The Dijit component (widget) is a library of graphical user interface components provided by Dojo. It provides common components to be used in AJAX application development, and helps developers quickly build AJAX applications. Instead of introducing the components that Dojo provides by default, this article focuses on introducing the programming model and best practices of the Dijit component to help developers better develop their own Dijit components. The following is a brief introduction to Dijit.

Dijit Overview

The presence of the Dijit component is an important feature of the DOJO framework that distinguishes it from other JavaScript frameworks. In desktop application development, developers use a large number of graphical user interface component libraries to improve development efficiency. In WEB application development, the HTML language itself provides only a handful of basic controls, such as buttons, radio boxes, check boxes, text input boxes, and Drop-down lists. Some of the more complex components that are common in WEB application development, such as dialog boxes, menus, toolbars, progress bars, Rich text editors, and trees, do not provide native support. In this case, developers often need to develop such complex components themselves, which results in longer development cycles and higher cost of development and maintenance.

Dojo provides a diverse range of component libraries. Developers only need simple customization to use these components in their own applications. In addition, Dojo provides a sophisticated component programming model. If the components provided by default do not meet the requirements, you can develop the required components yourself. Following this unified programming model is much easier than creating components from scratch. With the concept of components, developers can divide the various parts of the application from a relatively high level of abstraction when designing WEB applications. After defining a clear component interface, team members can develop in parallel, thereby improving development efficiency.

There are a few basic issues to be aware of when developing DIJIT components.

The granularity problem of the component. In general, more complex components are not conducive to reuse, but also detrimental to team development when the division of work. But when too many groups are on the page, they consume more system resources and affect performance. Performance is a very important factor for WEB applications. Therefore, a certain trade-off is required. It's a good idea to start with a larger component and then extract the duplicate code to form the new component when there is a duplication of code. This puts the decision to be made into a group to be deferred to the real need, avoiding excessive design.

The interface problem for the component. The interface of a component defines how other parts of the code use the component. In general, a component can provide three classes of interfaces: Public properties, public methods, and event binding points. A public property refers to a simple data type property provided by a component that can be publicly accessed. Typically used when creating components, used to customize components, and public methods refer to JavaScript methods that can be publicly accessed. Typically used after a component is created to change the behavior of the component, and the event-binding point is the placeholder method exposed by the component. Typically, a component consumer binds to the method by Dojo.connect (). Component uses this method to notify users of changes in their internal state. Such methods generally use on as the name prefix. Developers should define the right interfaces as needed to avoid some bad practices. For example, the value of a public property after the component is created, the user is generally not recommended to set its value. If setting the value of this property is a reasonable scenario, it is best to provide the appropriate public method and tell the user the correct usage in the form of a document.

An interaction problem between components. If you need to communicate with each other between components, it is best to use the component's object reference to do so. For example, when a component creates another component, it can pass its own object reference as a parameter to the component it creates. The latter can use this object reference to invoke the former method. Another approach is to do so through the Dojo.publish () and Dojo.subscribe () methods. The use of this approach is relatively simple and can avoid a deeper level of object reference delivery. The bad part is that the correlation between components is not clear enough and it is difficult to maintain. The recommended approach is to use the first method preferentially.

This paper discusses some common problems of developing DIJIT components. The programming model for the Dijit component is described below. During the introduction of the programming model, the relevant best practices are interspersed. Start with the core class dijit._widget of the Dijit component first.

Dijit._widget

Dijit._widget is the parent class for all Dijit components. Dijit the components that are provided by default and the components that you develop are required to inherit from this class. Dijit._widget provides methods that involve the lifecycle of components, property settings and access, event handling, and other accessibility features. An in-depth understanding of the usage and implementation details of these methods of this class is the basis for developing your own DIJIT components. The following is a separate discussion of the methods provided by Dijit._widget.

Component Life cycle

Dijit._widget provides a complete management of the component lifecycle, including the creation and destruction of components. The lifecycle management of the Dijit component is implemented using the template approach (Template method) design pattern. The Create () method of the Dijit._widget class defines the default template for the life cycle of a dijit component when it is created. This method invokes other methods contained in the template at the right time. These different methods form the phases of the component's lifecycle. When developing your own components, you can override some of these methods to add your own processing logic at the stage of interest. Developers can also override the Create () method to provide a completely different lifecycle implementation. However, this approach is too risky and is not recommended for use. In most cases, the method provided by the override default template is sufficient. The creation phase of the component life cycle defined in Dijit._widget is shown in Figure 1.

Figure 1. Dijit Component Creation Process