Section 4.1. Changes to the Development Cycle

4.1. Changes to the Development Cycle

There are a variety of ways to use AJAX when integrating it into Web applications. On one end of the spectrum, you can use it to enhance a current site, making small noninvasive changes to an already completed application. On the other end of the spectrum, you have applications that are heavily driven by JavaScript and won't work at all if the user's browser doesn't support AJAX.

Moving to a 100% AJAX application usually isn't an option for a mass-market Web site because browser compatibility issues will cut out too many possible users, but it can be a successful choice for internal projects in which limiting support to one or two browsers is possible. Although browser compatibility can limit the possible choices, it's not the most important factor when deciding how AJAX will be implemented. Developer familiarity with JavaScript and the willingness of developers to make changes to the way they normally develop will usually play a larger role in how AJAX is used.

The more you rely on AJAX, the larger the changes will be. In an enhancement-only scenario, the largest impact will be the additional testing that is needed, whereas in a 100% AJAX application, all aspects of developmentincluding design, implementation, and testingwill be affected. The amount of testing needed in any scenario is also affected by the number of browsers that need to be supported. In single-browser scenarios, testing can be focused solely on the new AJAX widgets and user interactions, whereas in a multiple-browser scenario, differences between browsers need to be tested as well; if older browsers are supported, then fallback scenarios also need to be tested.

4.1.1. Enhancement-Driven Changes

AJAX is typically used to enhance a current Web site after the site has been developed to a fully functional state. Specific areas where AJAX could improve user experience are chosen and then optional code is used to add AJAX to those areas. Examples include adding an AJAX-driven pull-down element to a search box that shows matching options as the user types or providing a way to validate that a username isn't already in use without submitting an entire form. Many AJAX libraries encapsulate all the functionality needed for features like these, making the only implementation and design challenge the integration of a new library. While this can be difficult depending on the framework in use, it's not really any different from supporting any other third-party library. If an AJAX library is not used, any implementation will make some major changes to your normal application development cycle; be sure to set time aside to create the needed infrastructure pieces.

Large amounts of JavaScript development can be especially disruptive for groups using unit testing or other automated testing tools. The disruption is caused by the lack of JavaScript support in normal testing tools. Unit testing of JavaScript is possible, but it may be hard to integrate into existing testing frameworks because it needs to run in a browser. In addition, it may need to run in different browsers to cover differences between them. Although getting JavaScript unit tests integrated into an existing framework can be a difficult task, it does have a large payoff because it helps hide many of the debugging differences that AJAX adds.

You'll find that even bringing in a small amount of AJAX leads to huge differences in debugging. These changes are caused by two main items:

• A larger amount of logic is encapsulated in JavaScript, which creates a second area to test code for problems. This testing process can be further complicated by the need to learn new tools because few Integrated Development Environments (IDEs) support JavaScript. This leads developers to rely more heavily on debugging tools that are built into browsers.

• The communication process is hidden. When you are loading a normal page, logic errors and debugging messages can be immediately shown, but with AJAX communication, these errors need to be caught in the JavaScript code and handled before they are visible. This makes logging problems at the server level more important and removes the direct feedback that most Web development languages provide.

When adding any amount of AJAX to a Web application, you can expect longer development and testing cycles. If AJAX libraries are used, the amount of additional time needed is about the same as adding any other feature. If all the development is new, then testing time will be increased, as more testing of basic functionality will be needed. Because more features are being added, implementation time is increased, but no other large changes are introduced. (These bolt-on features require little JavaScript to be coded once the basic infrastructure is in place.)

4.1.2. AJAX in Action: Removing a Popup User Search

A common task in many Web sites is selecting a user on which to perform an action. This task is especially common when dealing with permissions systems, where you can spend a large amount of time selecting users to add to groups or to update the permissions on. If the site contains only a small number of users, this can be accomplished by an HTML select box, but after a hundred or so users, this becomes less useful. It becomes less useful because of the time it takes to scroll through the list and find the item in question and because of the large amounts of data that need to be transferred for each box. One solution is to provide a link that opens a new page where the search can be done; the new page would then return the selected user. Although this scales to large numbers of users, it does have the disadvantage of taking a long time to select each user. An easy solution to this problem is to allow users to search directly on the page using AJAX.

AJAX searching can be achieved by putting an entire search form right on the page and submitting it over AJAX, or it can be done by building a combo box-style search box. As the user types, AJAX search requests are sent and the results are used to build a dynamic pull-down list below the text-input box. An example of this is shown in Figure 4-1. If this is the only AJAX you're adding to an application, it will require the following actions:

• Addition of an AJAX communication layer (usually provided by a library)

• Additional JavaScript and HTML code for building the drop-down elements

• New entry point to the application for getting unformatted search results

• Testing of the new feature

• Testing of the fallback to the old pop-up in non-AJAX browsers

Figure 4-1. AJAX-driven user selection

As you can see from the list of actions, there are no wildly different additions to the development cycle. You just need some extra time to add in this AJAX feature. The biggest changes caused by this addition are the new entry point for your AJAX search and any debugging hassles caused by it.

4.1.3. Changes Caused by Creating an AJAX-Driven Application

