The xmlHttp object provides the mechanism for asynchronous communication and is a standard that has been created to facilitate this communication. The standard is managed by a working group of the W3C.

XML provides both the request/response mechanism as well as a way to describe the data that’s retrieved. On the one hand, it can be used to retrieve a plain text (usually HTML) response for display using one variation:

xmlHttpRequest. responseText

On the other hand, it can be used to retrieve an XML document using another variation:

xmlHttpRequest.responseXML.getElementById('id')

The only difference between these two is that the data retrieved by the JavaScript, through the xmlHttpRequest object, is unstructured in the first case and structured XML in the second.

As mentioned, there are two steps to using the xmlHttp object—creating the object and testing for compliance with the standards provided for its deployment.

Different browsers use different kinds of xmlHttp objects. In ECMAScript-compliant browsers, the XMLHttpRequest object is part of the language. In other environments, it might be contained in an ActiveX object. This latter approach is the one typically used by Microsoft.

In order to make sure that you perform the right actions without causing the JavaScript to crash, you have to use something called the exception mechanism. Logically speaking, you try to perform a function and then you catch any error that it returns before JavaScript has a change to report the error.

In JavaScript, these two actions are called the try and catch blocks. The exception is the thing that is caught. Bearing that in mind, here is the user-defined CreateXMLHttpObject function:

function CreateXMLHttpObject()
{
  var _xmlHttpObject = null;
  try {
      // ECMAScript compliant object creation
      _xmlHttpObject = new XMLHttpRequest();
  }
  catch (e) {
        // e is the exception, thrown because
        // XMLHttpRequest does not exist.
  try { // try something else
     _xmlHttpRequestObject =
                new ActiveXObject("Msxml2.XMLHTTP");
    }
  catch (e) {
        // e is raised again, obviously the ActiveX approach
        // is not working either, so try another one:
        _xmlHttpRequestObject =
                  new ActiveXObject("Microsoft.XMLHTTP");
      }
   }
   return _xmlHttpRequestObject;
}

If the return value from CreateXMLHttpObject is still null, the last catch block also fails, and there is not a lot you can do about that, so you can just report it and stop the script. Apart from that, the rest of the code should be fairly self-explanatory.

There are some things to remember. First, you need to test whether the global variable that is allocated to the return value of the CreateXMLHttpObject has been set. If it has not been set, you need to reinitialize the xmlHttpRequest object.

If the variable xmlHttp object is still null even after you run the script, you need to set the relevant piece of content to a suitable message on the page. If you do not do that, the visitors are left wondering why their pages do not look quite right.

This can be done using code such as the following:

if (g_xmlHttp == null) {
  document.getElementById("result_area").innerHTML =
     "<b>Your browser does not support xmlHttp requests.</b>";
}

There is a better alternative to this last fragment. You can provide, via an interactive form, an alternative way to get the information. This would move the model from an AJAX model to a synchronous HTTP request/response mechanism.

The way that the system detects that an action needs to take place is via the xmlHttp state change mechanism.

The xmlHttpRequest object has a property that is referenced as follows:

xmlHttpRequest.onreadystatechange

This is a function that can be called whenever the state of the object changes so that it can do some work. A state change can be instigated when data is requested and received or when something else happens.

The function contained in the onreadystatechange property is triggered by a change in an associated property:

xmlHttpRequest.readyState

The states that you’re interested in, and the ones that can be values for the readyState property, are twofold:

The responseText and responseXML properties of the xmlHttpRequest object will contain the appropriate response for the type of data (text or XML) that was returned by the server to the client when the readyState is equal to 4.

However, before you will be ready to process that information, you first need to make a function to handle the state change. The generic skeleton for such a function might look like this:

function xmlHttpStateChange () {
  if (g_xmlHttp.readyState == 4) {
     // Do work here with the responseText or
     // responseXML property
  }
}

The next step is to assign the function to the xmlHttpRequest object through the onreadystatechange property. You do it this way so that other functions can be assigned to the object depending on what you want to do with the response when it comes back. This is achieved with a simple line of code:

g_xmlHttp.onreadystatechange = xmlHttpStateChange;

Of course, you could make the entire solution more object oriented by creating a derived object to put it in, but there is no sense in working harder than necessary to create client side solutions.

Having set up the xmlHttpRequest object, and assigned a function to process the data that comes back in the response, you need to send a request so that you can obtain that response.

