AJAXWorld News Desk

One of the most annoying things about the Web page paradigm is that you have to reload the page whenever you want to do something on the server side. If you want to do a site search, it's sprinkled across two pages.

On the first page, the user will enter a search term, then clicks a submit button to get to the second page where the search results are returned. If the user wants to filter or sort the search results it's usually refreshed again and each result is redisplayed in its filtered state.

Lately there's been a movement to help improve the Web by eliminating these constant page refreshes. Macromedia's Rich Internet Application (RIA) push with Flash and Flex has been at the forefront of this effort, however Flex' entry price has made it prohibitive for many ColdFusion Developers. That's where AJAX comes in. It's an alternate way to create a RIA and relies on technologies built into most browsers, making it completely free.

Dissecting AJAX
AJAX stands for Asynchronous JavaScript and XML. It's not a single technology, but rather a combination of different technologies that are used to create a Rich Internet Application feel. You've probably seen examples of this kind of application. Google uses AJAX a lot on such services as maps.google.com. After bringing up a location, you can click and drag the map, zoom in or out, or even bring up directions to and from the location. All this is done without any screen refreshes. You have to admit that the interface is pretty sweet. (Note: Yahoo has a similar mapping application, built entirely in Flex at http://maps.yahoo.com/beta.)

Since AJAX is a combination of technologies you're going to want to know what you're getting into before going any farther, right? I thought so. Here's the list:

• XHTML: To start with you need a display language. Most resources on AJAX say you have to use XHTML, but regular HTML will work too.
• XMLHttpRequest: The XMLHttpRequest object lets you retrieve data from the server without refreshing the page. It's a JavaScript object implemented in most major browsers. As the XMLHttpRequest object is being called, the user can do other things on the page. This is where the "asynchronous" part of the acronym comes in.
• iFrames: iFrames are in-line frames and are sometimes used as an alternative to the XMLHttpRequest object. A regular frame will divide the browser window into multiple separate pages, but an in-line frame embeds one page inside another. I won't get into any iFrames details in this article.
• XML: You all know what XML is, right? As a refresher, it's a way to describe data. If you need more details, read the article in this column from August 05 at http://coldfusion.sys-con.com/read/117667.htm.
• Document Object Model: The document object model defines your HTML page through a programmer API.
• JavaScript: I'm sure you all know what JavaScript is too. It's the most common language used for providing client-side functionality to HTML pages.

How do all these different technologies work together using AJAX? Well, it generally works something like this:

1. First, the user comes to your page and the page loads. Something (depending on what your page does) is loaded and displayed to the user.
2. The user does something such as clicking a link. Instead of reloading the page (as would happen in a normal Web app), that link fires off a JavaScript function.
3. The JavaScript function uses XMLHttpRequest object to retrieve XML data from the server.
4. Then the JavaScript parses the XML Data and through the Document Object Model will change the page without a refresh.

So the user gets to see more data quicker without the annoying page refreshes. That's fantastic, right? Why isn't everyone using this? Well, as with all things, AJAX isn't perfect. There are drawbacks:

• Development Time: Working with AJAX will bring you back to the old days of Web development, especially if you want any kind of cross-compatibility. There are different syntaxes for creating the XMLHttpRequest object in IE vs Netscape/Firefox, which can lead to extended development times.
• User Experience: When used properly, an AJAX can enhance the user experience. However, when used improperly it can make it horrendous. Since the page isn't reloading, what happens when the user hits the back button? He'll leave the application altogether. I bet he expected to go to the app's "previous state." What happens when the user bookmarks a page? He'll go the "initial" state of the app. There are workarounds, of course, but they're not trivial to implement.
• Searches: The single-page nature of the app makes indexing by search engines a tetchy proposition at best.
• Response Times: The very thing that works for you (no page reloads) can also work against you. What happens if you're retrieving a lot of data from the server? And the user is given no indication that something is happening.
• JavaScript: JavaScript must be enabled for an AJAX app to work. If JavaScript is disabled, your user isn't going to have a lot of fun with an AJAX app.
• Accessibility: AJAX is, most likely, not going to meet accessibility guidelines. If this is a goal of your project you're going to have to provide a fallback option. That means developing two paths to the same goal.

There are a few real simple examples of AJAX that you've probably used or seen that existed long before the term AJAX was conceived. Have you ever rolled your mouse over a graphic navigation button only to have that graphic change? JavaScript rollovers can be considered a precursor to AJAX. They do use JavaScript and they do change the state of the page. Have you turned on or off a DHTML layer on a page based on some selection by the user? This is another example of AJAX. If an application has a select box with an "other" option in it I'll often use DHTML to display an input text box if "other" is selected. If other isn't selected the input box is hidden. Both of these are simple examples of changing the page without a screen refresh. They don't go out to the server to get data, but they still fit the RIA paradigm.

Putting This All Together
Let me show you how this all comes together, so you can actually do something useful. The first step in the process is to initialize the XMLHttpRequest object. Unfortunately, there's not consistent way to do this across browsers:

<script language="javascript" type="text/javascript">
var request = false;
try {
     request = new XMLHttpRequest();
}
catch (trymicrosoft) {
   try {
     request = new ActiveXObject("Msxml2.XMLHTTP");
}
catch (othermicrosoft) {
   try {
     request = new ActiveXObject("Microsoft.XMLHTTP");
   }
    catch (failed) {
     request = false;
    }
  
}
</script>

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...