AJAX can be useful when used as an enhancement tool that is targeted at specific tasks that are slow or hard to do within the normal Web environment. However, AJAX is most powerful when you rethink how you build Web sites and design it into the application from the ground up. This allows you to move from a design built on full-page reloads to an event-driven application where events drive small areas of the application to update. Requiring AJAX for your application does limit which browsers you can support, but in many circumstances, the tradeoff is worth it, because it allows you to create applications that are not possible in a normal Web application model.

Creating an AJAX-driven application is a much larger shift than just sprucing up a site with AJAX. One of the most invasive changes you'll find is the removal of the page concept from the application. In a normal Web application, you would go to the /list/users.php URL, and that page would generate HTML to show a table of users. In our AJAX-driven application, an event will be fired (maybe by clicking a button) that will cause JavaScript to load user data using AJAX and then update an existing table using the JavaScript Document Object Model (DOM). Depending on your design, the /list/users.php page on the server might still exist. However, it would now just output the data needed, not an entire page. The main shift here is moving the logic that puts together the different data sources from your server to the client.

This shift will have a number of effects on your server-side development efforts. Because you will no longer be generating HTML at each URL, you'll find yourself in a model where you're building an API instead of a bunch of pages. This will have a large effect on most development frameworks, because the front controller will lose command over the actual HTML-generation aspects of the page and instead will focus on data aggregation and security. By the same token, security handling will move to different parts of the application. Because much of the HTML generation will now be handled on the client, you will no longer rely on it to filter out records the user shouldn't be able to access. Although most people won't edit the JavaScript code that drives your application, there is nothing stopping them from doing so; therefore, security checks and filters that are implemented in JavaScript could be removed easily by a determined foe.

The heavy focus on JavaScript will also be a change for many developers; reusable widgets that were created in a template language before will now need to be moved to JavaScript constructs. You'll also find it harder to stay away from JavaScript functions that have inconsistencies between browsers. This is especially true of JavaScript events, because they are at the heart of any event-driven application. Events do work well in all new browsers, but there are some differences, especially with change events that make them unreliable when used by themselves. In most cases, a bit of research will find workarounds to these cross-browser problems, but this aspect will likely be an annoyance during development and will surely increase the amount of testing that needs to be done.

Testing needs will increase as you make a more complex user interface (UI), but this process is relatively straightforward; if you already implement a detailed testing plan, this won't be much of a change. The biggest difference is that more interaction is needed with the elements on the page to test their interactivity. The JavaScript-to-server communication layer also becomes a new point of testing. You will need to make sure that your application handles communication errors properly because you'll be handling them now (instead of leaving them to the browser). The actual testing of the server side will also be a change for developers who are not currently using some type of unit testing processes. In an AJAX application, it is important to be able to test the server separately from the client because this greatly reduces complexity during the debugging process.

An AJAX-Driven Application Use Case: Mp3act

Mp3act is an open source music management system; it allows you to search, browse, and stream music stored on a server. Although it's not as popular as client-side music management systems, such as iTunes, server-side music management does have a thriving niche, and there are many implementations of this same process using a normal Web development model.

Mp3act fully removes the page concept from the application; the application is divided into two independent sections. One section is the navigation bar, which contains links between major aspects of the application, such as search and playlists. The other section is the content area that is updated as needed, either from links in the navigation area or from an action performed inside the content.

Mp3act provides feedback while waiting for data to load so that the user knows something is happening. (This feedback is useful because the Web browser's loading throbber never moves.) This status message is shown in Figure 4-2; this consistent messaging is used throughout the application and is one of the interface touches that any good AJAX-driven application needs.

Figure 4-2. Mp3actloading status shown switching to Playlists view

Mp3act performs two major types of AJAX actions: loading new application sections where large amounts of HTML are replaced, and dynamically updating tables. Figure 4-3 shows a table being dynamically updated; the plus button (on the right) is clicked, which adds the songs in the table to the playlist. The new songs are highlighted in green, showing the user that an action has been performed. (The highlight fades away in a couple seconds.) Items can also be deleted from the playlist and can be reordered using the arrow buttons. (Similar highlights with fade affects are used throughout the application.)

Figure 4-3. Mp3actadding an album to a playlist

When compared to a similar application developed without AJAX, Mp3act requires a large number of development changes, such as the following:

• Addition of an AJAX communication layer

• Creation of a JavaScript playlist widget

• Visual-effect JavaScript code for fading highlights and loading messages

• Creation of a data-driven API on the server

• Increased testing of rich UI features, such as reordering

• Cross-browser testing

• Loss of support on browsers that do not support AJAX

Although AJAX causes development changes, Mp3act's overall development timescale isn't necessarily longer than a non-AJAX version would require. Because Mp3act was conceived as an AJAX application from the start of its development and because its developers never planned for it to support non-AJAX capable browsers, its development process can skip normal Web-development work, such as building forms to reorder lists.

The one area that might still be overly time-consuming is the processing of developing good cross-browser support. In fact, in the original Mp3act release, Internet Explorer (IE) didn't work at all. Resolving these cross-browser issues, which involved items from XMLHttpRequest differences to various ways to create visual effects, could have been easily accomplished by using a library. However, some cross-browser issues, such as CSS layout, have no easy solution. Even if the overall development time is longer than for a non-AJAX version, the end result a usable, attractive application that works the way a user expectsseems well worth it.