List of Figures

Chapter 1. A new design for the Web

Figure 1.1. This desktop spreadsheet application illustrates a variety of possibilities for user interaction. The headers for the selected rows and columns are highlighted; buttons offer tooltips on mouseover; toolbars contain a variety of rich widget types; and the cells can be interactively inspected and edited.

Figure 1.2. Schematic architectures for a standalone desktop application. The application runs in a process of its own, within which the data model and the program logic can “see” one another. A second running instance of the application on the same computer has no access to the data model of the first, except via the filesystem. Typically, the entire program state is stored in a single file, which is locked while the application is running, preventing any simultaneous exchange of information.

Figure 1.3. Schematic architectures for client/server systems and n-tier architectures. The server offers a shared data model, with which clients can interact. The clients still maintain their own partial data models, for rapid access, but these defer to the server model as the definitive representation of the business domain objects. Several clients can interact with the same server, with locking of resources handled at a fine-grain level of individual objects or database rows. The server may be a single process, as in the traditional client/server model of the early- to mid-1990s, or consist of several middleware tiers, external web services, and so on. In any case, from the client’s perspective, the server has a single entry point and can be considered a black box.

Figure 1.4. Amazon.com home page. The system has remembered who I am from a previous visit, and the navigational links are a mixture of generic boilerplate and personal information.

Figure 1.5. Amazon.com book details page. Again, a dense set of hyperlinks combines generic and personal information. Nonetheless, a significant amount of detail is identical to that shown in figure 1.4, which must, owing to the document-based operation of the web browser, be retransmitted with every page.

Figure 1.6. Sequence diagram of a local procedure call. Very few actors are involved here, as the program logic and the data model are both stored in local memory and can see each other directly.

Figure 1.7. Sequence diagram of a remote procedure call. The program logic on one machine attempts to manipulate a data model on another machine.

Figure 1.8. Sequence diagram of a synchronous response to user input, during my morning routine. In a sequence diagram, the passage of time is vertical. The height of the shaded area indicates the length of time for which I am blocked from further input.

Figure 1.9. Sequence diagram of an asynchronous response to user input. If I follow an asynchronous input model, I can let the children notify me that they are starting to wake up. I can then continue with my other activities while the wakeup happens and remain blocked for a much shorter period of time.

Figure 1.10. Development of the modern bicycle

Figure 1.11. Lifecycle of a classic web application. All the state of the user’s “conversation” with the application is held on the web server. The user sees a succession of pages, none of which can advance the broader conversation without going back to the server.

Figure 1.12. Lifecycle of an Ajax application. When the user logs in, a client application is delivered to the browser. This application can field many user interactions independently, or else send requests to the server behind the scenes, without interrupting the user’s workflow.

Figure 1.13. Breakdown of the content delivered (A) to a classic web application and (B) to an Ajax application. As the application continues to be used, cumulative traffic (C) increases.

Figure 1.14. Interrupting the user’s workflow to process events. The user deals with two types of object: those relating to their business, and those relating to the computer system. Where the user is forced to switch between the two frequently, disorientation and lack of productivity may occur.

Figure 1.15. The Google Maps home page offers a scrolling window on a zoomable map of the United States, alongside the familiar Google search bar. Note that the zoom control is positioned on top of the map rather than next to it, allowing the user to zoom without taking his eyes off the map.

Figure 1.16. Google Maps hotel search. Note the traditional use of the DHTML technologies to create shadows and rich tooltip balloons. Adding Ajax requests makes these far more dynamic and useful.

Chapter 2. First steps with Ajax

Figure 2.1. The four main components of Ajax: JavaScript defines business rules and program flow. The Document Object Model and Cascading Style Sheets allow the application to reorganize its appearance in response to data fetched in the background from the server by the XMLHttpRequest object or its close cousins.

Figure 2.2. Using CSS to style a user interface widget. Both screenshots were generated from identical HTML, with only the stylesheets altered. The stylesheet used on the left retains only the positioning elements, whereas the stylesheet used to render the right adds in the decorative elements, such as colors and images.

Figure 2.3. The DOM presents an HTML document as a tree structure, with each element representing a tag in the HTML markup.

