AJAX Components - Part 3 | Page 2 | WebReference

AJAX Components - Part 3 | Page 2


[previous] [next]

AJAX Components - Part 3

Connecting to the Server

Rendering static data is hardly that useful in an enterprise application, so let's connect to the server. To retrieve data from the server, we need to go back to our SimpleDataModel class and give it some teeth. The first step for creating a remote datasource is retrieving the data from the server—we deal with inserting, updating, and deleting later. The UML diagram for the RemoteDataModel class looks like Figure 4.4.

The important new features of the RemoteDataModel compared to the SimpleDataModel are the private m_httpRequest for retrieving data from the server, the onDataReady event for notifying interested parties when the data is ready for consumption, the m_readComplete method that handles the asynchronous callback from the XHR object when the data has been retrieved from the server, and finally, the itemFactory object that we use to deserialize XML data from the server into JavaScript objects. The code for the RemoteDataModel follows:

Consider a few important points about the RemoteDataModel class. First, we request the data from the server asynchronously—at the URL specified by the handler field—so the read() method no longer directly returns data; the read() method no longer blocks the JavaScript thread until data is ready to be returned and instead sends the request for data to the server and immediately returns with no return value. The data is actually returned from the new method we added called m_readComplete(), which is executed when the data has finally been returned from the server. Just like the callback function that we use on the plain XHR object to be notified when an asynchronous request has been completed, we now need to apply that same pattern to our custom JavaScript classes that rely on asynchronous server requests. Thus, we have introduced the onDataReady event to which handlers can be subscribed and, hence, notified when the data is indeed ready.

The second important point about the RemoteDataModel class is that rather than returning JSON from our web service on the server, we return plain XML, which this is another aspect that can be factored out to create a RemoteXMLDataModel and RemoteJSONDataModel. A problem arises here because our DataGrid component relies on JavaScript-based tem-plating and, therefore, expects an array of JavaScript objects as the items field on a datasource object. To achieve this, we made the itemFactory field on the RemoteDataModel that is used to enable the user to specify a factory object that will provide a fromXml method that will return a JavaScript object based on the information in an XML element returned from the server. In this case, we want to create Customer objects, and we set the itemFactory field of the RemoteDataModel to an instance of the CustomerFactory class:

Now we have a choice to make as to how we actually instantiate the Customer class, and we have decided to depend on the class itself to do the deserialization from an XML element. The alternative would be to create an instance of the Customer class and then set all the relevant fields from the outside. To achieve this deserialization, we created a basic Serializable class as follows:

This loops through the attributes on the XML element from which the object is to be deserialized and copies each attribute name and value pair onto the JavaScript object. The Customer class looks like this:


[previous] [next]

URL: