Ajax Application Design

Asynchronous is the operative word with Ajax, and here's what it's all about.

During the past few months, I've used this column to explore a number of technologies and techniques related to Ajax, the asynchronous JavaScript and XML paradigm that is the hottest thing in modern Web development. Everyone is scrambling to include Ajax on his or her sites, and for good reason. For users, Ajax applications appear more responsive and desktop-like. For developers, Ajax is attractive because it breaks the one-page-per-click rule that has existed since the beginning of the Web, making new types of applications possible.

In an Ajax application, a click might force a complete page reload, as in a traditional Web application. But, it might instead fire an HTTP request in the background. The response to this HTTP request is handled (also in the background) by a JavaScript function, which can use the content to modify some or all of the page.

If you have been developing Web applications for a while, you might be wondering what the big deal is with Ajax.> After all, it's neither new nor difficult for a JavaScript function to modify the current page via the DOM, is it? Perhaps not, but sometimes the most powerful ideas result not from fancy technologies, but from the clever combination of simple ones. HTML, HTTP and URLs were all fairly simple inventions, and they might not have gone very far on their own. But by combining them in just the right way, Tim Berners-Lee launched a revolution that continues to this day.

Just as the Web has changed the way that we view publishing and communication, Ajax has changed the way that we expect Web-based applications to work. Fortunately, working with Ajax requires only a few skills above and beyond what Web developers needed to know until now—particularly JavaScript, the DOM and CSS.

Last month, we built a small application that demonstrated the improved usability that Ajax brings to the table. As a visitor filled out the HTML form with a requested user name, a JavaScript function requested (via HTTP) a list of current user names from the server. The HTTP response contained a list of current users. By checking to see whether the newly requested user name was on that list, it was possible to tell the user in advance to choose something else.

This approach had many problems, but the two biggest ones were scalability and security. If our site becomes especially popular, we will have many registered users, so sending a complete list of user names will consume increasing amounts of CPU and bandwidth.

In addition, it is a large security risk to send all of the user names on a site to anyone who requests it. The odds are good that at least one of those users has chosen a poor password, which would make it easy to assume that person's identity. The implications of this security breach depend on your users, your application and your country. Some countries' legal systems might even see this as a prosecutable violation of database privacy laws.

So, for technical and security reasons alike, we need to find a better solution. An obvious candidate, and one we examine this month, involves sending the proposed user name to the server via an Ajax request. The server's response will thus be a short “yes” or “no”, indicating whether the browser should allow or prevent registration.

Ajax Requests

An Ajax application consists of several parts:

  1. A JavaScript function, defined in the Web page, that is invoked when a particular event happens. These event handler functions are common in the JavaScript world, even without Ajax. Before CSS, for example, it was common to use JavaScript to change the src attribute for an img tag whenever the mouse would hover over it (the onmouseover event) or move off of it (the onmouseout event). In the case of Ajax, the event handler function doesn't manipulate the DOM, but rather it sends an asynchronous HTTP request using the XMLHttpRequest object.

    In our example application, the JavaScript function will create an XMLHttpRequest object and use it to invoke a program residing on the server. As a parameter to the request, we will send the contents of the username text field.

  2. A server-side program that expects to receive the HTTP request, along with one or more parameters, and produces an appropriate HTTP response. The response theoretically may be in any legitimate MIME format, although XML, plain text and JSON (JavaScript Object Notation) appear to be the most popular choices. The server-side program will almost certainly not be written in JavaScript. You can choose the language in which you write this program, as well as the method in which it is invoked. The key is that it has access to the resources you need, such as a database, and that it can produce the output in the format you want. In this month's example application, the server-side program takes the username parameter and looks in the database to see if it is already in use. The XML that it returns will indicate its findings.

  3. A second JavaScript function, also defined in the user's Web browser, that is invoked when the HTTP response is received. This callback function, as it is sometimes known, receives the HTTP response and then acts on it. Our callback routine will thus need to parse the Ajax HTTP response and then use the DOM to modify the current page as necessary.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Good article

gds's picture

Really good articles on ajax fundamentals. One comment I have is that it is not pointed out in Part 2 and 3 that the database access, register.pl, is still in effect. It is also easy to change check-name-exists.pl above to use similar database methods as register.pl users:

use strict;
use diagnostics;
use warnings;
use CGI;
use CGI::Carp;
use DBI;
# ------------------------------------------------------------
# # Connect to the database
# ------------------------------------------------------------
my $dbname = 'test';
my $dbuser = 'gene';
my $dbpassword = '';
my $dbh = DBI->connect("DBI:mysql:dbname=$dbname",
$dbuser, $dbpassword,
AutoCommit => 1, RaiseError => 1,
PrintError => 1, ChopBlanks => 1}) ||
print "Error connecting: '$DBI::errstr' ";

# Define the usernames that are taken
# (Use a hash for lookup efficiency)
#my %usernames = ('abc' => 1,
# 'def' => 1,
# 'ghi' => 1,
# 'jkl' => 1);
# ------------------------------------------------------------
my $query = new CGI;
print $query->header("text/plain");
# Get the POST data
my $postdata = $query->param("POSTDATA");
# Get the username
my ($name, $value) = split /=/, $postdata;
my $username = '';
if ($name eq 'username')
$username = $value;
my $select_sql = "SELECT COUNT(*) FROM Users WHERE username = ?";
my $select_sth = $dbh->prepare($select_sql);
my ($username_is_taken) = $select_sth->fetchrow_array();

# If this username is defined, say "yes"!
if ($username_is_taken)
print "yes";
# Otherwise, say "no"!
print "no";

I also change it to use onblur instead of onchange but had to pass a parameter to checkUserName():

function checkUsername(val) {
var username = val; //document.forms[0].username.value;
xhr.send("username=" + escape(username));