Figure 2.4. Inspecting the style attribute of a DOM node in the DOM Inspector. Most values will not be set explicitly by the user but will be assigned by the rendering engine itself. Note the scrollbar: we’re seeing only roughly one-quarter of the full list of computed styles.

Figure 2.5. Sequence of events in an asynchronous communication in a web page. User action invokes a request from a hidden requester object (an IFrame or XMLHttpRequest object), which initiates a call to the server asynchronously. The method returns very quickly, blocking the user interface for only a short period of time, represented by the height of the shaded area. The response is parsed by a callback function, which then updates the user interface accordingly.

Figure 2.6. A simple Ajax application will still work like a web page, with islands of interactive functionality embedded in the page.

Figure 2.7. In a more complex Ajax application, the entire application is an interactive system, into which islands of document-like content may be loaded or programmatically declared.

Chapter 3. Introducing order to Ajax

Figure 3.1. Schematic of the Façade pattern, as it relates to the XMLHttpRequest object across browsers. The loadXML() function requires an XMLHttpRequest object, but doesn’t care about its actual implementation. Underlying implementations may offer considerably more complex HTTP Request semantics, but both are simplified here to provide the basic functionality required by the calling function.

Figure 3.2. Division of responsibility in the Observer pattern. Objects wishing to be notified of an event, the Observers, can register and unregister themselves with the event source, Observable, which will notify all registered parties when an event occurs.

Figure 3.3. Using the Command pattern to implement a generic undo stack in a word processing application. All user interactions are represented as commands, which can be undone as well as executed.

Figure 3.4. In our example Ajax trading application, both buy/sell and analysis functions determine whether to use real or simulated data based on a TradingMode object’s status, talking to the simulation server if it is in amber mode and to the live trading server in green mode. If more than one TradingMode object is present in the system, the system can end up in an inconsistent state.

Figure 3.5. The main components of the Model-View-Controller pattern. The View and Model do not interact directly but always through the Controller. The Controller can be thought of as a thin boundary layer that allows the Model and View to communicate but enforces clear separation of the codebase, improving flexibility and maintainability of the code over time.

Figure 3.6. Main components used to generate an XML feed of product data in our online shop example. In the process of generating the view, we extract a set of results from the database, use it to populate data structures representing individual garments, and then transmit that data to the client as an XML stream.

Figure 3.7. A many-to-many relationship in a database model. The table Colors lists all available colors for all garments, and the table Garments no longer lists any color information.

Figure 3.8. MVC as it is commonly applied in the web application. The web page/servlet acts as the Controller and first queries the Model to get the relevant data. It then passes this data to the template file (the View), which generates the content to be forwarded to the user. Note that this is a read-only situation. If we were modifying the Model, the flow of events would differ slightly, but the roles would remain the same.

Figure 3.9. The Rico framework Behaviors allow plain DOM nodes to be styled as interactive widgets, simply by passing a reference to the top-level node to the Behavior object’s constructor. In this case, the Accordion object has been applied to a set of DIV elements (left) to create an interactive menu widget (right), in which mouse clicks open and close the individual panels.

Chapter 4. The page as an application

Figure 4.1. Model-View-Controller applied to the internal functioning of a tree widget. The view consists of a series of painted-on-screen elements composed of DOM elements. Behind the scenes, the tree structure is modeled as a series of JavaScript objects. Controller code mediates between the two.

Figure 4.2. Model-View-Controller applied to the Ajax client application as a whole. The Controller at this level is the code that links the UI to the business objects in the JavaScript.

Figure 4.3. Nested MVC architecture, in which the pattern repeats itself at different scales. At the outermost level, we can see the pattern defining the workflow of the application as a whole, with the model residing on the web server. At a smaller scale, the pattern is replicated within the client application and, at a smaller scale than that, within individual widgets in the client application.

Figure 4.4. Musical keyboard application running in a browser. The colored areas along the top are mapped to music notes, which are printed out in the lower console area when the mouse moves over them.

Figure 4.5. Our revised musical keyboard program allows the designer to specify multiple keyboards. Using CSS-based styling and the native render engine, we can accommodate both vertical and horizontal layouts without writing explicit layout code in our JavaScript.

Figure 4.6. The Mousemat program tracks mouse movement events on the main “virtual mousemat” area in two ways: by updating the browser status bar with the mouse coordinates and by moving the dot on the thumbnail view in sync with the mouse pointer.

