Home ›

Ajax Application Design

Issue 152

From Issue #152
December 2006

Dec 01, 2006  By Reuven M. Lerner
 in
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.

______________________

Comments

Comment viewing options

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

Good article

gds's picture
Submitted by gds on Sun, 12/03/2006 - 17:26.

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:


#!/usr/bin/perl
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);
$select_sth->execute($username);
my ($username_is_taken) = $select_sth->fetchrow_array();

# If this username is defined, say "yes"!
if ($username_is_taken)
{
print "yes";
}
# Otherwise, say "no"!
else
{
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));

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions