Ajax Challenge 1: What Data Do You Get?

From Documentation
DocumentationSmall Talks2006JanuaryAjax Challenge 1: What Data Do You Get?
Ajax Challenge 1: What Data Do You Get?

Tom M. Yeh, Potix Corporation
January 5, 2006

The Purpose

This article describes a challenge caused by Ajax. As we know, Ajax updates a Web page asynchronously by communicating with the server. Like any asynchronous communication, it introduced the race condition. It is not easy to resolve because of the stateless nature of the HTTP protocol.


Assume you have an expense claim as follows.


<select> <option></option> <option>Postage</option> <option>Toll</option> </select>


However, your users hate to type the same amount over and over. After all, most expense rates are seldom changed. It is better to bring up the default amount from the server, when user selects an item.

To achieve this, you could monitor the onChange event for the SELECT control which represents the item. Then send an Ajax request (XMLHttpRequest) to ask the server for the default amount, when you receive the onChange event. At the server side, you write a servlet to query the database for the default amount, and send the result back to the browser in response to the Ajax request.

Assume the user selects Postage and the default amount is 0.50. Then you shall see the following form, after your JavaScript codes receiving 0.50 and updates it to the corresponding field. User could then decide whether to change the amount, before he or she submits the form.


<select> <option>Postage</option> <option>Toll</option> </select>


So far so good except a bit tedious to write so many codes just to enable such a simple function.

The Race Condition
Now your users liked this gadget for its speeding up the data entry. Until one day you found some amount is zero.
Why? One of your user clicked the submit button before the server sends back the default amount.
Worse, it is not easy to detect. For example, user might select Postage and then change his mind by selecting another. What number do you get?


To resolve the race condition, some kind of synchronization among serlvets for handling Ajax and regular requests is a must. However, HTTP is stateless, so it is not practical to really exchange data or locking among them. Rather, you could add some hidden fields to denote what Ajax requests have been responded. Then, submit with theses hidden fields such that the servlet know what have happened. As adding more interactivity such as an event causing a chain of changes, how to manage these hidden fields is another important issue.

It is time for commercial! With ZK, this issue is simple an history. ZK enriches Web applications with the classic desktop programming model, a modern markup language, and plenty of components.

Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.