Figure 4.7. Here the ObjectViewer is used to display a hierarchical system of planets, each of which contains a number of informational properties, plus a list of facts stored as an array.

Chapter 5. The role of the server

Figure 5.1. An Ajax application moves some of the responsibilities of the presentation tier from the server up to the browser, in a new entity that we call the client tier.

Figure 5.2. Web programming without a framework. Each page, servlet, or CGI script maintains its own logic and presentation details. Helper functions and/or objects may encapsulate common low-level functionality, such as database access.

Figure 5.3. Model2 web framework. A single controller page or servlet accepts all requests and is configured with a complete graph of user workflows and interactions. The request will be handed to one of a number of ancillary classes or functions for more specialized processing and finally routed out to a View component (for example, a JSP or PHP page) before being sent to the browser.

Figure 5.4. Architecture of a component-based web framework. The application is described as a collection of widgets that render themselves by emitting a stream of HTML and JavaScript into the browser. Each component contains its own small-scale Model, View, and Controller, in addition to the larger Controller that fields browser requests to individual components and the larger domain model.

Figure 5.5. Comparison of a system in which all objects are fully exposed as Internet services to an Ajax client and one is using a Façade to expose only a few carefully chosen pieces of functionality. By reducing the number of publicly published methods, we can refactor our domain model without fear of breaking client code over which we have no control.

Figure 5.6. Screenshot of planetary info application, in which pop-up windows describing each planet can be brought up by clicking on the icons.

Figure 5.7. Content-centric architecture in an Ajax application. The client creates an IFrame and launches a request to the server for content. The content is generated from a Model, View, and Controller on the server presentation tier and returned to the IFrame. There is no requirement for a business domain model on the client tier.

Figure 5.8. Script-centric architecture in an Ajax application. The client application makes a request to the server for a fragment of JavaScript, which it then interprets. The client app exposes several entry points for generated scripts to hook into, allowing manipulation of the client by the script.

Figure 5.9. In a data-centric system, the server returns streams of raw data (XML in this case), which are parsed on the client tier and used to update the client tier model and/or user interface.

Chapter 6. The user experience

Figure 6.1. Various conventions for providing status information in a user interface: modifying the icons to reflect particular characteristics (here access permissions), a status bar providing summary information, and a modal dialog. The interface shown here is the KDE desktop for UNIX workstations, but similar conventions are found in most popular graphical interfaces.

Figure 6.2. Status bar user interface for our notification system. Individual messages are represented by their icons.

Figure 6.3. Messages on the status bar can be inspected by rolling the mouse over the icon, causing a tooltip to appear.

Figure 6.4. Higher-priority messages are shown in a pop-up dialog, in which messages are listed in order of priority.

Figure 6.5. Using CSS float attributes allows a list of icons to fit into a variety of shapes of container. Here we have changed the status bar to a square, and the cross and blue sphere icons on the left wrap themselves into the new area automatically, while the launcher for the dialog floats to the right.

Figure 6.6. A successfully loaded resource will be displayed as a tooltip on the status bar.

Figure 6.7. An unsuccessful network request will result in the notification dialog being shown. (There are two messages shown here, the second of which is a network error notification.)

Figure 6.8. The modified ObjectViewer displaying a recently edited value for the diameter property, which is styled to have a colored background. The styling will disappear after a short period of time, when the edit is no longer new and noteworthy.

Chapter 7. Security and Ajax

Figure 7.1. The JavaScript security model prevents scripts from different domains from interacting with one another.

Figure 7.2. A security warning dialog is shown in Internet Explorer if the code tries to contact a web service not originating from its own server. If the user agrees to this interaction, subsequent interactions won’t be interrupted.

Figure 7.3. If an Ajax application needs to access resources from other domains, the server of origin can proxy the resources on the Ajax client’s behalf.

Figure 7.4. Using the Google SOAP API in a simple Ajax application to entirely frivolous ends. The user can try to enter a phrase that will return an estimated number of results from Google within the specified range.

Figure 7.5. Requesting additional security privileges in the Firefox browser will result in a dialog being displayed, with a standardized warning message.