This is a two-stage process:

The request can be an HTTP GET or POST, depending on what the server script is expecting. These examples use GET because it’s far easier to explain and exposes the components that will be used as input. The URL is hidden behind the rest of the HTML via the JavaScript, so it is never exposed to the end users.

The URL is built in the usual fashion for this kind of request:

http://www.your_url.com/script.php?first_parameter
           =value&second_parameter=value"

The next step is to call the method that makes the actual request. Assuming that the previous URL is present in an appropriate variable, and that you have initialized a global variable g_xmlHttp using the appropriate object-creation function, the following can be used to open the URL:

g_xmlHttp.open("get", url, true);

The g_xmlHttp variable is an object that must be created as per the JavaScript/ ECMAScript standard discussed in Chapter 5. It can be instantiated with code such as the following:

g_xmlHttp = new XMLHttpRequest();

Finally, you need to send null to the server because you’re not providing any additional data (that is, this is a GET and not a POST request, which would contain the form data). This is performed very simply:

g_xmlHttp.send(null);

The true parameter in the call to the open method means that the script will continue and not wait for response. If you had used false, that would instruct the script to wait for the response. This changes the behavior of the local object, and not the server, so putting in false means that the page might not load properly, as the page would become temporarily unresponsive.

Once the response comes back from the server, the state change property will be updated and the onreadystatechange function (referred to in the property) will be called.

Due to the fact that you have requested that the data be returned asynchronously, at some point in time, the function assigned to the state change property will be called. This will occur in reaction to the state change of the g_xmlHttp object.

At the server side, the response can be either plain text or an XML formatted object. A PHP script will usually return, by default, the text content type, although you can change what’s returned using the header function (to return HTML, for example):

header('Content-Type: text/html'),

When a text variant is provided in the response, the entire response will be accessed via the following object property:

g_xmlHttp.responseText

This property contains plain text, but that may contain fragments of HTML, which can subsequently be directly assigned to any named element through JavaScript, as noted. A div element, for example, could be set up that was previously empty and then have its .innerHTML property set to the text (with or without HTML formatting data) returned through the .responseText property.

The xmlHttpRequest object also provides an interface that equates to a DOMDocument style object, which you first encountered in Chapter 5. This allows you to have standard access to a structured piece of data—in this case, an XML document.

This is brought into play when the header is returned from the PHP script running on the server, as follows:

header('Content-Type: text/xml'),

At this point, you can retrieve the XML document from the following member property of the g_xmlHttp global that you set up in the first place:

xmlDocument = g_xmlHttp.responseXML;

From here, you can access the XML using the usual set of methods through the xmlDocument object, such as:

xmlDocument.getElementById('id1'),

To do this, you need to know the structure of the document that has been returned. Otherwise, it becomes difficult to extract the appropriate data to place in the HTML document that is used as the interface with the end users (the visitors).

The previous discussion described the client side processing, so now you need to look at what happens on the server side when the server receives the request. There is, in fact, nothing special about the HTTP request itself; it is identical to any other request for a resource that it might receive.

The PHP script will be called with the HTML GET protocol, and so the query data, if any, will be in the appropriate superglobal variable. As you’ll remember from previous chapters, this is accessed as follows:

$_GET['parameter_name']

All that you need to do on the server side is perform any processing and return the result by using familiar PHP commands, such as echo to send back the data. This data can be returned as if it were a text or XML stream.

The best way to illustrate this is to go through a whole example by starting with a simple HTML document that provides the interaction among the user, the Web, and the server. You’ll need a text box, a button, and a div to store the result in.

The core of the HTML document can be written as follows:

<form name="table_layout">
Number of Columns : <input type="text" name="columns_entry"/>
<input type="button" onClick="updateColumns();">
</form>
<div id="columns_area">
</div>

The important parts of this document are the button and the div. The update-Columns function attached to the onClick handler of the button has to start the AJAX operation by creating the query and submitting it.

The function can be created as follows:

function updateColumns() {
  if (g_xmlHttp == null) {
     g_xmlHttp = initXMLHttpObject();
  }
  if (g_xmlHttp == null) {
  // not much point continuing
  return;
  }
  var queryURL = "get_columns.php?";
  queryURL += "col=" + document.table_layout.
      columns_entry.value;
  g_xmlHttp.onreadystatechange = columnsChanged;
  g_xmlHttp.open("get", queryURL, true); // Do the AJAX
  g_xmlHttp.send(null); // No data to go
}

