Adding Ajax

Designing a Framework for Your Site

The most important decision facing you now is whether to add Ajax to existing pages or to start from scratch. This book is based on an assumption that web developers begin by introducing Ajax into existing pages and applications rather than scrapping a site and starting anew. In other words, the client-side functionality is adapted, and the server-side component of the site is left as-is, more or less.

The next step in the decision process is to determine the extent of the Ajax modifications. If you're changing a static web page form to one that uses script and XMLHttpRequest to support in-page edits, your use of the new technologies is relatively isolated and will have little impact on the overall site application.

However, if you're adding a site-wide help system, a new dynamic menu, or an in-place search feature, all of your pages will be impacted, and you might want to consider some additional architecture changes, such as splitting out your header and all the script into separate files that can be included in all of your pages. This approach allows you to make sure all of the appropriate JavaScript libraries are included, and allows you to isolate objects like event handlers.

Many of the new content management systems are based on a modular approach that allows you to reuse the sidebar, headers, and footers as much as possible. If your site doesn't use a modular system and the pages are managed manually, you might want to add this to your to-do list for future designs.

Tip

Whether you modularize your web pages or not, all of your custom JavaScript should be created in separate files that are included into the appropriate pages. When you change in the code in a script, it will automatically be propagated out to all the pages using that script.

Meet Your Reader

Earlier, I covered the importance of discovering your web page readers' environments, including their browsers and operating systems, and determining whether they have JavaScript enabled. You'll also need to work through an accessibility plan, including criteria used to judge each web page as it's converted to Ajax. This will help to ensure the plan's requirements are met.

I remember reading somewhere once that you only have to meet the needs of 90 or 95 percent of your web page readers. That may be true of people using older browsers, such as IE 5.5 for the Mac, but it isn't true for people who face enough challenges in life without having more thrust on them just to access your site. This may include:

• The visually impaired, who may use a text-to-speech browser

• Those physically incapable of using a mouse

• People who suffer from color blindness

• The hearing impaired, who may not be able to listen to a podcast or hear auditory instructions

• People with attention-deficit disorder or other learning-comprehension challenges, who may not be able to quickly comprehend fast-moving text or flashed messages

• The tired, time-challenged, distracted, and stressed

In other words, all of us. Your readers may have a hard time reading font that's tiny enough to require a magnifying lens to view. Adding in-page editing or dynamic search functionality doesn't amount to much if you have to cram the additions into a space too small to be readable. Additionally, there are few things more irritating than having to wave the mouse around the page like a magic wand in order to discover where the site's navigation objects are or which elements can be clicked to get access to critical information.

Safe and Secure

A site's readers are also dependent on the developers providing a usable and safe environment. Part of a web site's architecture is the inclusion of test procedures that check to make sure the page is still accessible in all of the target browsers and environments each time a change is added. Included in your upgrade plan should be procedures to stress test the changes.

You should also run tests to make sure the code isn't taking more than its share of space on a reader's computer. Most JavaScript applications use client-side storage for one reason or another and for the most part JavaScript cookies are sufficient for an application's needs. However, several Ajax libraries have provided facilities to store additional data on the client's computer using Flash or some other external storage. When developing your plan, investigate how much data must be stored on the client compared to the server. Client-side storage is an inherent security risk in any web application, Ajax-based or not.

You will also have to include security issues in your plan. As we progress through the book, I'll point out areas of vulnerability with the different Ajax effects we explore. Still, the more moving parts your pages have, the more important it is to monitor sites that issue security releases and test your pages when browsers release updates.

Tip

Since this is a general-purpose book on adding Ajax, I can't provide complete details on security issues. Instead, I recommend Christopher Wells' book, Securing Ajax Applications (O'Reilly), which provides detailed coverage of Ajax and security.

Tight Coupling and Loose Coupling

As part of the framework for adding Ajax, web developers also need to decide on how tightly coupled client and server applications are.

A tightly coupled application is one in which most of the client side of the application is generated by or dependent on the server. In other words, there's no way to really separate the two or the whole thing breaks.

A loosely coupled application, on the other hand, is one in which the web services could be called by an Ajax application, but could likewise be called by another web service. In addition, the client side of the application interfaces only with the API (application programming interface), so it is not affected by how the web service was developed or which language is used.

If you're choosing a loosely coupled solution, it means that you're developing your server application to provide web services that may be called by other server-side applications in addition to an Ajax application. This approach is the most disciplined because it makes no assumption about the capability of the client. A change in the client doesn't impact the server, and a change in the implementation of the server doesn't impact the client.

If, however, you're using a more tightly coupled approach (for example, a Java library such as Google's Google Web Toolkit (GWT), then the tool itself is going to determine the extent of what you can do with the page or even what's generated.

For the most part, if you're adding Ajax to an existing site, you're going the loosely coupled approach. When you're starting from scratch, you have the option to use tight coupling as an approach, though you should be cautious in tying the server and client sides so closely together.