Introducing Ajax - Part 2/Page 2

'; figDoc.write(zhtm); figDoc.close(); } // modified 3.1.99 RWE v4.1 -->
[previous] [next]

Introducing Ajax - Part 2

By Ed Woychowsky

2.5.2 The XMLHttpRequest Object

Unlike the hidden frames approach, in which the unload/reload cycle is still there but is tucked out of the way, using the XMLHttpRequest object means finally saying good-bye to the unload/reload cycle that we've all come to know and loathe. This means that, in theory, if not in practice, a single page could conceivably be an entire website. Basically, it's a load-and-go arrangement.

In theory, the original page loads and a user enters information into a form and clicks submit. A JavaScript event handler sends the user's information to the server via XMLHTTP and either waits penitently for a response (synchronous) or sets an event handler for the response (asynchronous). When the response is received, the JavaScript takes whatever action that it is programmed to, including updating parts of the page, hence the lack of an unload/reload cycle or "blink." This is great theory, but a theory is pretty useless if it cannot be put into practice; let's take a look in Listings 2-7 and 2-8 at how this can be implemented from a client-side perspective.

Listing 2-7 Example Ajax Web Page

Listing 2-8 XML Document

If this were CSI, Columbo or The Thin Man, now is the time when the hero explains how the deed was done. It goes something like this: The HTML page loads, which causes the onload event handler, initialize, to fire. In this function, the XMLHttpRequest object's open method is invoked, which only sets the method (POST), gives the relative URL of a web service, and states that the request will be asynchronous (true). Next, the onreadystatechage event handler is set; this is the function that handles what to do when the web service responds. Finally, the send method of the XMLHttpRequest object is invoked, sending our request on its merry way.

When a response is received from the web service, the stateChangeHandler is fired. You've probably noticed the test of the readyState property. The reason for this is that there are more than one possible readyState values, and we're interested in only four, complete. When the response is complete, the result is loaded into an XML document, the appropriate node is selected, and the HTML is updated.

Listings 2-7 and 2-8 could be considered by some a pure example of Ajax. Unfortunately, the way it is currently coded, browsers other than Microsoft Internet Explorer would have real issues with it. What sort of issues? The code simply won't work because of differences in how XML and the XMLHttpRequest object work in various browsers. This doesn't mean that this form of Ajax is an IE-only technology; it simply means that careful planning is required to ensure cross-browser compatibility.

On the subject of compatibility, I don't want to scare you off, but let me point out that the more advanced the client-side coding is, the more likely it is that there will be issues. The majority of these issues are merely little annoyances, similar to flies buzzing around. These "flies" aren't fatal, but it is a good idea to keep these things in mind.

[previous] [next]

URL: