Anatomy of an Ajax Application
By Phil Ballard and Michael Moncur
|
In this chapter you will learn about the individual building blocks of Ajax and how they fit together to form the architecture of an Ajax application. Subsequent chapters will examine these components in more detail, finally assembling them into a working Ajax application.
The Need for Ajax
In the following parts of the book, we shall discuss each of the core components in detail.
Before discussing the individual components, though, let's look in more detail at what we want from our Ajax application.
Traditional Versus Ajax Client-Server Interactions
Chapter 1 discussed the traditional page-based model of a website user interface. When you interact with such a website, individual pages containing text, images, data entry forms, and so forth are presented one at a time. Each page must be dealt with individually before navigating to the next.
For instance, you may complete the data entry fields of a form, editing and re-editing your entries as much as you want, knowing that the data will not be sent to the server until the form is finally submitted.
Figure 3.1 illustrates this interaction.
After you submit a form or follow a navigation link, you then must wait while the browser screen refreshes to display the new or revised page that has been delivered by the server.
As your experience as an Internet user grows, using this interface becomes almost second nature. You learn certain rules of thumb that help to keep you out of trouble, such as "don't click the Submit button a second time," and "don't click the Back button after submitting a form."
Unfortunately, interfaces built using this model have a few drawbacks. First, there is a significant delay while each new or revised page is loaded. This interrupts what we, as users, perceive as the "flow" of the application.
Furthermore, a whole page must be loaded on each occasion, even when most of its content is identical to that of the previous page. Items common to many pages on a website, such as header, footer, and navigation sections, can amount to a significant proportion of the data contained in the page.
Figure 3.2 illustrates a website displaying pages before and after the submission of a form, showing how much identical content has been reloaded and how relatively little of the display has actually changed.
This unnecessary download of data wastes bandwidth and further exacerbates the delay in loading each new page.
By the Way: Bandwidth refers to the capacity of a communications channel to carry information. On the Internet, bandwidth is usually measured in bps (bits per second) or in higher multiples such as Mbps (million bits per second).
The Rich User Experience
The combined effect of the issues just described is to offer a much inferior user experience compared to that provided by the vast majority of desktop applications.
On the desktop, you expect the display contents of a program to remain visible and the interface elements to respond to commands while the computing processes occur quietly in the background. As I write this chapter using a word processor, for example, I can save the document to disk, scroll or page up and down, and alter font faces and sizes without having to wait on each occasion for the entire display to be refreshed.
Ajax allows you to add to your web application interfaces some of this functionality more commonly seen in desktop applications and often referred to as a rich user experience.
Introducing Ajax
To improve the user's experience, you need to add some extra capabilities to the traditional page-based interface design. You want your user's page to be interactive, responding to the user's actions with revised content, and be updated without any interruptions for page loads or screen refreshes.
To achieve this, Ajax builds an extra layer of processing between the web page and the server.
This layer, often referred to as an Ajax Engine or Ajax Framework, intercepts requests from the user and in the background handles server communications quietly, unobtrusively, and asynchronously. By this we mean that server requests and responses no longer need to coincide with particular user actions but may happen at any time convenient to the user and to the correct operation of the application. The browser does not freeze and await the completion by the server of the last request but instead lets the user carry on scrolling, clicking, and typing in the current page.
The updating of page elements to reflect the revised information received from the server is also looked after by Ajax, happening dynamically while the page continues to be used.
Figure 3.3 represents how these interactions take place.
A Real Ajax Application-Google Suggest
To see an example of an Ajax application in action, let's have a look at Google Suggest. This application extends the familiar Google search engine interface to offer the user suggestions for suitable search terms, based on what he has so far typed.
With each key pressed by the user, the application's Ajax layer queries Google's server for suitably similar search phrases and presents the returned data in a drop-down box. Along with each suggested phrase is listed the number of results that would be expected for a search conducted using that phrase. At any point the user has the option to select one of these suggestions instead of continuing to type and have Google process the selected search.
Because the server is queried with every keypress, this drop-down list updates dynamically as the user types-with no waiting for page refreshes or similar interruptions.
Figure 3.4 shows the program in action. You can try it for yourself by following the links from Google's home page.
Next let's identify the individual components of such an Ajax application and see how they work together.
By the Way: Google has presented other Ajax-enabled applications that you can try, including the gmail web mail service and the Google Maps street mapping program. See the Google website for details.
