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.
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.
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.
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 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.
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.
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.