Building a Client-Side Ajax Cache / Page 2 | WebReference

Building a Client-Side Ajax Cache / Page 2

[previous] [next]

Building a Client-Side Ajax Cache [con't]

The searchForEmployee() Function

This is where high level actions occur, such as setting up page elements, initializing variables, form validation, and finally, calling our cache's fetch() function. In this simple context, we only need to perform the latter two. Likewise, the only form validation that we are performing is to verify that it is not empty. Using a combination of Prototype and native JavaScript functions, it's actually quite simple to do. In fact, you can even chain several functions together, as was done here:

The first line of code converts the form contents into a Hash, using the constructor that accepts a JavaScript Object. Prototype has a function for converting a Form to an Object called Form.serialize( string formElement[, createHash = false]) ). The first argument can either be the Form Element or just it's ID. The second, optional parameter is a boolean indicating whether to return the Form as a query string (false) or as a proper JavaScript Object (true). Inside the if test, we are calling the values() function on the inputHash, which returns an Array containing all of the Hash items, without their associated keys. The native JavaScript join() function creates a string from the Array without any token separator, which is a comma by default. To test for the absence of values, we can apply the Prototype blank() function to the returned string. The blank() function carries out a special string test that ignores whitespace. That way, strings which contain spaces are still deemed to be empty.

Having completed form validation, we are ready to call the fetch() function. It accepts three arguments: the query string, an Object containing element IDs — one for populating data, one for displaying error messages — and the base url. Converting the Hash to a query string can be achieved using the Hash's toQueryString() function. The same URL-encoded string that is appended to the URL in a GET request will double as our keys. To give you an idea of what a query string looks like, here is an example of a generic GET request. The Form data, called the query string, is the part after the question mark (?):

There is some additional code for creating the url in the form of "employee[1 - 5].txt". It simulates dynamic server behavior and allows us to test our cache without requiring a server-side component. In a real application, it would probably be most efficient to set the base URL when creating the AjaxCache class.

The AjaxCache as a Proxy

It is important that a cache manager be transparent to the script that is using it; calling the function that fetches the data should come back with a resultset (if only an empty one). Ideally, from the client's perspective, it should be nearly impossible to tell whether the data was retrieved from the server or from the cache, except that the server calls could be expected to take slightly longer; in practice, the server calls may not lag enough to detect a difference. The asynchronous nature of Ajax creates a slight hurdle for us, in that it does not return a value directly to the calling function, but rather, executes the callback function on its return. To get around this, we could design our calling function to also accepts a callback function. So, while our function would never return a value directly, it would handle the execution of the callback function with the requested value(s). Using the cache in this way is called a Proxy pattern.

AjaxCache Version 2: Using the Prototype Ajax.Updater

Building our cache using a proxy pattern as described above would work well, but it still leaves the transformation from dataset to viewable HTML up to the caller. We can lessen the burden by taking advantage of the Prototype Ajax Updater. It accepts all the same parameters as an Ajax Request, but with the addition of two element IDs: one to display the results and another for error messages. Prototype takes care of the updating of the element's contents via the Element.update() method.

Here is the code for the AjaxCache, which makes use of the Ajax Updater:

Our test files are formatted as table rows so that they can be inserted directly into the table for displaying:

[previous] [next]