The first part of the code tests to see if a g_xmlHttp object exists, and if it does not, the code uses the assumed initXMLHttpObject function to create it. If everything is correctly instantiated, the queryURL is built, and the function columnsChanged is attached to the g_xmlHttp object.

The queryURL contains the name of the PHP script you are going to call and a data part that contains col= followed by the contents of the text control.

This columnsChanged function then has to handle the state change once the data is returned and place the data in the div container of the HTML document. The updateColumns function then sends the request.

This function simply sets the contents of the div container to the responseText of the g_xmlHttp object. The code might look like this:

function columnsChanged () {
  if (g_xmlHttp.readyState == 4) { // We have a response!
    document.getElementById("columns_area").innerHTML
                = g_xmlHttp.responseText;
  }
}

This is all well and good, but you also need to create a PHP script that is run on the server. It has to be able to extract the data fed in by the users and return appropriate text with HTML. The script could be as simple as follows:

<?php
$num_cols = $_GET["col"];
echo "<table border=1><tr>";
for ($col_num = 0; $col_num < $num_cols; $col_num++){
  echo "<td>" . $col_num . "</td>"; // Basic work
}
echo "</tr></table>";
?>

The PHP script extracts the number of columns from the $_GET superglobal, and uses that to construct a table using HTML code, which is then sent back to the client as the response to the original request.

Of course, you could make refinements to this example, but the general procedure remains the same. If you wanted to produce XML instead, for example, by way of the result, you would have to change the way it was both written and interpreted.

You’ll look at this possibility in the “AJAX with Databases” section.

This can be considered as more of a side note than anything else, as well as a kind of best practice style hint. CSS is generally used to provide a consistent user interface, and where AJAX is used, and the response possibly follows a different look and feel, the combination of the two technologies can come into its own.

The main principle is that, when using AJAX, try not to make the server side script produce pure HTML. Otherwise, the JavaScript might have to do some finessing of the HTML to fit it into the look and feel of the page on which it is placed.

Instead, leverage the use of CSS to only change the pure text and let the structure of the document also dictate the style information. That way, if the style changes, the PHP script does not have to change, provided that a consistent use of CSS statements has been established.

Otherwise, it becomes very hard to keep up with the style changes, unless the style information is stored in a database. Because AJAX is built on three different technologies—HTML, JavaScript, and XML—there are potentially three pieces of source code that could change.

Using styles helps to keep these potential changes to a minimum.

Finally, AJAX with server side databases becomes a very powerful tool. It is wise to return the information in a structured way such as XML, rather than as plain text, to cut down on the client side processing.

The reasons for this are that it allows you to keep the client/server interactions down to a bare minimum, and XML can store much more information in a structured manner. It is the mix of AJAX with databases and visitor interaction that is at the heart of many Web 2.0 applications.

If you look at previous example of the blog database, it has the following basic schema:

date, title, summary, content

When you first produce the page, you might populate a form control that contains the dates of all the blog entries. You can do this using AJAX (but this might be overly complex) or using straight PHP to build the Web page. The latter implementation might be coded in a PHP script as follows:

<html>
<head></head>
<body>

<form name="blog_search">
Date : <select name="blog_date"
       onChange="listBlogs(this.value)">
<option value="">
<?php
$db_link
  = mysql_connect('mysql_host', 'mysql_user',
                  'mysql_password'),
mysql_select_db('site_content'),
$query = 'SELECT DISTINCT date FROM
          blog_entries ORDER BY date';
$result = mysql_query($query);
while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
  echo "<option value='" . $line["date"] . ">";
}
?>
</select>
</form>
<div id="blog_list">
</div>
</body>
</html>

This code leaves out any non-essential information, and of course, the final version would have to be better formed, using more correct HTML. However, in the interest of clarity, I have kept the code to a minimum. The core of the page is the SQL query that is used to populate the HTML select control with a series of option drop-downs—one for each date in the fetched result.

Attached to the select control is an onChange handler, which calls a function, listBlogs. Given that you have a range of dates, the listBlogs function becomes easy to implement:

