Preview new functions of extjs 4.0 (5): new store/Proxy

Document directory

• Ext. Data. serverproxy (ajaxproxy)
• Ext. Data. clientproxy (memoryproxy/webstorageproxy)
• Store/Proxy Summary

Link
Proxy

Ext. Data. Proxy is a key data communication class. Proxy: proxy. How can data be proxy? A little disconnected! What does proxy mean?

In simple terms, proxy is the data source defined. At least ajaxproxy/scriptproxy/localproxy/sessionproxy in ext performs this way. To load or store data for Ext. Data. model4, you must use this proxy class. Specifically, the proxy operation regards all final data operations as add, delete, modify, and query, namely create, read, update, or delete. These four operations map create (), read (), update (), and destroy () respectively (). The task of different proxy subclass is to specify the crud one by one and then return it to the store. In the crud method, we all expect an Ext. Data. Operation
The exclusive parameter of the object is passed in ....... What is operation? Opeartion is a new version of 4.0. It encapsulates the action information to be executed by stroe, the Ext. Data. Model instance to be modified, and so on. In the completion phase, each crud method supports asynchronous callback functions.

In API implementation, proxy can be divided into serverproxy and clientproxy:

The server proxy sends data to the remote end through the request. The client proxy means to save local data on the client. The following is an introduction.

Ext. Data. serverproxy (ajaxproxy)

Serverproxy is the superclass of the ajaxproxy and scripttagproxy classes. Generally, ajaxproxy is the most common proxy in typical cases. the parameters set in the page code are obtained from the server through the Ajax pipeline. Ajaxproxy is only applicable to the same source page. Cross-origin (crossdomain) data cannot be obtained from the range on this page. To obtain data across domains, use scripttagproxy. Ideally, serverproxy should be called httpproxy, because it covers all the superclasses of httpproxy-but it is adjusted in ext4.0, and httpproxy is dwarf to the abbreviation of ajaxproxy. Httpproxy in 3.x is changed to serverproxy.

The difference between scriptproxy and the old version is not big. In principle, script tag is also used for disguised cross-origin. The disadvantage is that it is only suitable for JSON data format. We can also look at the Ext. util. jsonp class for the cross-cutting solution.

In Ext, how do I rest web resources?

If you need a restful style application, you can add "Put/Delete" based on "Get/Post" of ajaxproxy to make full use of the four HTTP verbs, EXT is implemented by Ext. data. resetproxy. The 'create', 'read', 'update' and 'deststroy' provided in resetproxy correspond to the post, get, put, and delete methods respectively. ajaxproxy. actionmethods is limited to get/post operations .). That is to say, the resetproxy manages the data API. In addition to defining the four crud operations: Create, view, change, and destroy, these operations are mapped to the restful HTTP method respectively: get, post, put, and delete.

