AJAX - The Complete Reference

232 Part II: Developing an Ajax Library^

encounter application or data errors. For example, the server might send back the wrong

data type or a data packet that is malformed. The error cases can be broken into a couple of

obvious groups including:

• The Web server throws an error.


• The server-side framework throws an error.


• The application itself throws an error.


• The application returns erroneous data (wrong format, malformed, and so on).

The situation can get a bit more complicated when moving from one request at a time to

multiple requests being issued at once. If the ordering of the responses matter, particularly if

responses depend on each other, does the application work if data arrives late or out of

order? Could a race condition occur if multiple requests attempt to access fixed resources?

Clearly asynchronous Ajax programming with numerous dependent requests is approaching

the same kind of complexity as concurrent programming using threads, but now the tasks

are being farmed out over a potentially unreliable network connection!

An application that is more continuous in its communication to the server adds even

more concerns than previously mentioned. To build such an application you might employ

a polling pattern to maintain a live heartbeat. With a focus on quality connectivity, we

should consider monitoring the quality of the link, both initially and over the course of

time. Transmitting error counts, retry numbers, latency statistics, and other indications of

the quality of communications moves developers out of the realm of assuming all is well to

actively monitoring communication and application quality.

Given the overview of the possible problems that may be encountered, each issue will

now be presented more in-depth along with code and concepts to address or at least

identify the issue. Extra time will be spent addressing how to make Ajax applications as

speedy as possible, as improved speed is one of the primary reasons Ajax is employed.

Timeouts

Starting with the simplest concern, what happens if a request simply doesn’t return or appears

not to because it is so slow? Sane users don't want to sit watching a spinning circle forever. To

address this, timeouts should be employed where after some predetermined time has elapsed

the request is aborted or, as shown later, even retried. Interestingly, setting a timeout value is

not part of the native XHR object, but it is easy to implement. When invoking sendRequest(),

the user can set options to indicate that a timeout should be applied. The defaults for the

request are

request.timeout = false;

request.timeoutCallback = function(){};

The timeout option can be false or 0 if no timeout is wanted or it can be the number of

milliseconds preferred for the timeout.

In order to override these and have the library invoke a callback function upon timeout,

the options should be set like:

var options = { method: "GET",

timeout : 2000,