Introducing Ajax | Page 2
'; figDoc.write(zhtm); figDoc.close(); } // modified 3.1.99 RWE v4.1 -->
2.3 What Is Ajax?
2.3.1 The Ajax Philosophy
How the client—in this case, a web browser—communicates with the server is one of the cornerstones of Ajax. Designed with the philosophy of not using bandwidth just because it's there, a web page coded using these techniques won't go through the unload/reload cycle, or "blink," as some refer to it, unless absolutely necessary. Why send 100,000 bytes back and forth to the server when 300 bytes will suffice?
Of course, this means that, to the casual observer, the browser is behaving strangely because sometimes only selected parts of a web page are updated. This means that the page won't "blink," as the peasant—er, client—so elegantly put it. Instead, in a wink of an eye, parts of the page will update quicker than they believed possible. The speed difference can be compared to the difference between accessing a file on a floppy disk and accessing a file on the hard disk. Personally, my reaction was along the lines of "I am never going back!" But individual results can vary, so consult your doctor.
With an Ajax application, the browser is expected to actually process the data supplied by the server. This means not only the little things that DHTML did, such as rollovers and hierarchical drop-down navigation menus, but real things, such as posting to the server and handling the response, whether it is handling it either synchronously or asynchronously. In addition, Ajax applications need to be able to not only find objects on the HTML page but also, if necessary, update them.
This leads to the question of how, short of the whole kites and Igor methodology, does one accomplish this unholy task? The answer is that it depends on just how and how far one wants to pursue this course. There are three ways to bring life to an Ajax application, and each has its own advantages and disadvantages. It all depends on just which parts of the Ajax toolset the developers are comfortable with. It also depends on how comfortable you are with excluding certain members of the planet from the application. Yes, I'm talking about those people who are still running Internet Explorer version 2.0. Fortunately, it isn't my job to issue decrees concerning browser compatibility; however, it is my job to cover how to implement an Ajax application.
2.3.2 Meddling with Unnatural Forces
Earlier I explained how I, and probably quite a few others, stumbled upon the then nameless technique that was to become Ajax. However, that was not my first brush with what my supervisor called "mad scientist stuff." Several years earlier, as a consultant for the group insurance division of a large insurance company, I had the good fortune to get the assignment to automate a paper-based request system.
Armed with a file layout, salespeople would try to sell group insurance to companies and, theoretically, would explain that enrollee information needed to conform to the file layout. However, possibly in an effort to make the sale and thereby get the commission, they would accept it in any conceivable electronic format. XML, Excel, or flat files—it was all the same to them because they would fill out a multipage form and the minions in systems would take care of it. Needless to say, quite a few of these pieces of paper got lost, got coffee spilled on them, or simply got filed under "it's real work and I don't want to do it" by the folks in systems.
Here's how it worked: The user would enter multiple pages of information concerning the request. This information would be cached on the client side until the user reached the end of the chain of pages and clicked the final submit button. The caching was accomplished through the use of HTML frames; the first frame, as the user input frame, filled the entire browser's window. However, the second frame, the data frame, was the interesting one because it wasn't visible even though it was always there.
This trick, for lack of a better word, with hidden frames was that they had the advantage of speeding up the application. The speeding up was due to reduced interaction with both the web server and the database server. Another benefit was that, in addition to the performance improvements, the application seemed to flow better because the input was broken into convenient chunks instead of the usual approach of entering between 80 and 200 items at one time.