function listBlogs (var blog_date) {
  if (g_xmlHttp == null) {
    g_xmlHttp = initXMLHttpObject();
  }
  if (g_xmlHttp == null) {
  // not much point continuing
  return;
  }
  var queryURL = "get_blogs.php?";
  queryURL += "date=" + blog_date;
  g_xmlHttp.onreadystatechange = blogListChanged;

  g_xmlHttp.open("get", queryURL, true); // Do the AJAX
  g_xmlHttp.send(null); // No data to go
}

This code should be reasonably familiar by now, and does nothing really different except to build a slightly different URL. Finally, the blogListChanged function can be created so that when the xmlHttp request returns, the appropriate HTML code can be built based on the data that is returned by the get_blogs.php function.

Because this data will be XML, you can use the following implementation:

function blogListChanged () {
  var html_out = "<table>";
  if (g_xmlHttp.readyState == 4) {
              // We have a response in XML!
    xmlDoc = g_xmlHttp.responseXML;
    // For each entry, print the date and summary
    var blogItemList = xmlDoc.getElementsByTagName("item");
    var numBlogItems = blogItemList.length();
    for ( var blog_item = 0; blog_item
        < numBlogItems; blog_item++ ) {
        var curr_item = blogItemList.item(blog_item);
        // curr_item is an entry in the NodeList
        html_out += "<tr><td>" + curr_item.childNodes[0].
                             nodeValue + "</td>";
        html_out += "<td>" + curr_item.childNodes[1].
                             nodeValue + "</td></tr>";
      }
   }
   html_out += "</table>";
   document.getElementById("blog_list").innerHTML = html_out;
   }

Note that this example uses the DOMDocument object in JavaScript to access the XML data returned by the PHP script. Note also that I left out the PHP script that generates the XML data based on a query from the database.

It really is not that different from returning a piece of text, except that the header needs to be changed, as previously noted, with the header function. The general layout of the XML should look something like this:

<bloglist>
<item>

   <title>Title</title>
   <content>Content</content>
</item>
</bloglist>

Really, that’s all there is for AJAX. This discussion is just enough for you to get started using it on your own site. The rest of this chapter is dedicated to showing you a few Web 2.0 applications that you can create using AJAX and some other techniques that are already in existence—why work harder than you need to?

Due to the fact that RSS feeds are returned from the HTTP request as XML documents, it becomes easy to integrate feeds of data sources with AJAX on the page, as long as they support the HTTP GET protocol.

This means that a request for a feed will result in an XML object being created that is accessible through DOMDocument in JavaScript and PHP. The latter might make use, for example, of the SimpleXML interface to access the feed, filter it, and return a modified version to the AJAX request object, which then uses JavaScript DOMDocument operations to render the result.

In this way, you should begin to see the power of so-called mashups and Web applications. They reuse lots of different existing technologies and services, one of which is called Yahoo! Pipes.

Yahoo! Pipes is an RSS mashup available at pipes.yahoo.com that allows the users to build applications that are solely centered around processing one or more feeds. The principle is that the pipe starts with a data feed, operates on it, and returns a data feed.

Those familiar with UNIX command-line (csh/bash) programming will realize, of course, that the terminology has its roots in UNIX pipes, which are used to redirect output from processes as input to other processes, all from the command line. This technique is also available in MS-DOS-like operating systems, using, like the UNIX/Linux counterpart, the | (pipe) symbol.

The core of Pipes is a process that enables the users to get a variety of XML feeds and build a set of operations around the data in a visual way. It combines dynamic HTML (JavaScript and styles) and AJAX to provide intermediate results.

One of the uses for Pipes is to integrate the result into your site through AJAX, by requesting the URL that the pipe can be accessed through. The Yahoo! Pipes system then runs the pipe and returns a feed that can be freely used.

The underlying Web 2.0 principle is to obtain one or more feeds, combine them, filter the data or use the feed data for something else (a Web search, for example), and then return a result as a feed. There are many different building blocks allowing the users to enter data, services to be queried, and results manipulated.

For example, one use could be to look for open hub requests on HubPages.com, which is a public feed. Then, you could use one of the Pipes functions to extract the search terms from each of the HubPages.com Request titles. The resulting stream of search terms can then be passed to Google.

The result of the Google search is a Web page, for which there is also a Pipes widget, which enables the users to break the page down into tag values. The results of the search could then be returned as an XML feed. This XML feed can then be embedded, using AJAX, in a static Web page, making it dynamic.