Figure 7.6. In an ordinary HTTP transmission, data is transmitted across the Internet in plain text, allowing it to be read or modified at intermediate nodes by the man in the black hat.

Figure 7.7. Using a secure HTTP connection, data is encrypted in both directions. Intermediate nodes still see the encrypted data but lack the necessary key to decrypt it.

Figure 7.8. In an Ajax architecture, the server exposes web services to the Internet over a standard protocol, typically HTTP. The Ajax client fetches streams of data from the server. Because of the public nature of the web services, external entities may request the data directly, bypassing the client.

Figure 7.9. Data models in an Ajax-based game of Battleship. Once the pieces are positioned, the server will maintain a map of both players’ pieces. The clients will initially model only their own pieces but build up a model of their opponent’s as the game progresses.

Chapter 8. Performance

Figure 8.1. Object graph of stopwatch library classes. Each category is represented by an object that contains a history of events for that category. All categories are accessible from the stopwatch.watches singleton.

Figure 8.2. Mousemat example from chapter 4 with the JavaScript profiler running and generating a report on the active stopwatches. We have chosen to profile the window.onload event, the drawing of the thumbnail cursor in response to mouse movement, and the updating of the status bar with the mouse coordinates. count indicates the number of recordings made of each code block, and total the time spent in that block of code.

Figure 8.3. Venkman debugger for Mozilla with the Profile button checked, indicating that time spent executing all loaded scripts (as shown in the panel on the top left) is being recorded.

Figure 8.4. Fragment of the HTML profile report generated by Venkman showing the number of calls and total, minimum, maximum, and average time for each method that listens to the mouse movements over the mousemat DOM element in our example page.

Figure 8.5. Windows Task Manager showing running processes and their memory usage. Processes are being sorted by memory usage, in descending order.

Figure 8.6. Selecting additional columns to view in the Task Manager’s Processes tab. Virtual Memory Size shows the total amount of memory allocated to the process.

Figure 8.7. UNIX top command running inside a console, showing memory and CPU usage by process.

Figure 8.8. Process Explorer provides detailed reporting on memory and processor usage on a per-process basis, allowing for more accurate tracking of the browser’s footprint on a Windows machine. This window is tracking an instance of Mozilla Firefox running the stress test described in section 8.4.2.

Figure 8.9. The Drip tool allows detailed queries on the internal state of Internet Explorer’s DOM tree.

Figure 8.10. Our memory management demo application, after creation of the first 100 widgets. The user has just clicked one of the widgets with the mouse.

Chapter 9. Dynamic double combo

Figure 9.1. The client-side solution

Figure 9.2. The server-side postback method

Figure 9.3. The Ajax solution

Figure 9.4. Client-side architecture, showing the Ajax interaction

Figure 9.5. Available options in the first select element

Figure 9.6. Server-side process flow diagram

Figure 9.7. The double-combo list in action

Figure 9.8. Cross-browser differences in how a select element is rendered

Chapter 10. Type-ahead suggest

Figure 10.1. Google Suggest showing the available suggestions for the letter e

Figure 10.2. The system architecture for the type-ahead suggest

Figure 10.3. JavaScript statement output of the server-side page for a test run

Figure 10.4. The output for the type-ahead suggest for this application

Figure 10.5. The progression of the type-ahead project

Chapter 11. The enhanced Ajax web portal

Figure 11.1. Yahoo!’s portal shows customized information.

Figure 11.2. A9.com’s portal with the web results for Eric Pascarello

Figure 11.3. A9.com’s portal showing the search results with the Book Results column

Figure 11.4. Ajax portal flow. Users log in to the portal and manage their windows. Changes are saved automatically in the background while they work.

Figure 11.5. The users table properties in SQL Squirrel, the graphical database explorer

Figure 11.6. The contents of the users table

Figure 11.7. The HTML login form with no CSS applied

Figure 11.8. Ajax portal’s login page with the CSS stylesheet attached

Figure 11.9. An error message is displayed because of invalid credentials.

Figure 11.10. portal_windows database table structure

Figure 11.11. Data entered for the user with the id of 1

Figure 11.12. The Ajax portal with three windows open on the screen

Figure 11.13. Ajax portal showing windows with different positions

Chapter 12. Live search using XSLT

Figure 12.1. Classic search model showing the processing over a period of time

