An Ajax Encounter of the Second Kind
As flexible and cross-browser capable as the “hidden frames” method of implementing Ajax is, all that has been accomplished is the “AJ” part of Ajax. Which is sort of like the sound of one hand clapping, and that usually means that Igor has been slacking off again. Thankfully, there’s another parteh, make that technologyavailable: XML. The problem with XML is that it has developed a reputation of being difficult; however, it doesn’t have to be. Just keep in mind that, in those situations, code has a tendency to follow you around, like Igor.
XML
In its simplest form, XML is nothing more than a text file containing a single well-formed XML document. Come to think of it, the same is pretty much true in its most complex form as well. Looking past all of the hype surrounding XML, it is easy to see that XML is merely the text representation of selfdescribing data in a tree data structure. When this is understood, all that is left are the nitty-gritty little details, like “What’s a tree data structure?” and “How exactly does data describe itself?”
A tree data structure is built of nodes, with each node having only one node connected above it, called a parent node. The sole exception to this rule is the root node, which has no parent node. Nodes can also have other nodes connected below, and these are called child nodes. In addition, nodes on the same level that have the same parent node are called children. Figure 2-2 is a graphical representation of a tree data structure.
Figure 2-2. Tree data structure
Figure 2-2 can also be represented as the XML document shown in Listing 2-4.
Listing 2-4. XML Representation of the Same Information as in Figure 2-2
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<library>
<book>
<series>The Wonderland Gambit</series>
<title>The Cybernetic Walrus</title>
<author>Jack L. Chalker</author>
</book>
<book>
<series>The Wonderland Gambit</series>
<title>The March Hare Network</title>
<author>Jack L. Chalker</author>
</book>
<book>
<series>The Wonderland Gambit</series>
<title>The Hot-Wired Dodo</title>
<author>Jack L. Chalker</author>
</book>
</library>
The nodes shown in Listing 2-4 are called elements, which closely resemble HTML tags. And like HTML tags, start tags begin with < while end tags begin with </. However, unlike HTML tags, all XML tags either must have a closing tag or be self-closing or must be empty elements. Self-closing tags are recognizable by the ending />; if the forward slash was omitted, the document would not be a well-formed XML document. In addition, to all elements being either closed or self-closing, the tags must always match up in order. This means that the XML document in Listing 2-5 is well formed but the XML document in Listing 2-6 is not well formed. In a nutshell, “well formed” means that there is a right place for everything. Feet are a good example of this: Imagine if Igor used two left feet; the monster wouldn’t be well formed and wouldn’t be able to dance, either.
Listing 2-5. A Well-Formed XML Document
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<one>
<two>
<three>
<four/>
</three>
</two>
</one>
Listing 2-6. An XML Document That Is Not Well Formed
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<one>
<two>
<three>
<four/>
</two>
</three>
</one>
As neat and nifty as the hidden frames method of communicating with the server is, the addition of an XML document provides another option, XMLHTTP, or, as some refer to it the XMLHttpRequest object. Note all those capital letters, which are meant to indicate that it is important. The XMLHttpRequest object sends information to and retrieves information from the server. Although it doesn’t have to be, this information is usually in the form of XML and, therefore, has the advantage of being more compact than the usual HTML that the server sends. Just in case you’re interested, this was the means of communication for that page that I had handwritten and was using during the “it doesn’t blink” fiasco.
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
<html>
<head>
<title>AJAX Internet Explorer Flavor</title>
<script language="javascript">
var dom = new ActiveXObject('MSXML2.FreeThreadedDOMDocument.3.0');
var objXMLHTTP = new ActiveXObject('Microsoft.XMLHTTP');
/*
Obtain the XML document from the web server.
*/
function initialize()
{
var strURL = 'msas.asmx/getTime';
objXMLHTTP.open('POST',strURL,true);
objXMLHTTP.onreadystatechange = stateChangeHandler;
try
{
objXMLHTTP.send();
}
catch(e)
{
alert(e.description);
}
}
/*
Handle server response to XMLHTTP requests.
*/
function stateChangeHandler()
{
if(objXMLHTTP.readyState == 4)
try
{
dom.loadXML(objXMLHTTP.responseText);
document.getElementById('time').innerText =
dom.selectSingleNode('time').text;
}
catch(e) { }
}
</script>
</head>
<body onload="initialize()">
<div id="time"></div>
</body>
</html>
Listing 2-8. XML Document
<?xml version="1.0" encoding="utf-8" ?> <time>3:30 PM</time>
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.
An Ajax Encounter of the First Kind
Now that I’ve gushed about the why of this technique, let me offer a little insight on the how of this technique. Let’s start with the three HTML documents shown in Listing 2-1, Listing 2-2, and Listing 2-3. Some readers might not consider this a true example of Ajax, but it does share many of the same qualities of Ajax, in much the same way that a Star Trek fan and a Star Wars fan share many of the same qualities.
<html>
<head>
<title>HTMLfs</title>
</head>
<frameset rows="100%,*">
<frame name="visible_frame" src="visible.htm">
<frame name="hidden_frame" src="hidden.htm">
<noframes>Frames are required to use this Web site.</noframes>
</frameset>
</html>
Listing 2-2. visible.htm
<html>
<head>
<title>visible</title>
<script language="javascript">
/*
Perform page initialization.
*/
function initialize() { }
/*
Handle form visible form onchange events. Values from the visible
form are copied to the hidden form.
*/
function changeEvent(obj)
{
parent.frames[1].document.getElementById(obj.id).value = obj.value;
}
/*
Submits the form in the hidden frame then reloads the hidden frame.
*/
function submitForm() {
parent.frames[1].document.getElementById(’hidden_form’).submit();
parent.frames[1].document.location = “hidden.htm”;
}
</script>
</head>
<body onload=”initialize()”>
<form name=”visible_form” id=”visible_form”></form>
</body>
</html>
<html>
<head>
<title>hidden</title>
<script language="javascript">
var reBrowser = new RegExp('internet explorer','gi');
/*
Perform page initialization, waits for the visible frame to load and
clones the hidden form to the visible form.
*/
function initialize()
{
var hiddenForm = document.getElementById('hidden_form');
if(reBrowser.test(navigator.appName))
{
while(parent.document.frames.item(0).document.readyState !=
'complete') { }
parent.frames[0].document.getElementById(’visible_form’).innerHTML =
hiddenForm.innerHTML;
}
else
{
var complete = false;
while(!complete)
{
try
{
parent.frames[0].document.getElementById(’visible_form’).appendChild
(hiddenForm.cloneNode(true));
complete = true;
}
catch(e) { }
}
}
}
</script>
</head>
<body onload=”initialize()”>
<form name=”hidden_form” id=”hidden_form” action=”post.aspx”>
<h1>Address Information</h1>
<table border=”0″ width=”100%”>
<tr>
<th width=”30%” align=”right”>Name: </th>
<td align=”left”>
<input type=”text” name=”name” id=”name” value=”"
onchange=”changeEvent(this)”>
</td>
</tr>
<tr>
<th align=”right”>Address Line 1: </th>
<td align=”left”>
<input type=”text” name=”address1″ id=”address1″ value=”"
onchange=”changeEvent(this)”>
</td>
</tr>
<tr>
<th align=”right”>Address Line 2: </th>
<td align=”left”>
<input type=”text” name=”address2″ id=”address2″ value=”"
onchange=”changeEvent(this)”>
</td>
</tr>
<tr>
<th align=”right”>City: </th>
<td align=”left”>
<input type=”text” name=”city” id=”city” value=”"
onchange=”changeEvent(this)”>
</td>
</tr>
<tr>
<th align=”right”>State: </th>
<td align=”left”>
<input type=”text” name=”state” id=”state” value=”"
onchange=”changeEvent(this)”>
</td>
</tr>
<tr>
<th align=”right”>Zip Code: </th>
<td align=”left”>
<input type=”text” name=”zip” id=”zip” value=”"
onchange=”changeEvent(this)”>
</td>
</tr>
</table>
<br>
<input type=”button” value=”Submit” onclick=”submitForm()”>
</form>
</body>
</html>
A World Unseen
Any developer familiar with the use of frames and framesets will find Listing 2-1 pretty normal looking. However, one item isn’t plain vanilla: the rows=”100%,*” attribute on the frameset element, which states that the first frame gets 100 percent of available rows. The asterisk (*) states that anything left over goes to the second frame. In this example, there is nothing left over, so it is the equivalent of coding zero. This results in the first frame being visible and the second frame being hidden. In essence, this is a sneaky way to hide what’s going on from prying eyesnamely, the user. The next two listings are the visible frame, Listing 2-2, and the hidden frame, Listing 2-3. Listing 2-3 is where the real mad science happens.
Enter JavaScript
Listing 2-2 is short and sweet, basically two short JavaScript functions that don’t appear to do anything. The first of these functions, changeEvent, is just what it says it is, a handler for an on change event. When fired, it copies the value associated with the current object on the current frame to one with the same ID on the hidden frame. The second function, submitForm, submits a form; however, like the previous function, it works with the hidden frame by locating and submitting the form there.
This leaves just one question: Where does the HTML for the visible form come from? The answer lies in Listing 2-3, the one for the hidden frame. Like the visible frame, it has JavaScript functions and a form. There is, however, a major difference in the form. Unlike its visible counterpart, it has all of the HTML necessary to make a nice little form. The trick is getting it from the hidden frame to the visible frame.
This magic is accomplished in the pages’ on load event handler, initialize. This function waits for the other frame to load and then copies this form’s inner HTML to the other frame. When this is done, the result is the normal-looking web page shown in Figure 2-1. The way it behaves, however, is almost application-like, with parts of the visible page being updated each time the hidden frame does an unload/reload cycle.
Figure 2-1. A normal-looking web page that functions almost like a desktop application
