7.2. Asynchronous

On the surface, what's required to change the request from synchronous to asynchronous appears to be simply changing the false parameter to TRue for the open method. Unfortunately, although that would make the request asynchronous, it would have some issues with the responseXML property. This is because the request is asynchronous; instead of waiting for a response from the send method, processing just continues on its merry way. This means that the responseXML property is undefined, which is not exactly what we're looking for or expecting.

Fortunately, there is a way to correct this issue, but it requires creating an event handler to, er, handle changes to the readyState property. With the XMLHttpRequest object, the value of the readyState property changes every time something changes with the response to the request. This change fires the handler defined by the onreadystatechange property. Let's take a look at the example shown in Listing 7-2.

Listing 7-2. Example of Creating an Event Handler to Correct the Problem

var objXMLHTTP = new XMLHttpRequest(); var objXML; objXMLHTTP.onreadystatechange = asyncHandler; objXMLHTTP.open('GET', 'books.xml', true); objXMLHTTP.send(null); function asyncHandler() { if(objXMLHTTP.readyState == 4) objXML = objXMLHTTP.responseXML; }

In this example, the function asyncHandler is assigned as an event handler using the onreadystatechange property. This means that the asyncHandler function fires each time the readyState property changes. Because it fires every time the property changes, it is necessary to verify that the response is actually complete before doing anything with the response. The if statement in the asyncHandler function takes care of this issue; a readyState equal to 4 means that everything is fine and we're done. But what if everything isn't fine?

Anyone who has ever played any of the Mech Assault campaigns knows that something always goes wrong. What fun would it be if everything worked all the time? Thinking about it, please disregard my last statement as the ramblings of a sick mind. Nevertheless, the universe is perverse, so bad things happen to good people, countries, cities, and web applications. Because of this, it is sometimes necessary to code defensively, to handle the unexpected. Note that I said defensively, not offensively. Don't go looking for problems; like a mad cat with charged PPCs, they'll find you soon enough.

You can handle this potential problem in several ways. The first possible method involves hoping and wishing. Unfortunately, management has a tendency to frown upon this method of error handling. Possibly this is because mangers aren't a particularly hopeful group of people. Maybe because their heads are on the chopping block right next to our own.

A better method of handling potential problems, at least from a job longevity point of view, is to consider what could go wrong. The way that I see it, things can go wrong in two possible ways. The first of these is getting basic bad information back from the server. During development, this can be handled by an alert and the responseText property. Beyond the development phase, however, this would probably scare away the nonmad scientists. At these times, you might want to inform the user that an error has taken place and use the XMLHttpRequest object to tell development about it. A more common, and much harder to handle, error is a timeout.

A timeout, for those who have been watching Star Gate SG-1 instead of reading about web development, occurs when an application either doesn't respond at all or doesn't respond in a reasonable amount of time. Who defines "reasonable"? You do. Big believer in the 7-second rule? Then use 7 seconds. Like the Hitchhiker's Guide to the Galaxy? Then use 42 seconds. In short, use whatever time period seems appropriate. After you decide this, all that is necessary is to figure out how to handle it.

Personally, I'm fond of using the setTimeout method with a variable set to the result from the method. If the response is received within the specified time limit, clearTimeout can be used to prevent the timeout function from executing. Otherwise, the function specified by the setTimeout method will execute and any problems can be dealt with then. All in all, using the setTimeout method is a rather elegant solution to a potentially fatal problem.

This leaves really only one issue: What to do with those individuals who, for some reason, choose to use Microsoft Internet Explorer? Keep it clean! Yes, we have to accommodate those people in some way, beyond the Click Here to Download option.