Figure 12.2. Process flow of a search executed in the frame model

Figure 12.3. Process flow of the Ajax model. The server-side process generates data, which the client-side code inserts into the page directly. Less bandwidth is used, and the user interface is smoother.

Figure 12.4. The search results are displayed from the Ajax live search.

Figure 12.5. The search results are displayed from the Ajax live search with CSS applied to the elements.

Chapter 13. Building stand-alone applications with Ajax

Figure 13.1. Eric Pascarello’s blog, which has an accessible RSS feed

Figure 13.2. RSS reader project’s process flow diagram

Figure 13.3. The RSS syndication reader developed in this project

Figure 13.4. HTML elements are shown without any CSS

Figure 13.5. CSS is applied to the holder and header divs.

Figure 13.6. CSS applied to the content divs

Figure 13.7. CSS applied to the footer

Figure 13.8. The preloader is loading file 2 of 4 as indicated by the status message with no errors.

Figure 13.9. The fading transition is taking place between message 5 and 6.

Figure 13.10. The Frank feed has been added to the Ajax reader.

Figure 13.11. This window shows the RSS feeder being paused since the center button is now labeled RESUME.

Figure 13.12. In Mozilla, choose Tools > Web Development > JavaScript Console.

Figure 13.13. The permission denied error message caused by the XMLHttpRequest object

Figure 13.14. The security prompt notifies the user about the request for access rights.

Figure 13.15. RSS Feed (x of y) : RSS Feed Title

Figure 13.16. Article (x of y) : RSS Item Title

Figure 13.17. Article (x of y) : RSS Item Title

Figure 13.18. RSSItemView result

Appendix A. The Ajax craftsperson’s toolkit

Figure A.1. Syntax highlighting support for JavaScript in (left to right) the TextPad, Gvim, and jEdit programmer’s editors

Figure A.2. The JavaScript editor plug-in for Eclipse provides rudimentary outlining support for JavaScript objects but doesn’t handle the full object-based syntax.

Figure A.3. Dreamweaver’s editor supports JavaScript and CSS. The CSS file being edited in the upper-right pane is also shown in outline form in the upper left.

Figure A.4. The Komodo IDE provides high-quality outlining features for JavaScript objects and can understand a number of coding idioms. Here the code outliner has recognized that various functions belong to the ObjectViewer prototype.

Figure A.5. Using the JavaScript debugger statement triggers a breakpoint programmatically.

Figure A.6. The Mozilla Venkman debugger allows inspection of local variables in functions higher up the call stack than the current point of execution.

Figure A.7. Setting up a conditional breakpoint in the Mozilla Venkman debugger

Figure A.8. Changing the value of a variable in a running program using the Mozilla Venkman debugger

Figure A.9. The Mozilla LiveHTTPHeaders extension can log HTTP traffic and present details of request and response headers.

Figure A.10. The logging console in operation, monitoring object creation, network activity, user edits, and so on. We have added a second network request to a nonexistent server resource, moons.xml, to demonstrate the display of the styled logging message.

Figure A.11. The Mozilla DOM Inspector presents a structural view of the DOM behind a web page, including nodes declared in the HTML and those generated programmatically.

Figure A.12. The Mozilla DOM Inspector allows direct scripting access to elements in the DOM. The variable name target refers to the currently selected DOM node, in this case the image of the planet, whose border we have just altered.

Figure A.13. The IEDocMon toolbar for Internet Explorer provides functionality similar to the Firefox DOM Inspector, allowing for rapid resolution of rendering issues with programmatically generated user interfaces.

Figure A.14. The Firefox browser lists all installed extensions in a pop-up dialog. More extensions can be installed from the Web.

Figure A.15. Firefox extensions can be installed from the Web, using a special downloadable archive format.

Figure A.16. Newly installed extensions are visible in the Extensions dialog immediately but won’t become active until the browser is restarted.

Figure A.17. After you restart the browser, the extension is ready to use.

Appendix B. JavaScript for object-oriented programmers

Figure B.1. Referencing the Model from an event handler function by name. The DOM element ID is parsed, and the parsed value used as a key to a global lookup array.

Figure B.2. Attaching a reference to the Model directly to a DOM node makes it easier for the event handler function to find the Model at runtime.