Dojo Data advanced applications--using the Write API and the notification API

Overview

With the rapid development of Web2.0 and RIA, processing data at the client is becoming a trend. Using the Dojo Data,web developers can establish a unified data access model in different data formats, which makes the data read and write adopt a unified interface, which reduces the complexity of client logic and improves the maintainability and scalability of the program. In this article, we illustrate the technical application of the Read API in Dojo Data through examples.

Introduction to the Dojo Data Write API

Some repositories in the Dojo Toolkit not only provide read functionality, but also provide write functionality. That is, by using these repositories, users can not only obtain data from the server side, but also update the source data on the server side. These repositories implement a Write API defined by Dojo data to create, change, and delete data. Similar to the Read API, the Write API is designed to mask differences in the underlying data storage format and to provide users with a uniform data access API. With these APIs, users can focus on the logical implementation of the business level without spending too much effort on the underlying data storage format. Table 1 lists the Write APIs defined by Dojo Data.

Table 1.Dojo Data Write API

Api	Describe
NewItem	Create a new data item
SetValue	To update the value of a data item
DeleteItem	Delete a data item
Setvalues	Update values for a set of data items
Unsetattribute	To empty an attribute value of a data item
Save	Commit the updates made by the client to the server side to complete the update of the source data
Revert	Rollback of updates made by the client to the state after the last save operation
IsDirty	To determine if a data item has been updated on the client

The Dojo data update is divided into two phases. In the first phase, the user invokes the Write API provided by Dojo data to update the data, which is recorded by the repository trace. These updates are also stored in local memory and are not immediately delivered to the server side. At this point, if the user invokes the revert method, you can discard the update operations, roll back the repository to the state after the last call to the Save method, and in the second phase, the user invokes the Save method, using the Dojo XMLHttpRequest technology to communicate with the server asynchronously, The user's actions are passed to the server side, which ultimately updates the server's source data. The advantage of this design is that the interaction with the server side can complete a large number of data updates at once, that is, batch operations, and can support rollback on the client side. The entire process of the Dojo data update is shown in Figure 1.

Figure 1.Dojo Data Update operation flow