AJAX

Typical web applications interact with the user via forms. The server sends the client a form, the
user enters responses, and the form is submitted back to the server for processing. Once the form
is processed, the server responds with a new complete page, the composition of which is often
dependent upon the users last form submission. In each interaction with the user, an entirely new
page is required. Such applications must use bandwidth, transferring constant page elements (site
navigation, for example) with each page request, even though these elements were sent to the
client in previous responses. Further, such applications are slower than desktop applications,
because the web application is unresponsive while the results of one interaction are being processed
and until the new page loads.
AJAX (Asynchronous JavaScript and XML) refers to a group of technologies that allows for the
creation of fat-client web applications, where the responsibility for a relatively large portion of the
application processing is given to the client. Specifically, AJAX applications often use XHTML and
CSS for semantic markup and presentation, XML to format data that will be exchanged between
client and server, and JavaScript to communicate with the server and manipulate the Document
Object Model (DOM). When using AJAX, communication between the client and the server can be
limited to data only, as the client has the functionality necessary to handle presentation and user
interaction. Further, such communication happens asynchronously and without a page refresh.
This allows for the client-side of the application to remain responsive even while data is being
exchanged with the server. If a user performs an action that requires a request be sent to the server,
the request can be sent and the application can handle further interaction while awaiting a
response (even issuing more requests). This concept is illustrated in Figure 11.1.
Probably the most popular AJAX application today is Googles GMail ( http://www.gmail.com), a
web-based email client. In traditional web-based email clients, nearly every action by the user causes
a refresh of the entire page or frame. Because GMail employs AJAX, the page never refreshes. Rather,
the interface is updated dynamically by manipulating the DOM via JavaScript based on user interaction
with the application and XML communication with the GMail server. This enables, for example,
a user to compose an email, click Send, and continue reading his or her email while the GMail server
handles the actual processing of the sent message. While reading the rest of the email, he or she will
receive a status message indicating that the message was sent successfully.
Figure 11.1

History

AJAX itself is not new; nor is the idea behind it. In fact, many methods have been developed and used
in
the past to communicate with the server without a page refresh.
Page
Traditional Web Application
AJAX Web Application
Page Server
Page
Page
Server
Page

The Image Source Trick

JavaScript allows dynamic loading of images using the Image object. When one creates an image and
sets its src property, the browser sends a request for the image and attempts to package the response
in
the image object. Developers have used this to make one-way communication with a server by setting
the src attribute to the URI of a server-side script, passing data to the server in the query string. The
server-side script might then update a data store. Typically, no image is returned in the response, but
this
does not cause problems, as the developer does not use the Image object for its intended purpose.
The positives of this technique are:
It allows for sending of data to the server without refresh.
It can read properties of the object to determine when request is complete.
However, it does have some drawbacks:

It cannot receive non-graphical data from the server (communication is one-way).

It cannot detect nor handle HTTP errors that may have occurred during the attempted
communication.

Hidden Frames

Many developers found the Image source trick to be inadequate and required the ability to receive
information
from the server in addition to sending to it. Enter the use of a hidden frame. In this technique,
the developer uses a frame with no visibility (by setting either the height or width to 0, depending on
the frameset) as the vehicle. The hidden frame is nothing more than a page with the minimal set of
HTML elements plus a script element. The script element is often simply definitions of arrays and
variables,
the values of which have been written by the server. Thus, the controller frame (the one that is
visible) can set the location property of this frame to that of a server side script, optionally sending
data to it via the query string. The browser then issues this request. The server-side script processes
any passed information in the query string and then writes data in valid JavaScript syntax. Look at the
following code to get the general idea.
<?php
$uname = $_GET[username];
?>
...
<script type=text/javascript>
top.usernameOK = <?php echo isUsernameAvailable($uname); ?>;
top.usernameAlts =
new Array(<?php echo implode(,, getSimilarNames($uname)); ?>);
top.frames[1].readVars();
</script>
...

When the hidden frame loads with the JavaScript, it triggers the controller frame, which can then
access
the variable values written by the server-side script as top.usernameOK and top.usernameAlts:
<script type=text/javascript>
function readVars()
{
alert(top.usernameOK);
alert(top.usernameAlts);
}
self.readVars = readVars;
</script>

This code lives in the controller frame. Wrapping the code in a function that is called by the hidden
communication
frame is one method of triggering the retrieval of data by the loading of the hidden frame.
The upsides to this technique are:
It allows for sending and receiving of data to the server without full-page refresh.
It can trigger retrieval of data by main application as soon as the data are available.
Its simple to use and debug, as all data the application is using is clearly visible in the source of
the hidden frame.
It can receive graphical data, but support for JavaScript variables as image sources is only partially
supported in browsers (IE, for example, likes only XBM image data assigned like this).
Because frame loads add a browser history entry, the user can use the back button. However,
the behavior of the back button might not be what the user expects.
And the downsides are:
It introduces usability problems, such as the inability to easily bookmark an application state.
It can partially detect communication errors by resubmitting requests after a timeout period.
The hidden frames contents could easily be manipulated by the user (this is always a concern,
but it is somewhat easier for the user to do this with the hidden frame technique).
Only one request per hidden frame can be dispatched at a given time (which is a downside if
the response is important).

Hidden IFRAME
Similar to the hidden frame technique is the hidden IFRAME technique. Instead of using a hidden frame
within a frameset, this method uses an invisible IFRAME element, changing its source location to issue
requests to and receive responses from the server. Google Maps uses this technique to communicate

with the server without a page refresh.

276

Chapter 11
The advantages of this technique are:
It has all the pros of the hidden frame technique.
You have a bit more control over the behavior of the back button, depending on how the source
location of the IFRAME is changed.
And the drawbacks are:
It suffers from usability problems similar to the hidden frame technique.
It can partially detect communication errors by resubmitting requests after a timeout period.
Only one request per hidden IFRAME can be dispatched at a given time (a drawback if the
response is important).
There are serious browser differences in how one programmatically adds an IFRAME element
and how one references the document response contained within the IFRAME after a source
location change.