Ext Data Classes

I't useful to look at an ajax application from the perspective of the data and its life cycle. At a high level, an ajax application retrieves data from a server in some format (xml, json), stores it in memory as javascript objects where it is accessed and manipulated by UI components. At some point, updates are made to the data and sent back to the server.



So how does Ext support the data lifecycle? A picture is worth a lot of words, so here's the picture:

Data comes from some source (your server or a local javascript object), with a format (XML, JSON) and is converted into a set of Records with the help of the DataProxy-DataReader-RecordType trio. The data is stored in the Store which provides APIs for access and modification.

Creating, configuring, and loading the store.

The data lifecycle is orchestrated by the Store class. After your application has started and UI components have been rendered, you call a load method on the store.

At some point in your application initializition process, you create a store and pass it a reader, a proxy, and a record type (the trio mentioned above).

Options:

· Use a JSON store. It internally creates an HttpProxy and a JsonReader. You pass the fields that define the record type.
· Use a MemoryProxy with a JsonReader for in memory data.
· Use a SimpleStore for Simple in-memory arrays. The SimpleStore internally creates an ArrayReader.

Once the store is configured, pass it to a UI component. A grid takes a store as a parameter in it’s constructor.

After the the UI is rendered, call load.

Loading the Data

Call load (later reload) and the store calls load on the proxy, passing the reader and a callback method (loadRecords) to the proxy. The proxy gets the data (from server or from memory) and passes the raw data to the reader. The reader converts the raw data to an array of records based upon the recordType (which the reader now has) and returns the records to the proxy who calls back to the store (loadRecords). The store updates itself and fires the load event.

Dont need a proxy because you have local data? Call loadData on the store and pass the data object as a parameter. The store will call readRecords on the reader and then call loadRecords on itself to load the converted records into the store.

You can even pass data into the store in the constructor {data: myData} and it will automatically load the data. This seems like the simplest approach for local data.

OK, so now the data has been loaded. The store fires the load event, listening UI components are notified and the UI’s then access the store to read and render the data. You can refresh and reload the store at any point and the UI will get update itself.

The Store: Internals and Specifics

The store contains three collections of data: a MixedCollection named data that is a collection of Records and represents the primary data owned by the store. When sorting, grouping, or filtering operations are performed, the store create a second MixedCollection named snapshot that contains the subset created by the operation.

The modified collection is an array of modified records. The modified collection is added to after afterEdit is called and cleared after afterReject and afterCommit is called. These methods are called by a Record object (linked a single store by a pointer—when a record is added to the store, the store joins itself to the record). When reject is called on a record, the record calls afterReject on the store. When commit is called on a record, the record calls afterCommit on the store. A record can call afterEdit at two points: when endEdit is called and at the end of a set command.

The Record Class

TODO.

UI Components that Use the Store

DataView. A UI component that renders a set of records from a store using a template. DataView handles load, dataChange, add, update, and remove events. Its updates its view based upon data changes in the store.

PagingToolbar. Listens for load events and accesses the total field in the store to update it's total field.

LoadMask. Listens for beforeLoad, load, and loadException.

ComboBox. Handles, beforeLoad, load, and loadException events.

Use of Stores by Grid Components

CellSelectionModel. Gets the record matching the selected cell index passes it along when it fires the cellSelect and selectionChange events. It doesn't directly access or modify records in the store.

ColumnModel. ColumnModels don't refernce a store directly. However, they own the dataIndex property which maps (by index) the column represented by the ColumnModel to a record in the store. Furthermore, the ColumnModel owns the optional column renderer function which receives a store as a parameter.

EditorGrid. When a user activates a cell editor by means of a doubleclick, the EditorGrid gets the record from the store and shows/renders the edit control. (The key method to look at is startEditing).

GridPanel. Passes the store to the loadMask. Calls sort on the store.

GridView. The GridView is one of the heaviest users of the store.

• Receives the store from the GridPanel (thank you).
• OnHeaderClick, calls sort on the store (the store does the sort, then turns around an fires an update event which the GridView listens for and hears and updates itself.
• Listens for load, datachaned, add, remove, update, and clear events, and does the right thing.
• Passes the store to the renderer (stored in the ColumnModel) when rendering the grid
• Get the count and accesses field names.

RowSelectionModel. Validates row selection indexes.

Extensions of the Store.

GroupingStore. Adds a groupBy method.

PropertyStore. PropertyStore is an Observable that holds a store (versus "specializing" a store). It adds its own store semantics. It creates a store based upon a PropertyRecord.

Ext.grid.PropertyRecord = Ext.data.Record.create([
{name:'name',type:'string'}, 'value'
]);

The PropertyStore listens for updates on the store and fires its own property change events, thus changing the semantics of the store.