This section provides a summary of the data APIs. If you're just getting started, you may want to skim this section to get a feel for the capabilities the APIs and then come back after you've read the rest of the chapter, which has more concrete examples, to explore it further.
All data stores will implement the dojo.data.api.Read
API because this API
provides the means of retrieving, processing, and accessing the
data—clearly a prerequisite for any other operation. The complete
API specification follows in Table 9-1. The next section discusses
a toolkit-provided implementation: ItemFileReadStore
.
Tip
The API listings that follow use descriptors like dojo.data.api.Item
to convey the notion
of a dojo.data
item even though
an item is somewhat of an abstract
concept.
Table 9-1. The dojo.data.api.Read API
Name | Comment |
---|---|
| Given an item and an
attribute name, returns the value for the item. A value of
undefined is returned if the attribute does not exist
(whereas |
| Works just like
|
| Introspects the item
to return an |
| Returns |
| Returns |
| Returns |
| Returns |
| Loads an item to the
effect that a subsequent call to
|
| Executes a given
query and provides an assortment of asynchronous callbacks
for handling events related to the query execution. Returns
a
|
| Returns an |
| Used to close out any
information associated with a particular |
| Used to return a human-readable label for an item that is generally some kind of identifying description. The label may very well be some combination of attributes. |
| Used to provide an
|
The Identity
API, shown in
Table 9-2, builds on the
Read
API to provide a few
additional calls for fetching items based upon their identity. Note
that the Read
API has no
stipulations whatsoever that items be unique, and there are
certainly use cases where the notion of an identity may not be
pertinent; hence the separation between the two of them. With
respect to databases, you might think of the Identity
API, loosely, as providing a kind
of primary key for each item that records can be identified with. It
is often the case that data-enabled widgets require the Identity
API, particularly when providing Write functionality. (The Write API
is coming up next.)
Table 9-2. The dojo.data.api.Identity API
The Write
API, shown in
Table 9-3, extends the Read
API to include facilities for
creating, updating, and deleting items, which necessarily entails
managing additional issues such as whether items are
dirty —out of sync between the in-memory copy
and the server—and handling I/O such as save
operations.
Table 9-3. The dojo.data.api.Write API
The Notification
API, shown
in Table 9-4, is built
upon the Read
and complements the
Write
API by providing a unified
interface for responding to the typical create
, update
, and delete
events. The Notification API is
particularly useful for ensuring visuals properly reflect the state
of a store, which may be changing or refreshed via Read and Write
operations. (The dijit.Tree
and
dojox.grid.Grid
widgets are great
cases in point.)
Table 9-4. The dojo.data.api.Notification API
Get Dojo: The Definitive Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.