As a GIS web application developer you have many choices when it comes to developing web based mapping applications. The new JavaScript APIs including ArcGIS Server, Google Maps, Bing Maps (still can’t get used to calling Virtual Earth by its new name), OpenLayers, and others have opened up a treasure chest of opportunities for developers. These JavaScript APIs excel at quickly accessing and displaying geographic data to your end users. But there are many times when you need to display additional non-geographic data in your applications and this data can come in many formats including database tables, JSON, XML, CSV, images, and others. This data may be displayed in a variety of user interface components including grids, trees, combo boxes, image galleries, and others. Dojo not only provides the user interface widgets for displaying the data, but also a data abstraction layer for accessing data in various formats.
Dojo provides extensive utilities for reading and writing data in various formats through its Data API. The Data API is actually composed of four abstract API’s including the Read, Write, Identity, and Notification APIs. These abstract APIs are implemented by various core implementations called stores that read specific dataset types including JSON, XML, CSV and web services from Google, Flickr, and others. For example, the GoogleSearchStore is a core implementation of the abstract Read and Write Data APIs that can be used to perform a search against Google’s Search Service. In the next few posts we will examine several of the core implementations of the Data API including stores used to read data in JSON, XML, and CSV formats. For today though we’ll simply get a high level overview of the abstract Data APIs.
Dojo.data provides a uniform data access layer that removes the concepts of database drivers, service endpoints, and unique data formats. All data, whether the format be JSON, XML, CSV, or something else, is represented by items (rows in database terminology) and attributes (columns in database terminology) of an item. These items are returned via fetches or queries against a data set. The basic implementation of dojo.data gives you access to ItemFileReadStore which provides read access to JSON format data and ItemFileWriteStore which provides write access to in-memory JSON format data. Additional stores including XmlStore, CsvStore, and endpoint specific stores for Flickr, Google, Amazon, and others are provided through the DojoX project (dojox.data). Obviously you will want to do something with the data once it has been retrieved. Normally you’ll want to display the data in some way. Dojo widgets (called dijits) such as grids, trees, combo boxes, and others are data store aware and can easily be hooked into your data store.
Data can be stored either locally or remotely. It is treated the same either way. The Data API also removes the need for you as a programmer to acquire boilerplate code that retrieves data, writes updates to the server, maintains synchronicity with the server, and handle variable formats. Dojo provides a standardized way of interacting with whatever data source you need to work with. In the Data API, a data store is the main object for each implementation and is created as a driver for one and only one dataset. For instance, the ItemFileReadStore object is a core implementation of the Data API which is used to read data in a JSON format.
The Identity API is very similar to the Read API, but provides a few additional capabilities such as the ability to perform random access of an item within a dataset. Identity also returns unique data items which is important when using certain user interface Dijits such as combo boxes, filtering selecting, and tree dijits which need unique items.
The Notification API builds on the Read API and complements the Write API. It provides a unified interface for responding to create, update, and delete events.