Ext. data. restproxy. the actionmethods item should remain unchanged unless the global Ext. override () overwrites the default value. You can also override getmethod (by Ext. data. ajaxproxy inherited. In short, we can also extend other HTTP verbs. In view of the small number of lines of restproxy code, this post is as follows:

/** <Br/> * @ author Ed Spencer <br/> * @ Class Ext. data. restproxy <br/> * @ extends Ext. data. ajaxproxy <br/> */<br/> Ext. data. restproxy = ext. extend (ext. data. ajaxproxy, {<br/> actionmethods: {<br/> Create: 'post', <br/> Read: 'get', <br/> Update: 'put ', <br/> destroy: 'delete' <br/>}, </P> <p> API: {<br/> Create: 'create ', <br/> Read: 'read', <br/> Update: 'update', <br/> destroy: 'deststroy' <br/>}< br/>}); <br/>

Compared with ext. data. API comparison (see 3. x), although it is set around rest, the number of lines in the new resetproxy code is greatly reduced, the preliminary judgment is to give full play to the results brought about by the OO methodology (compare the old API is a singleton design ).

Ext. Data. clientproxy (memoryproxy/webstorageproxy)

Ext. Data. clientproxy is the storage base class for the client (because clientproxy is the base class, please do not use it directly ). Its subclasses include Ext. Data. memoryproxy and Ext. Data. webstorageproxy. The main usage of these two subclasses is as follows:

• Memoryproxy is a proxy in the memory, so if you refresh the browser, there will be no local data. That is, all data in memoryproxy is in the memory. Once the page is refreshed, the data will no longer exist. Generally, this class is not directly used. When will it be used? For example, if the structure of a user model and data from different sources is not very consistent, we can flexibly use memoryproxy and jsonreader for conversion and then load the data to the store.
• Webstorageproxy is the base class of Ext. Data. localstorageproxy and Ext. Data. sessionstorageproxy. It usesHTML5The new Ley/value client storage solution stores Ext. Data. Model instances to achieve offline persistence. During the process of instantiating webstorageproxy, if the browser does not supportHTML5The client storage solution immediately throws an exception.

As shown in the UML diagram, webstorageproxy has the standard crud method; memoryproxy only has the read () method; but both have the clear () method. This method deletes the client to make all record data, including supported data such as IDS. The following is an example of using memory for conversion:

The sample code for edit may be different from the EXT model of the latest version, but it does not affect the main meaning-thanks to Qiuqiu/Sun.

// The model used in the store. <Br/> Ext. regmodel ('user', {<br/> fields: [<br/> {Name: 'id', type: 'int'}, <br/> {Name: 'name', type: 'string'}, <br/> {Name: 'phone', type: 'string', mapping: 'phonenumber'} <br/>] <br/>}); <br/> // The data is not consistent with the model defined above, that is, the phone field must be mapped to phonenumber. <Br/> var DATA = {<br/> Users: [<br/> {<br/> ID: 1, <br/> name: 'ed Spencer ', <br/> phonenumber: '000000' <br/>}, <br/>{< br/> ID: 2, <br/> name: 'abe Elias ', <br/> phonenumber: '000000' <br/>}< br/>] <br/>}; <br/> // set "root: 'users' "to see how it corresponds to the above data structure. <Br/> var store = new Ext. data. store ({<br/> autoload: True, <br/> model: 'user', <br/> data: data, <br/> Proxy: {<br/> type: 'memory ', <br/> reader: {<br/> type: 'json', <br/> root: 'users' <br/>}< br/>}); <br/>

The premise is that webstorageproxy has two subclasses:

• Localstorageproxy: The local storage of html5.
• Sessionstorageproxy: Uses HTML5 session storage as the service object.

Once again, both localstorageproxy and sessionstorageproxy involve new HTML5 functions. Therefore, if the browser does not support HTML5 functions, the webstorageproxy constructor immediately throws an exception. When using local storage, you need a unique ID as the key for storing all the record objects, and remember that the ID to be sent must be unique. Otherwise, the call process will be unstable. If no ID is sent, the storeid is considered as the ID. If no ID exists, an exception is thrown.

Proxy is always used in combination with Ext. Data. store. You can also directly create a proxy, as shown in the following two examples:

New Ext. data. store ({<br/> Proxy: {<br/> type: 'localstore', <br/> ID: 'myxykey' <br/>}< br/>}); <br/> // directly create <br/> New Ext. data. localstorageproxy ({<br/> ID: 'mytherproxykey' <br/>}); <br/>

The new webstorageproxy includes offline tasks. In addition to webstorageproxy, ext 4.0 also provides websqlproxy so that the storage client can use SQL statements. However, no source code of websqlproxy is found. It is estimated that the source code will be seen only after the final release.

Store/Proxy Summary

The data has changed a lot and many statements can be listed. Here is a small example: Introduction of the new Ext. Data. treestore/EXT. Data. treereader. Ext. Tree no longer uses the data binding form of treeloader, which is the form before 3. X. In fact, there is no need to set up a different data model for the tree component. Ext4 is aware of this. In this release, we can see that the tree belongs to the store data source.

There are other such cases ~

Edspencer, a core team member, is the architect of extjs4. At the senchacon conference, he gave a speech on ext's architecture and new features. In addition, ext. Data. * is from him. I think we should politely thank him for taking the opportunity to speak here. No matter how many people are, they are also open-source. What we can see is that Ext. Data. * has been rewritten to form such an API situation. I personally think this is the biggest change in 4.0 and it is fascinating. As the official roadmap says, "A rewrite of the Ext. datapackage with a brand new architecture
"And enormous newcapabilities" is a real name.

The data section also has a play. Ext. Data. Operation actually refers to the CRUD operation between store and proxy. Ext. Data. batch is a collection form of opeartion. It is a batch to package multiple operations. In addition, there is Reader/writer, which will be available for further discussion in the next phase.

Reprinted please indicate the sourceEXTHttp://www.ajaxjs.com ).