Capture an event (such as when a user changes an edit field or presses a button).
Total: <input type="text" id="total" />
document.getElementById('total').value = <some value>;
Listing 1. index.html
Listing 2. getShipping.php
<?php echo "$5.00"; ?>
This first example avoids XML entirely. The following line of code grabs the result as plain text:
results = http.responseText;
Keep in mind that the above example takes as many shortcuts as possible to keep it simple. There is no error checking or error handling whatsoever. There aren't even any HTML tag names, only ids. For example, it would be more common to create an input field that reads <input type="text" name="totalshipping" id="totalshipping" />. You probably wouldn't place the shipping cost in a field that a person could edit (although your form could re-validate the shipping when the person clicked “purchase” to correct any user changes). In addition, the example doesn't actually calculate a shipping cost. The URL in the above code points to a simple PHP script that returns the text value “$5.00” (Listing 2). A real application would take the zip code and use it to calculate the shipping cost and return that value. In short, the example cuts every possible corner to isolate how Ajax works rather than how one should code an Ajax application.
Technically, you can create a full Ajax application without ever using XML, but you will find XML to be a virtual necessity as your Web application grows in complexity. Here is how to do the same simple Web page with XML, once again cutting every corner for the sake of simplicity.
Notice in Listing 3 that we now grab the response with the code http.responseXML and extract the value we want with the code xmlDocument.getElementsByTagName('shipping'). Note also that the XML refers to the total with the tag shipping instead of totalshipping. This difference is unnecessary, but the purpose in this tutorial is to avoid the possible implication that the XML tag name and the HTML input field id must match in order to make the application work. They do not have to match.
Listing 3. index-xml.html
The only thing left is to modify our PHP code to return XML instead of plain text. See Listing 4 for the PHP code. In addition to the XML content itself, note the line of code that sends a header identifying the content as XML before returning the XML content itself. The XML places the shipping amount as a child of <order>, along with the unused data, <total>. This is simply a baby step toward representing a more realistic set of data that the page should return.
Listing 4. GetShippingXML.php
<?php $shipping="$5.00"; $total="$505.00"; $return_value = '<?xml version="1.0" standalone="yes"?> <order> <shipping>'.$shipping.'</shipping> <total>'.$total.'</total> </order>'; header('Content-Type: text/xml'); echo $return_value; ?>
Believe it or not, that's all there is to Ajax. Just about everything else that adds complexity to Ajax application development falls into the following categories.
A real Ajax application would not assume that the PHP file exists. It also would check the validity of the zip code before attempting to send it as a parameter to the server in order to find the shipping cost. (You also could have the server validate the zip code or do minimal validation at the client side, such as ensuring that the user entered five full digits and then perform full validation of the zip code at the server side.)
The above example eschews all error handling in order to keep the focus on the bare bones of how Ajax works. Obviously, you need to include input validation, error detection and error handling in a real application.
The above sample code works with Firefox, but there's no guarantee it will work in any other browser. If you want to write all your Ajax code from scratch, taking into account the variations between Firefox, IE and Opera, buy lots of ibuprofen—you'll need it. Fortunately, a plethora of Ajax libraries exist that manage the differences for you. One of my favorites is Dojo (see Resources).
As for what you must do to handle the services at the server side, that's entirely up to your choice of Web application language and choice of database, among other things. Use what you know best, or take the time to learn other Web application languages you suspect will ease the burden of writing server-side code.
Finally, keep an eye on what you manage at the server side and what you manage at the client side. Depending on what your Ajax Web application does, you may find some performance gains by storing certain information in cookies, or you may speed up performance by storing the information at the server side. Use common sense and experiment between the two approaches to see which performs best.
It's not always easy to build a killer Ajax application, but hopefully this tutorial on the simplicity of how Ajax works will encourage you to give it a try. Now grab a toolkit and go!
Nicholas Petreley is Editor in Chief of Linux Journal and a former programmer, teacher, analyst and consultant who has been working with and writing about Linux for more than ten years.