Inhaltsverzeichnis von Ajax Design Patterns

Inhaltsvorschau

BY NOW, YOU'VE PROBABLY USED AJAX ON SITES LIKE GOOGLE MAPS (HTTP://MAPS.GOOGLE.COM) Amazon's A9 search engine (http://a9.com), and Flickr (http://flickr.com). Despite their different domains, all these web sites make heavy use of Ajax. The technology lets them take a great leap forth towards the richness of standard desktop applications, and in a manner which still respects the established conventions of the Web.

No longer are you forced to wait five seconds a web page to reload every time you click on something. Ajax applications change in real-time. They let you drag boxes around instead of clicking on arrows and typing in numbers. They keep page content fresh instead of forcing you to keep hitting Refresh. They show meaningful animations instead of verbose messages.

At the heart of all this is a growing emphasis on web usability. Perhaps you've heard the story of the dancing bear—everyone's impressed with it even though its skills quite frankly wouldn't get the bear into a dance academy; it makes an impression because it can dance and not because of how well it well dances. The Web felt like that at first. Suddenly you could read news from the other side of the world, find hints on some obscure game, purchase a rare book. All valuable activities, regardless of how easy or difficult to perform them. Usability? We don't need no stinkin' usability!

Here's what happened: people discovered that any coder and his dog can build the basic functionality (and you don't always need the coder); amid the rush of B2B companies hyping multimillion dollar auction systems, I recall one CTO bragging that his summer students created the same thing for a few thousand bucks. So if companies in a saturated market can't compete on raw functionality, what can they compete on? The things that matter to users. Most of the companies that have survived and prospered—companies like Google, Amazon, and Yahoo!—avoided feature bloat and promoted simple, though not dumbed-down, interfaces. It's no coincidence that each of these companies have been busy incorporating Ajax features to that end. Each of these monster dotcoms not only uses Ajax, but has actually pioneered some of the concepts described in this book. You can throw Microsoft into that list as well.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

No longer are you forced to wait five seconds a web page to reload every time you click on something. Ajax applications change in real-time. They let you drag boxes around instead of clicking on arrows and typing in numbers. They keep page content fresh instead of forcing you to keep hitting Refresh. They show meaningful animations instead of verbose messages.

At the heart of all this is a growing emphasis on web usability. Perhaps you've heard the story of the dancing bear—everyone's impressed with it even though its skills quite frankly wouldn't get the bear into a dance academy; it makes an impression because it can dance and not because of how well it well dances. The Web felt like that at first. Suddenly you could read news from the other side of the world, find hints on some obscure game, purchase a rare book. All valuable activities, regardless of how easy or difficult to perform them. Usability? We don't need no stinkin' usability!

Here's what happened: people discovered that any coder and his dog can build the basic functionality (and you don't always need the coder); amid the rush of B2B companies hyping multimillion dollar auction systems, I recall one CTO bragging that his summer students created the same thing for a few thousand bucks. So if companies in a saturated market can't compete on raw functionality, what can they compete on? The things that matter to users. Most of the companies that have survived and prospered—companies like Google, Amazon, and Yahoo!—avoided feature bloat and promoted simple, though not dumbed-down, interfaces. It's no coincidence that each of these companies have been busy incorporating Ajax features to that end. Each of these monster dotcoms not only uses Ajax, but has actually pioneered some of the concepts described in this book. You can throw Microsoft into that list as well.

In addition, a whole new generation of companies has risen on the strength of their simple, intuitive applications. 37signals has a suite of tightly focused applications used daily by a passionate user base. With an innovative photo-sharing interface, Flickr built a community of 1 million photo-sharing users in around 18 months. Another recent entrant is Odeo, a podcast manager that works as an easy-to-use web application rather than running in the desktop like most of the competition. Like their giant counterparts, these newcomers are big proponents of Ajax and have helped define the concepts behind many of the Ajax Patterns featured in this book.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

On February 18, 2005, Jesse-James Garrett published an online article "Ajax: A New Approach to Web Applications" (http://www.adaptivepath.com/publications/essays/archives/000385.php). The Web was becoming richer and responsive, closing the gap with the desktop. Garrett introduced "Ajax" to label the architecture behind the new generation of rich web apps like Google Maps and Google Suggest. Ajax isn't a plugin, nor a proprietary technology. It's an architectural style—a high-level design pattern—composed of many related technologies and ideas.

Ajax technologies and applications were around before Garrett's article labelled them as such, but the article was a tipping point. Just like when the terms, "object-oriented," "agile development," and "postmodernism" began to be used, a converging trend had been given a buzzworthy umbrella term around which a community could form. "Ajax" gave us a label for the systems that were combining several powerful technologies. With this label established, the development community could suddenly share ideas about how the technologies fit together, debate in blogs about different design approaches, build libraries to support these kind of systems, and catalog common patterns.

Strictly speaking, the term is an acronym —"AJAX," for "Asynchronous JavaScript + XML"—although Garrett has noted that other technologies like CSS and DOM are just as important in the Ajax equation. "Ajax" just happens to roll off the tongue a whole lot easier than "Asynchronous JavaScript+CSS+DOM+XMLHttpRequest." Consistent with his original article, Ajax is generally written "Ajax," not "AJAX." That's a mindset, not mere cosmetic detail, because Ajax is a design style and attitude rather than a precise set of technologies; the technologies are whatever happen to let us build the things we want to build. Throughout this book, I refer to Ajax in terms of what it offers users and their organizations. Here's a working definition:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If you Google for "year of the portal", you'll find ample evidence that every year since 1996 has been the year of the portal. It's just around the corner, really. The idea has so much promise: the first thing you see when your browser opens up is a personal homepage with "My News" and "My Mail" and lots of other boxes just about "Me." In short, a page created by Me for Me. So why have they never really taken off? One big factor is that most portal interfaces, frankly, are unusable.

Consider the problems you face in using a legacy-style portal, using Excite.com as an example—many other conventional portals work in a similar manner (Figure 1-1).

Figure 1-1: Excite

Customizing the page is the most critical task, but you have to register first; each of the customization controls on the homepage will close the portal and take you to a completely different registration page.
Adding new "portlets" —the blocks of content—is rather painful. You have to click on Add/Delete Content, which will whisk you off to a tabbed configuration interface. There, you add and delete portlets by updating a list of current portlets.
Customizing an individual portlet—e.g., setting the stocks you're watching—will close the portal and send you to a special configuration page. You've lost the context.
Changing layout doesn't happen directly on the page, but in the configuration area. The layout is managed on a miniature model of the real portal, with titles shown only. (Some portals require repetitive clicking on arrow buttons for layout; fortunately, Excite allows drag-and-drop on the model.)
Volatile content such as news and market information is present on the page, but refreshes occur only occasionally; the smallest allowed period is five minutes. Refreshes force the whole page to be reloaded, which is not only distracting, but also makes it difficult for the user to see what, if anything, just changed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Attempts to webify office applications are almost as old as the Web itself. It's now part of computer folklore that Netscape's Marc Andreesen exclaimed, in the mid-1990s, that MS-Windows would be reduced to "a poorly debugged set of device drivers running Netscape Navigator," expecting to herald in a new era of desktop-style applications running inside the browser. The benefits of the Web over desktop apps are clear and abundant—e.g., an ability to access data from any web browser in the world, easy upgrading, no tampering of local machines, and better collaboration. However, there are serious problems too, and the most severe is interface. In the past, it's simply been impossible to produce a portable interface that's good enough to justify switching from the desktop.

This is changing quickly though, thanks to Ajax. A new generation of Ajax office applications (http://innerphaze.homelinux.com/blog/?p=28) are emerging as a serious substitute for MS-Word, Excel, and their desktop contemporaries.

One such offering is Writely, a Google acquisition billed as "The Web Word Processor" (Figure 1-3). Writely rightly avoids slavishly reproducing the desktop word-processing experience and instead aims for a feature set and interface that will work on the Web. The result is something that's as much a turbo-charged wiki as a webified word processor. The list that follows describes some of its features.

Figure 1-3: Writely

The content under edit is What-You-See-Is-What-You-Get (WYSIWYG). As you edit, you get to see the final content—color, fonts, layout, and all. The idea is covered in Rich Text Editor (Chapter 14).
Writely allows several people to collaborate on the same document at once. Using technology described in the Periodic Refresh (Chapter 10) pattern, it's able to keep updating the document and also the status of other authors.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Earlier on, Ajax was defined as a technology that "builds on standard web technologies to deliver a rich, responsive, user experience." This shouldn't be seen as a binary thing, because it's useful to think of Ajax as a continuous spectrum—an application that happens to include a Flash widget, or one that avoids using any remoting technology can still be considered "partly" Ajaxian; it's useful to do so if you're designing that system as you can leverage the experience of other Ajax developers, which is the kind of experience encapsulated in the Ajax Patterns. And in documenting the Ajax Patterns, it's certainly useful to learn from applications that aren't "pure Ajax." To that end, the characteristics here are intended as a general guide, but not hard-and-fast rules, for what constitutes an Ajax application.

These days, you'll hear a lot more about "web applications"—or "webapps"—than about "web sites." Driving many modern web projects is the perspective of the browser as a platform and the Web as an operating system. People aren't just buying a book or browsing a manual, but are performing day-to-day work as well as socializing via the browser platform, often working on more critical, complex tasks than in the past. While Ajax can really be applied to anything running inside a browser, it comes into its own with these kinds of systems, where it helps keeps users engaged and productive.

Traditional web sites make you submit a form, wait a few seconds, watch the page redraw, and then start the whole cycle again. That's because the tiniest server interaction, and even the tiniest display change, requires a call to the server, and then a complete page refresh. It's a frustratingly slow and erratic sequence. Ajax changes the model in a few ways. First, JavaScript running inside the browser can manipulate the display directly—you don't have to send a whole new page from the server in order to hide an element or rearrange the page. Second, server interaction can be handled via JavaScript, so you can upload user commands and download new information without any page refresh. Third, user actions such as mouse-clicking and typing can be handled by JavaScript, so the interaction is a lot richer than just filling in a form and hitting Submit. All of these enhancements make Ajax interaction feel faster and more continuous.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Here's a quick rundown of the various technologies involved in Ajax. To begin with, there are several that have always been popular on the Web, which are relatively well-understood by the development community. They are still used in Ajax applications, though sometimes in different ways.

HTML/XHTML: As always, HTML provides the structure of a web page. An Ajax App uses an HTML document to show the initial page, and the document is continuously manipulated to change the display and set up new events. Where possible, its XML-compliant variant, XHTML, should be used in order to make manipulation more robust.
CSS: CSS enriches the display and, thanks to stylesheets, helps separate document structure from style details. Fortunately, browsers are now reasonably consistent in their support for CSS2, so the past few years have seen many web sites shift from table-based layout, which was always something of a hack, to the cleaner, more flexible, CSS-based layout. From our perspective, the great thing about all this is that CSS can easily be manipulated with JavaScript. With just one line of code, you can make an object disappear, move it around the page, or alter its appearance.
HTTP, CGI, Form Submission: As with conventional web applications, Ajax communicates via HTTP. The difference is that instead of returning full pages, the server returns concise results that are then processed in the browser script. Form submission—often with CGI-style URLs—is also used, but again is initiated programmatically, meaning that no page refresh need take place.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

At a lower level, how does an Ajax interaction look? Here's a typical sequence of events. Let's begin with the application startup sequence (Figure 1-4):

Figure 1-4: Typical startup sequence

User points browser to Ajax App. The user begins interacting with an Ajax application by visiting it in the usual way; e.g., by following a link or selecting a bookmark.
Browser loads initial content. The browser fills up with initial content sent out by the Ajax application. This includes the initial HTML to be displayed, the CSS to establish styling, and the JavaScript code to manage further interaction. The HTML is sometimes as raw as a general page structure, in which case the initial content will subsequently be pulled down in a second call. The code will usually set up event handlers to dictate how the system should respond to user actions.

Once the application has loaded, further activity will be triggered by events. Following is the typical sequence for each event (Figure 1-5):

Figure 1-5: Typical event-handling sequence

User does something. Most events are triggered by user actions such as mouse clicks. As explained in Dynamic Behavior patterns, JavaScript functions can be registered against particular event types on particular page elements; e.g., you can arrange for the purchase( ) function to be called whenever a shopping item (the page element) is double-clicked (the event type). Thus, the user action will typically cause an event handler to be invoked.
Event handler sends request to server. Certain events require server interaction—for example, the user has just entered some information that should be validated by the server; or the user has just requested some new information.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This book has certainly been a moving target. There were already quite a few Ajax applications available when the "Ajax" term was coined, and the space has since exploded, propelled by the rush of activity in what's come to be known as the "Web 2.0" movement. Each day is bringing fresh ideas to the table, as more and more Ajax applications are released. It's impossible to know where it will all lead, but this section identifies a few future trends and open questions.

Better compatibility across browsers has made rich web development much easier. However, we're at a crossroads now, because the same economic boom that's fuelling Ajax application development is also fuelling innovations in the browsers themselves, leading to a serious risk of diverging technologies.

One group pushing for change is the Web Hypertext Application Technology Working Group (WHAT-WG). The key term here is "Application," as the group is pushing for the Web as a true application platform, a goal that resonates loudly with the aims of Ajax. Under current proposals, rich controls and interaction techniques such as drag-and-drop will enjoy native browser support. All this is good for Ajax developers, but will probably come at the price of compatibility. It's not clear which browsers will support which standards, and there are likely to be major discrepancies in the implementation schedules. Moreover, Microsoft is conspicuous by its absence from WHAT-WG, and it's distinctly possible IE will end up with a very different API for all this functionality. As well as standards endorsed by WHAT-WG and W3C, there will inevitably be browser-specific features to consider as well. Microsoft will continue to evolve its Atlas framework, and it's certainly possible that IE will give Atlas functionality—such as local data storage—that's not available to other browsers.

If browsers do go down the mid-1990s path of diverging APIs, developers will have to decide on appropriate strategy. The options will include: targeting a specific browser (unfortunate, but will sometimes be the most pragmatic choice), ignoring browser-specific features, and relying on compatible plugins for behavior not directly supported by a particular browser.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This chapter has introduced the basic technologies of Ajax, provided overviewed characteristic examples, and given some indication of where it's all going, though there will doubtless be some surprises along the way. Even if the "Ajax" name is fairly new, Ajax has been kicking around in various corners of the Net for some time now, and the rest of the book explains what we've learned so far about working with Ajax. In the next chapter, we'll dive head-first into Ajax with a "pattern-led tutorial"—a hands-on introduction to the basic technologies of Ajax as well as the Ajax Patterns that guide their usage.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THIS CHAPTER INTRODUCES AJAX AND THE AJAX PATTERNS IN A THREE-PART TUTORIAL. THE FIRST section is a whirlwind tour of the key technologies, recommended if you've never worked with Ajax before. The second section shows how the higher-level patterns work to enhance a system; if you've already tinkered with Ajax, you might like to jump straight there. The final section proposes some exercises to try on your own.

The online home for this tutorial is http://ajaxify.com/tutorial/, where you'll discover running demos for each example here. To work locally, you'll need a standard PHP installation (version 5 or later) with Apache or a similar web server (no database is required). If you want the completed code, you'll find a downloadable package at the above URL—consult Appendix B for more details on installation. Each section in the tutorial begins with a summary of the corresponding online demo as well as the directory within the code package where you'll find the completed code.

This section includes a few exercises to get up to speed with the basic Ajax technologies. Each section is independent from the others, and each corresponds to a group in the Foundational Technologies Patterns (Part II), which are patterns about the raw technologies on which all Ajax applications are based.

Each demo should live in its own directory, so create a tutorial directory under your server's document root, and then create three fresh directories underneath that:


 cd /apache/docroot (substitute your own document root)

 mkdir tutorial

 cd tutorial

 mkdir display remoting dynamic

For Unix systems, ensure permissions are appropriate for your web server (e.g., make the directories globally readable and executable). Each directory will begin with the same "blank slate" HTML file, index.html. Open up your favorite editor and save the following file to display/index.html, remoting/index.html, and dynamic/index.html

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section includes a few exercises to get up to speed with the basic Ajax technologies. Each section is independent from the others, and each corresponds to a group in the Foundational Technologies Patterns (Part II), which are patterns about the raw technologies on which all Ajax applications are based.

Each demo should live in its own directory, so create a tutorial directory under your server's document root, and then create three fresh directories underneath that:


 cd /apache/docroot (substitute your own document root)

 mkdir tutorial

 cd tutorial

 mkdir display remoting dynamic

For Unix systems, ensure permissions are appropriate for your web server (e.g., make the directories globally readable and executable). Each directory will begin with the same "blank slate" HTML file, index.html. Open up your favorite editor and save the following file to display/index.html, remoting/index.html, and dynamic/index.html:


  <html>



  <head>

    <title>AjaxPatterns.org - Tutorial</title>

    <script type="text/javascript" src="tutorial.js"></script>

  </head>



  <body>



    <h1>AjaxPatterns Tutorial</h1>



    <div id="sandbox">

    </div>



  </body>

Remember to set file permissions according to the web server's requirements. Now point your browser to one of the new files and check that you can see the above content. The URL should be http://localhost/tutorial/display/ or, failing that, try http://localhost/tutorial/display/index.html.

The HTML file loads the JavaScript file tutorial.js, which isn't there yet. The next three demos will leave the HTML file alone and illustrate Ajax concepts with code in their respective tutorial.js files.

Section 2.1.2.1: Hello World!

To begin, go to the working directory (tutorial/display/). Note that there's an online demo of the application we're going to build at

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Patterns aren't necessarily about big upfront design; more often, they're used for refactoring and enhancing existing systems. The foundational technologies from the previous section can be seen as techniques for Ajaxifying a conventional web app in addition to being useful for building a new one. In the same way, many of the subsequent patterns can be seen as techniques for improving an existing Ajax App.

Here, we'll look at how a few patterns can be progressively applied to enhance a web app. The conventional app is initially described for comparison, but we really begin building the app at Step 1, where we produce a basic Ajax version. In all, there are four steps. In the packaged code, you'll find the complete code for each step. So if you get lost in the middle of Step 2, you can start Step 3 afresh by taking a clean copy of the completed Step 2 directory. Note that all the application files reside in just the one directory.

There is no working directory (no coding required here). See the location of the completed code within the installation package at /tutorial/ajaxagram/. There's an online demo at http://ajaxify.com/tutorial/ajaxagram/.

Starting on familiar ground, the initial version is a conventional web app—no Ajax here. It takes a word and lists all anagrams; i.e., all possible combinations of the letters (Figure 2-4). For simplicity, there's no dictionary comparison to look for real words, and for the sake of performance, the input field is limited to just five characters. We won't actually build this conventional version, but you might want to peruse the code (in tutorial/ajaxagram/) for comparison with the next Ajaxified version. There are two source files:

anagram.php: The server-side business logic for finding anagrams, described later in the section "Business logic: the anagram web service."

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now it's over to you. Here are some suggestions for projects you can work on. You might like to approach these as "Katas" (http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Practices/Kata/), short exercises that you can keep returning to. Alternatively, add all the bells and whistles and make them full-blown projects. Check http://ajaxpatterns.org/Katas for the latest list, and please add links to any of your online efforts.

Two-Person chat: Allow two people to chat in real-time via the browser.
Filesystem navigator: Navigate a server-side filesystem. Bonus points for sanely displaying file contents.
Search portlet: Build a portlet to access your favorite web service, using a Cross-Domain Proxy (Chapter 10) pattern or an On-Demand JavaScript (Chapter 6) pattern if the web service happens to offer a compatible service (such as Yahoo's JSON API). Results should be displayed inside the portlet, without any page refresh.
Drag-And-Drop cart: Create a shopping cart that allows items to be dragged in and out and uploads details to the server. Note that several libraries support drag-and-drop.
Am I Ajax Or Not: Create a clone of AmIHotOrNot.com. Show two random images (or even just random numbers), let the user click on their favorite, and ensure the server records their choice. For bonus points, show scores in the browser; e.g., offer a popup showing the number of "wins" for the two items being displayed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The first part of this chapter showed you how to create a basic Ajax application. After performing that section, you should be comfortable about the basics of Display Manipulation (Chapter 5), Web Remoting (Chapter 6), and Dynamic Behavior (Chapter 7. The second part of this chapter introduced a number of the Ajax Patterns—the point is not to understand those patterns in detail, but to get a feel for the sort of thing the patterns do. That is, to see how they build on top of the basic technologies to improve usability, maintainability, and so on. The final part of this chapter suggested several exercises—I recommend you try one or two if you're still coming to grips with Ajax.

It should be clear by now that although Ajax is a great leap forward for the Web, it's no magic bullet. Developers need to tread carefully in order to ensure their Ajax apps are easy to maintain and easy to use. The next chapter summarizes several key principles for Ajax system design and introduces the Ajax Patterns, which offer practical advice on applying those design principles.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

AJAX DOES A LOT FOR WEB USABILITY, HAS ALREADY DELIVERED SOME STUNNING APPLICATIONS, AND IS clearly the "in" thing at this time. But it's no magic bullet. Careful design is always required, and it must be tailored to the technology at hand. By monitoring the state of Ajax applications, we continue to learn about what works and what doesn't, and about how developers are succeeding in their design trade-offs. This chapter explains these lessons at a high level and introduces the patterns, which discuss them in depth.

Ajax is about improving user experience and delivering value to the organizations that own and use web applications. Here, we'll look at the key attributes of an ideal Ajax application. Reality dictates that you'll never get the best of all worlds, so you'll have to make trade-offs based on how important you consider each attribute. The Ajax Patterns are intended to help you deal with these trade-offs.

Usability: Ajax applications should be as intuitive, productive, and fun to use as possible.
Developer productivity: Development should be as efficient as possible, with a clean, maintainable code base.
Efficiency: Ajax applications should consume minimal bandwidth and server resources.
Reliability: Ajax applications should provide accurate information and preserve the integrity of data.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Ajax is about improving user experience and delivering value to the organizations that own and use web applications. Here, we'll look at the key attributes of an ideal Ajax application. Reality dictates that you'll never get the best of all worlds, so you'll have to make trade-offs based on how important you consider each attribute. The Ajax Patterns are intended to help you deal with these trade-offs.

Usability: Ajax applications should be as intuitive, productive, and fun to use as possible.
Developer productivity: Development should be as efficient as possible, with a clean, maintainable code base.
Efficiency: Ajax applications should consume minimal bandwidth and server resources.
Reliability: Ajax applications should provide accurate information and preserve the integrity of data.
Privacy: While user-generated data can and should be used to improve the user experience, users' privacy should also be respected, and users should be aware of when and how their data is used.
Accessibility: Ajax applications should work for users with particular disabilities and of different ages and cultural backgrounds.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

By studying existing Ajax applications, as well as any relevant precursors, it's been possible to distill a number of important design principles for Ajax, which are shown in this section. The thinking behind the principles was a big influence on the pattern discovery process, and knowing them will help to apply the patterns.

We'll begin by looking at principles of user-centered design, followed by those of software design. Of course, you can never fully separate those concerns, and they're often in conflict with each other. Dealing with those conflicts is really a key concern of the patterns. Incidentally, it's worth checking out a good online resource that takes the opposite perspective: Ajax Mistakes (http://swik.net/Ajax/Ajax+Mistakes) is a long list of Ajax mistakes and gotchas, as well as anti-patterns originally authored by Alex Bosworth and now maintained on a wiki.

Follow web standards: Try hard enough, and you can do some very confusing things with Ajax, even more so as rich graphics become commonplace. Rather than reinventing the Web as we know it, use Ajax to build a "better Web," an enhanced layer over what's already there. Respect the conventions that users are already familiar with.
The browser is not a desktop: Further to the previous principle, Ajax is a richer brand of the traditional web site rather than a webified brand of the traditional desktop. True, desktop widgets like sliders are migrating towards Ajax, but only when they make sense in a web context and often in a modified form. We're also seeing application categories like word processors head online as well, but again, the best products will be those that fit in with the Web rather than blindly replicating the desktop experience.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Ajax Patterns show how people have used the design principles effectively in real-world Ajax applications. It might seem funny that we can have so many patterns about Ajax, a term that was coined only a few months before work on these patterns began. However, the ideas are not new; there were many Ajax features on the Web before the term came about to describe them. The healthy Net economy has helped a lot too, with hundreds of new sites now using Ajax, along with powerful tools (RSS, Technorati, Google, and wikis) to locate them as soon as they're available.

With over 60 patterns, it's useful to classify the patterns hierarchically. At a high level, the book is divided into four parts, each corresponding to a different focus area—Foundational Technology, Programming, Functionality and Usability, and Development. Beyond that, each part is divided into several chapters, where each chapter includes related patterns. For instance, Foundational Technology Patterns (Part II), includes Web Remoting (Chapter 6), which includes several patterns for web remoting. Here's a summary of each part:

Foundational Technology patterns (11 patterns): The foundational technologies are the building blocks that differentiate Ajax from conventional approaches, and this section explains typical usage.
Programming patterns (23 patterns): These are the features of architecture and code that serve the software design principles listed previously. These include, among other things, design of web services; managing information flow between browser and server; populating the DOM when a response arrives; and optimizing performance.
Functionality and Usability patterns (28 patterns)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

All of the patterns follow the same basic format, though certain fields are left out where appropriate. This section explains the meaning of each section.

Evidence

How much real-world evidence exists for the pattern, on a 3-point scale and presented graphically? It's a rather subjective estimate, but use the following icons as a guide:

○: Suggests the idea is purely speculative
⊙: Suggests there's at least a proof-of-concept or an early usage
⊙⊙: Suggests there's a few established examples
⊙⊙⊙: Suggests the pattern is in widespread usage

Tags

Tags—or keywords —help people locate the pattern and get a sense of its focus.

In a Blink

This is a sketch to set the scene for the pattern.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Ajax Patterns Demos appear in many patterns as Refactoring Illustrations and also in the Solution section. They're all online at http://ajaxify.com/run/, and it would be worth trying them out. In addition, the full code base can be downloaded from that location; its installation is explained in the Appendix B. It includes the demos as well as completed code for Chapter 2. Note the demos have been tested on Firefox 1.5 and IE6, though most of them work on comparable browsers as well.

The server-side code is all PHP, but most of it is fairly trivial, so it should be fairly easy for all programmers to comprehend. PHP was chosen as it's quite easy for anyone to set up, on any platform. Also, the language itself is fairly "generic" in that anyone with web development experience should have no difficulty following the code.

The demos are organized around a refactoring theme. For most of the examples, there is an initial, "embryonic," Ajaxian application. Then, several parallel refactorings are applied to the same demo, each in a separate subdirectory. And each of these refactorings may have a further refactoring applied, contained in a deeper subdirectory. A tree structure emerges on the site, with each application having evolved in different ways.

For example, look at the evolution of Finite Cache Sum Demo (http://www.ajaxify.com/run/sum/xml/cached/expiry/), which has the path /sum/xml/cached/expiry/.

/sum/: First, there is the basic demo at /sum/. Enter some numbers and the server responds with a sum. As a basic Ajaxian application—with no form submission involved—there are some foundational technologies illustrated here, but that's about it.
/sum/xml/: Next, the sum is refactored to receive results in XML form, as a demo is done for the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This chapter has covered how people are designing for Ajax and introduced the Ajax Patterns. The pattern language (just like Ajax itself) isn't a magic bullet, but a tool intended to improve your mastery of Ajax web development. You can use it as a reference for "quick-fix" problem solving, but you probably gain more if you also treat it as an educational resource to learn more about the recurring problems and solutions in Ajax. The remainder of this book constitutes the patterns themselves, divided into four parts according to their area of concern—Foundational Technologies, Programming, Functionality and Usability, and Development.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THIS CHAPTER CONTAINS JUST A SINGLE PATTERN, THE ROOT FOR THE ENTIRE PATTERN LANGUAGE: Ajax App.

⊙⊙⊙ Ajax, Balanced, Client-SOA, DHTML, Fast, Fat, Interactive, Platform, RichInternetApplication, Rich, Thick, Web2.0, and WebApp

Figure 4-1: Ajax App

Pam's begun entering staff appraisals into a new Ajax App. She's pleased to see the data entry is much faster: fields are validated as soon as they're filled out, searches are integrated into the form rather than in annoying popups, and the remaining form fields keep mutating to reflect what she's entered so far.

How can you create a rich application?

See Chapter 1 for more details on the forces driving Ajax, which are summarized here.

Users like working and playing in the browser and are now more willing to keep their data online, but are nonetheless frustrated with conventional "click 'n' wait" interfaces.
Companies like web apps running on their Intranets because it makes deployment much easier, but they continue to be burned by unusable web apps that don't deliver the same value as a comparable desktop app.
Developers are now well-versed in the basic patterns of web architecture and ready to take on new challenges.
Technology has opened up new opportunities for the Web: broadband and beyond is becoming ubiquitous in many countries; servers can process huge quantities of requests per second; and storage is growing to the point where it's feasible for individuals to host most of their personal data online.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Ajax, Balanced, Client-SOA, DHTML, Fast, Fat, Interactive, Platform, RichInternetApplication, Rich, Thick, Web2.0, and WebApp

Figure 4-1: Ajax App

Pam's begun entering staff appraisals into a new Ajax App. She's pleased to see the data entry is much faster: fields are validated as soon as they're filled out, searches are integrated into the form rather than in annoying popups, and the remaining form fields keep mutating to reflect what she's entered so far.

How can you create a rich application?

See Chapter 1 for more details on the forces driving Ajax, which are summarized here.

Users like working and playing in the browser and are now more willing to keep their data online, but are nonetheless frustrated with conventional "click 'n' wait" interfaces.
Companies like web apps running on their Intranets because it makes deployment much easier, but they continue to be burned by unusable web apps that don't deliver the same value as a comparable desktop app.
Developers are now well-versed in the basic patterns of web architecture and ready to take on new challenges.
Technology has opened up new opportunities for the Web: broadband and beyond is becoming ubiquitous in many countries; servers can process huge quantities of requests per second; and storage is growing to the point where it's feasible for individuals to host most of their personal data online.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

FOR AN END USER, THE MOST OBVIOUS THING ABOUT AJAX IS ITS VISUAL APPEARANCE. AJAX APPS TEND to look richer, and the interface tends to update smoothly, more like a desktop app than a conventional web app. This chapter describes the two main technologies for updating the user interface. Display Morphing focuses on changes to a single element, while Page Rearrangement involves changes to the page structure. Along the way, we'll look at the Document Object Model (DOM). DOM manipulation is key to many of the Ajax Patterns.

⊙⊙⊙ Display, DOM, Graphics, GUI, Morph, Page, Paint, Reference, Rich

Figure 5-1: Display Morphing

Stuart is answering a question in an online quiz, with a countdown box showing how much time remains. The countdown label changes each second, and the color gradually shifts from green to red as the countdown proceeds.

How can you dynamically update display elements?

As the user's task and context changes, applications need to present different types of information.
As information the user is working on changes, information being displayed becomes stale.
Stale information is a big problem in conventional web apps. Because the information cannot change until it's out of date, you sometimes see disclaimers such as "May Be Out of Date" or instructions like "Click to Refresh."
Submitting and redrawing the entire page interrupts the user's flow.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Display, DOM, Graphics, GUI, Morph, Page, Paint, Reference, Rich

Figure 5-1: Display Morphing

Stuart is answering a question in an online quiz, with a countdown box showing how much time remains. The countdown label changes each second, and the color gradually shifts from green to red as the countdown proceeds.

How can you dynamically update display elements?

As the user's task and context changes, applications need to present different types of information.
As information the user is working on changes, information being displayed becomes stale.
Stale information is a big problem in conventional web apps. Because the information cannot change until it's out of date, you sometimes see disclaimers such as "May Be Out of Date" or instructions like "Click to Refresh."
Submitting and redrawing the entire page interrupts the user's flow.

Morph page elements by altering styles and values in the Document Object Model (DOM), such as text and color properties. The DOM represents the state of the web page at any time. When JavaScript manipulates the DOM, the browser notices the changes and immediately reflects them in the user interface. To morph a page element's display, you get a reference to it and change its properties. This allows you to change the display of any element on the page—headings, div elements, images, and even the document object itself. Note: an online demo (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Add, Adjust, Change, Delete, DOM, Move, Overlay, Rearrange, Restructure, Remove

Figure 5-6: Page Rearrangement

Doc is looking at a X-ray image in an online diagnostics system. When the mouse rolls over the body, an "advice box" appears at the bottom of the page with stats to help interpret the image. In case the box gets in the way, he's able to drag it around the page.

How can you dynamically restructure the page?

As the user's task and context changes, Ajax Apps need to present different information.
Changes to page structure should be as smooth as possible.
Refreshing the page breaks continuity and also clears JavaScript state.
Refreshing the page only allows for a discrete transition from one appearance to another—it's not possible to gradually fade or move an item.

Add, remove, move, and overlay elements by manipulating the DOM. The DOM is a hierarchical structure that defines how elements relate to one another. By adjusting the DOM structure, you can adjust where elements appear on the page. There are also critical CSS styles that affect page structure—you can change these by manipulating DOM elements' style attributes. Note: an online demo (http://ajaxify.com/run/page) illustrates the code concepts throughout this Solution and the code snippets loosely follow from the demo.

Adding is normally achieved by introducing a new element as a child of an existing

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

NOW THAT WE'VE SEEN HOW AJAX APPS CAN MANIPULATE THE DISPLAY, IT WOULD BE USEFUL IF THEY could use that capability to show data arriving from the server. We'd also like to accept input and upload it to the server. The Web Remoting patterns let JavaScript directly issue calls to the server. The point is to let the browser make a query or upload some data, without actually refreshing the page.

The first pattern is Web Service, which explains how the server side exposes functionality to be accessed by the browser.

The remaining patterns are the most useful and most common mechanisms for web remoting. XMLHttpRequest Call is a clean way for the browser script to invoke and catch responses from the server. IFrame Call provides a similar use by exploiting IFrame functionality. HTTP Streaming, also known as "Push" (or "Comet"), allows the server to continue streaming new data down the pipe, without the browser having to issue new requests. On-Demand JavaScript is a fairly broad-scoped pattern and is included in this section because one style, Script Tag Generation, is a distinctive technology that's becoming a popular way to directly access external domains.

Of the four techniques, XMLHttpRequest Call is the cleanest, because XMLHttpRequest is specifically designed for web remoting. Nevertheless, all of the techniques are effective, and each has a certain set of situations where it's the superior choice. See the "Alternatives" section for XMLHttpRequest Call for a comparison of the various techniques.

⊙⊙⊙ API, HTTP, Microcontent, REST, RPC, Share, SOAP, Platform

Figure 6-1: Web Service

In a financial forecasting app, Tracy runs an algorithm to forecast the next four interest rates. The browser script uploads the parameters to an "Interest Rate Forcaster" web service, which eventually outputs a concise list of future rates, free of any HTML markup:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ API, HTTP, Microcontent, REST, RPC, Share, SOAP, Platform

Figure 6-1: Web Service

In a financial forecasting app, Tracy runs an algorithm to forecast the next four interest rates. The browser script uploads the parameters to an "Interest Rate Forcaster" web service, which eventually outputs a concise list of future rates, free of any HTML markup: 4.5, 3.4, 4.0, 4.1.

What will Ajax Apps call on the server?

Ajax Apps can access the server directly and require well-scoped services instead of the conventional-style scripts that output an entire HTML page.
Many organizations like to expose their functionality and data for third parties to access. The API needs to be clean and easy to use.

Expose server-side functionality as fine-grained, easy-to-use Web Services. "Web Service" is an overloaded term, and the Ajax Patterns use a fairly broad definition:

A Web Service is a standard HTTP service.
A Web Service has a well-defined, consistent interface—input and output assumptions, message formats, and exception handling are all clearly understood by its developers and ideally documented in some manner.
A Web Service accepts fine-grained input parameters and outputs fine-grained responses, such as an XML document, a simple string, or a snippet of HTML. If it outputs an entire HTML document, it's probably not a Web Service.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Call, Callback, Download, Grab, Live, Query, Remoting, RemoteScripting, Synchronise, Synchronize, Upload, XMLHttpRequest

Figure 6-2: XMLHttpRequest Call

Reta's purchasing some items from a wholesaler's web site. Each time she adds an item to the shopping cart, the web site issues an XMLHttpRequest to save the latest cart contents. There's no form submission, so the item is added instantaneously, which saves Reta time as well as helping her understand what's going on.

How can the browser communicate with the server?

Ajax Apps require browser-server communication. User-generated information must be uploaded and new server information must be downloaded.
Because Ajax Apps should have a smooth and continuous feel, browser-server communication must be unobtrusive.
Ajax Apps should be highly responsive, so calls should involve minimal data transfer.
As the network is often unreliable and performance is inconsistent, calls should be asynchronous, allowing the user to keep working while network calls are in progress.

Use XMLHttpRequest objects for browser-server communication. JavaScript lacks a portable mechanism for general network communication, a restriction that's always been in place for security reasons and will probably remain. But thanks to the XMLHttpRequest object—now available in all major browsers—JavaScript code can make HTTP calls back to its originating server and get hold of the results. Doing so enables you to make fine-grained server calls and deal with responses as you wish, unlike conventional form submissions, which cause a complete page refresh. Note: an online demo (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Call, Callback, Download, Frame, IFrame, Live, Query, Remoting, RemoteScripting, Upload

Figure 6-5: IFrame Call

Bill's ordering a car online and the price is always synchronized with his choice. This happens because of a hidden IFrame. Each time he changes something, the browser populates a form in the IFrame and submits it. The IFrame soon contains the new price, which the browser copies into the visible display. XMLHttpRequest could have accomplished the feat too, but it's not supported in Bill's outdated browser.

How can the browser communicate with the server?

Refer to the section "Forces" in XMLHttpRequest Call.

Use IFrames for browser-server communication. Much of the fuss in Ajax concerns the XMLHttpRequest object, but sometimes other remoting techniques are more appropriate, and IFrame Call is one of those (see the "Alternatives" section of XMLHttpRequest Call, earlier in this chapter, for a comparison). IFrames are page-like elements that can be embedded in other pages. They have their own source URL, distinct from their parent page, and the source URL can change dynamically. IFrame Calls work by making the IFrame point to a URL we're interested in, and then reading the IFrame's contents once the new content has loaded. Note: an online demo (http://ajaxify.com/run/iframe) illustrates most of the code concepts throughout this Solution and the code snippets loosely follow from the demo.

To begin with, you need an IFrame in the initial HTML, and an event handler registered to catch the onload event. (It would be less obtrusive to register the handler with JavaScript, but due to certain browser "features," that doesn't always work.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Connection, Duplex, Live, Persistent, Publish, Push, RealTime, Refresh, Remoting, RemoteScripting, Stateful, ReverseAjax, Stream, TwoWay, Update

Figure 6-9: HTTP Streaming

Tracy's trading application contains a section showing the latest announcements. It's always up-to-date because the announcements are streamed directly from the server. Suddenly, an important announcement appears, which triggers her to issue a new trade. The trade occurs with a new XMLHttpRequest, so the announcement stream continues unaffected.

How can the server initiate communication with the browser?

The state of many Ajax Apps is inherently volatile. Changes can come from other users, external news and data, completion of complex calculations, and triggers based on the current time and date.
HTTP connections can only be created within the browser. When a state change occurs, there's no way for a server to create a physical connection to notify any interested client.

Stream server data in the response of a long-lived HTTP connection. Most web services do some processing, send back a response, and immediately exit. But in this pattern, they keep the connection open by running a long loop. The server script uses event registration or some other technique to detect any state changes. As soon as a state change occurs, it pushes new data to the outgoing stream and flushes it, but doesn't actually close it. Meanwhile, the browser must ensure the user interface reflects the new data. This pattern discusses a couple of techniques for Streaming HTTP, which I refer to as "page streaming" and "service streaming."

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Behaviour, Bootstrap, CrossDomain, Dynamic, JavaScript, LazyLoading, OnDemand, ScriptTag

Figure 6-13: On-Demand JavaScript

Bill's logging into his bank web site. The login form comes up straight away, and as he types in his username and password, the browser is quietly downloading the JavaScript necessary for the rest of the application.

How can you deploy lots of JavaScript code?

Ajax Apps make heavy use of JavaScript. Richer browser behavior means bulkier JavaScript to download.
Downloading JavaScript has a performance impact. Interaction cannot fully begin until all initial JavaScript has been loaded.
Bandwidth is also a concern with heavy JavaScript content. Often, not all JavaScript that's loaded is actually used, leading to a waste of bandwidth.

Download and run JavaScript snippets. The initial page load includes some JavaScript code, which—among other things—contains the bootstrapping code necessary to pull down further JavaScript. There are two techniques available: Script Tag Creation and Service Eval. Each will now be described, following by three main applications of the pattern.

With Script Tag Creation, use DOM manipulation to inject a new script element into the page. Perhaps surprisingly, the effect will be exactly the same as if the <script> tag had been encountered on startup: the referenced JavaScript will be downloaded and executed automatically. The tag can be attached to either the head or the body, though the former is more common as that's where you'd usually find

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

With the technologies covered so far, we can change the display and talk to the server. But what will trigger these actions? Ajax Apps are generally driven from within the browser, so that's where the actions will be triggered. Broadly speaking, there are two types of triggers, each covered here: User Actions, such as mouse clicks and keypresses, and Scheduling, where actions are scheduled to be run at some point in the future.

⊙⊙⊙ Action, Change, Click, Control, DHTML, DOM, Events, Keyboard, Mouse, Move, Type, Widget

Figure 7-1: User Action

Pam is booking a trip on the corporate travel planner. She sees a form with the usual fields and clicks on location. Suddenly, a list of cities fades in beside the form, and Pam selects Paris. Beside the city list, a second list appears, this one showing approved hotels. Pam chooses the Hilton, and both lists disappear. Pam's pleased to proceed with the destination on the updated form, which now reads, "Paris Hilton."

How can the application respond to user activity?

A rich application allows users to interact with it, frequently and in different ways.
Responses must be as quick as possible, so as to streamline performance, keep user attention, and help the user understand the application's cause-effect model.
Using form submissions as the only response to user activity is slow and limits interactivity.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Action, Change, Click, Control, DHTML, DOM, Events, Keyboard, Mouse, Move, Type, Widget

Figure 7-1: User Action

Pam is booking a trip on the corporate travel planner. She sees a form with the usual fields and clicks on location. Suddenly, a list of cities fades in beside the form, and Pam selects Paris. Beside the city list, a second list appears, this one showing approved hotels. Pam chooses the Hilton, and both lists disappear. Pam's pleased to proceed with the destination on the updated form, which now reads, "Paris Hilton."

How can the application respond to user activity?

A rich application allows users to interact with it, frequently and in different ways.
Responses must be as quick as possible, so as to streamline performance, keep user attention, and help the user understand the application's cause-effect model.
Using form submissions as the only response to user activity is slow and limits interactivity.

Handle most User Actions within JavaScript, using event handlers. The essence of Ajax is rich browser-based interaction, and DOM events are the technology that make it happen. DOM objects can register event handlers, functions that are notified when events occur. This callback model should be familiar to anyone who's worked with desktop GUI frameworks.

If you've not worked with a modern user interface framework such as Java's Swing, you might wonder how JavaScript events work. The answer is that, behind the scenes, the operating system tells the browser what the user's doing, and the browser then passes this information to the script. For instance, the operating system—monitoring keyboard and mouse input—might notice that the user hit "X" while the keyboard focus was on the browser window. It will then notify the browser, and the browser will decide which element within the current web page has keyboard focus. If that element happens to have an associated keypress event handler, the browser will arrange for it to be invoked. Just prior to invoking it, it will construct an event object indicating the key that was pressed ("X"), the object that had focus at the time, and auxiliary information like the current mouse location and the current time. The browser will derive some of this information from the previous operating system notification, so other information might be queried there and then. When the event handler is invoked, this event object will be passed in as an argument.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Cron, Event, Future, Loop, Periodic, Plan, Repeating, Schedule, Sequence, Timeout

Figure 7-3: Scheduling

Frank's panning across a map of the factory. To ensure he monitors all regions, each is color-coded according to how recently it was investigated. It's implemented with Scheduling: after 5 idle minutes, the room turns orange; after 10 minutes, it turns red.

How can you run actions in the future, or repeatedly?

Sometimes, an application needs to repeatedly run the same action; e.g., to extract new data from the server or to monitor application state.
Sometimes, an application needs to run an action at some future time; e.g., to warn a user his session is about to time out.
The server can't initiate a connection to the client, so there's no way to have the server "wake up" the client according to a schedule.

Use JavaScript timers to schedule actions. JavaScript's timer mechanism lets you schedule a one-off action or an action repeating at fixed intervals. In either case, what you specify is an action and a period of time in milliseconds. Note: an online demo (http://ajaxify.com/run/scheduling) illustrates the code concepts throughout this section and the code snippets loosely follow from the demo.

The naïve way to run an event in the future would be:


  sleep(5000); // Nope, won't work.

  expire( );

That won't work because JavaScript doesn't have a sleep( ) capability—you can't just block in the middle of a script. Instead, you need to schedule the execution.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Paradoxically, we round out the foundational Ajax technologies with a pattern that's all about "non-Ajax" technologies. The term "Ajax" usually relates to the technologies provided by standard web browsers—those covered in the previous chapters. However, it's pragmatic to bend that definition when there are useful "bonus" features that require extra capabilities; hence, the Richer Plugin pattern.

○ ActiveX, Applet, Extension, Flash, Greasemonkey, Hack, Java, Mashup, Plugin, ProgressiveEnhancement, Remix

Figure 8-1: Richer Plugin

Sasha is using an online photo-sharing web site. Since she's become a big fan, she's taking the time to install some optional plugins from the site: an in-browser photo editor, a screen capture tool, and a browser toolbar.

How can you make an Ajax App even richer?

Ajax makes web interaction much more like a desktop application, but there are limits. Many applications require functionality not available to Ajax Apps.
If you develop a desktop application, even if it connects to the Internet, you forego many advantages of an Ajax App.

Make your application "more Ajax than Ajax" with a Richer Plugin. Ajax is certainly a step up in richness, but sometimes you need more than Ajax can offer. That's when you release a Richer Plugin that users install to get even more out of your application. The concept here is "progressive enhancement"—the application works fine in standard web browsers, but by installing the Richer Plugin, users can take the interaction to the next level.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

○ ActiveX, Applet, Extension, Flash, Greasemonkey, Hack, Java, Mashup, Plugin, ProgressiveEnhancement, Remix

Figure 8-1: Richer Plugin

Sasha is using an online photo-sharing web site. Since she's become a big fan, she's taking the time to install some optional plugins from the site: an in-browser photo editor, a screen capture tool, and a browser toolbar.

How can you make an Ajax App even richer?

Ajax makes web interaction much more like a desktop application, but there are limits. Many applications require functionality not available to Ajax Apps.
If you develop a desktop application, even if it connects to the Internet, you forego many advantages of an Ajax App.

Make your application "more Ajax than Ajax" with a Richer Plugin. Ajax is certainly a step up in richness, but sometimes you need more than Ajax can offer. That's when you release a Richer Plugin that users install to get even more out of your application. The concept here is "progressive enhancement"—the application works fine in standard web browsers, but by installing the Richer Plugin, users can take the interaction to the next level.

What are the things that a Richer Plugin can achieve that an Ajax App can't? Here's a summary:

Browser morphing: Adding buttons, toolbars, bookmarks, icons; changing browser behavior.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THE CONCEPT OF A WEB SERVICE HAS ALREADY BEEN INTRODUCED IN THE WEB SERVICE PATTERN, BUT the pattern leaves open many questions—for instance, what sort of messages will be sent to and from the service? How will the URLs look? How will the service relate to backend software? These are the kind of design and programming issues covered in this chapter.

RESTful Service is an overview of Representational State Transfer (REST), a popular set of patterns and idioms for consistent and intuitive web services. RPC Service has similar goals, but with a philosophy that leads to very different services. Neither REST nor Remote Procedural Call (RPC) are Ajax-specific, because they are general industry conventions for web services. However, the next pattern, Ajax Stub, is Ajax-specific, because it provides a convenient way to invoke RPC-style services from the browser.

The remaining patterns look at popular message formats used for communication between the browser and Web Services. HTML Message is a message in HTML form, usually sent from the server to be morphed directly onto the page. In contrast, the remaining messages are raw responses that usually can't be displayed directly, and that may be transferred in both directions. They are Plain-Text Message, XML Message, and JSON Message.

⊙⊙⊙ API, HTTP, REST, Standard, Universal, Web

Figure 9-1: RESTful Service

Devi's producing a public web site explaining pharmaceuticals to the public. The browser applications will pull down drug data from the server, and authorized users—such as drug manufacturers—will be allowed to upload new information. It's envisioned that third-party applications will also connect to the web server and provide their own user interfaces. For example, pharmacies will be able to use the information via their point-of-sale systems, and doctors will have access from their specialized consulting software. Devi opts to follow a RESTful architecture for all of the services exposed on the server. This makes it easy for the browser side of her own web app to access the data and exposes services in a standardized manner.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ API, HTTP, REST, Standard, Universal, Web

Figure 9-1: RESTful Service

Devi's producing a public web site explaining pharmaceuticals to the public. The browser applications will pull down drug data from the server, and authorized users—such as drug manufacturers—will be allowed to upload new information. It's envisioned that third-party applications will also connect to the web server and provide their own user interfaces. For example, pharmacies will be able to use the information via their point-of-sale systems, and doctors will have access from their specialized consulting software. Devi opts to follow a RESTful architecture for all of the services exposed on the server. This makes it easy for the browser side of her own web app to access the data and exposes services in a standardized manner.

How do you expose services on the Web?

The browser side of an Ajax App needs to call server-side services.
There might be more than one browser-side application sharing the same server-side service.
As well, it's often desirable for third-party applications to invoke the server-side service too.
With numerous different applications—and a variety of developers—accessing the service, it ought to be easy to use.
Taken as a whole, the server-based services in a single "application" form an Application Programming Interface (API). It's important that services work consistently within the API.
The basic architecture of the Web does not force any type of service architecture—any given functionality could be exposed in a wide variety of styles.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Delegate, Facade, Procedure, Proxy, Remote, Remoting, RPC, SOAP, WSDL

Figure 9-2: RPC Service

Dave's finished coding the backend services for some blogging software. There's an ArticleRepository object, for example, with functions to create, remove, update, and delete articles. Using a new product, he's able to effortlessly expose ArticleRepository as a web service API, with a different URL for each operation. Now he can code up the browser script for his own application to talk to the API, and there's a ready-made API available to third parties too.

How do you expose services on the Web?

Refer to the section "Forces" in RESTful Service.

Expose web services as Remote Procedural Calls (RPCs). Like REST, RPC is a broad term. It's somewhat ambiguous too, meaning different things to different people. This pattern uses a fairly general definition—a Remote Procedural Call (RPC) is a form of communication where the client invokes a remote procedure on the server. The definition implies:

RPCs are generally characterized as actions. The URL is usually verb-like; e.g., /game/createGame?gameId=995 or /game/updater?command=createGame&gameId=995.
Typically, though not necessarily, the remoting is designed to be relatively transparent. The server's backend is developed, and a remoting framework acts as a bridge between client and server, allowing the client to directly invoke backend operations. Often, the remoting framework is distributed across both tiers, wrapping and unwrapping messages at each end.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Delegate, Facade, Procedure, Proxy, Remote, Remoting, RPC

Figure 9-3: Ajax Stub

Devi begins working on the browser script for a trading application and soon decides she needs a way to execute a trade. There's already a method to do that on the backend TradeManager object, so after 15 seconds reconfiguring the Ajax Stub, the browser script is able to invoke the method.

How do you implement an RPC Service (see earlier in this chapter)?

Some services have to reside on the server, for reasons of security, complexity, and performance. Thus, you need to expose web services to be accessed from the browser script.
A web service should encapsulate only web-related logic and delegate any business and application logic to the backend.
This creates a redundancy: the web service and the backend logic are tied together. When one changes, the other must change, leading to more work and the risk that you'll forget to change one or the other.
The browser needs to access web services via XMLHttpRequest over HTTP, which is fundamentally different to the way both JavaScript and server-side scripts work. It's tedious to wrap and unwrap messages into a form suitable for transfer.

Use an Ajax Stub framework that allows browser scripts to directly invoke server-side operations, without having to worry about the details of XMLHttpRequest and HTTP transfer.. The aim is to let the JavaScript call remote operations as if they were regular JavaScript functions, facilitating a more natural program style.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ AHAH, Direct, Display, HTML, InnerHTML, Message, Precise, ServerSide, Visual

Figure 9-4: HTML Message

Dave's identified the need for a credit history service, providing a list of transactions. JavaScript resources are limited, so the entire HTML is created server side, and the browser application has only to morph a DOM element with the entire HTML response.

What format should be used for server responses?

The browser display needs to be dynamic in Ajax Apps.
The display changes by altering the DOM, and HTML is often used to specify the new value.
The nature of the change is often complex and needs to be determined server side.
Not all developers know JavaScript, and many feel its usage is best minimized.

Have the server generate HTML snippets to be displayed in the browser. In this approach to browser-server dialogue, the server-side service outputs some HTML, which is picked up by the XMLHttpRequest callback function and an element then morphed by setting its innerHTML property to the response HTML. In general, the server side is application-specific because the HTML response is closely tied to the application's display style.

The XMLHttpRequest allows callers to retrieve responses as either XML or plain-text. With HTML, it's usually easiest to retrieve it as a plain-text string. If the HTML is a pure XHTML document, XML is also an option, but usually that's not the case because there's no need for a header section. The entire response can be as simple as

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Acknowlegement, Custom, PlainText, Semantic, String

Figure 9-6: Plain-Text Message

Devi's working on an auto-completion form field. Every few seconds, the server needs to respond with a list of suggestions. Devi codes the server side to output the suggestions as a comma-separated list, as it's convenient to output on the server and easy to parse in the browser.

How can you transfer data between server and browser?

Ajax Apps require messages to be transmitted back and forth.
Both browser and the server must be able to access the message. That usually means the format must be easily accessed in JavaScript as well as in whichever server-side language is used.

Pass simple messages between server and browser in plain-text format. This is a broad pattern, because "plain-text" is an ambiguous term. The emphasis here is on keeping things simple—XML or JSON are often more appropriate for complex data structures, but can also add unnecessary complexity.

Despite the name, XMLHttpRequest is perfectly capable of working with plain-text responses. As discussed in XMLHttpRequest Call (Chapter 6) and XML Message (later), the browser script can decide how to interpret the response in XMLHttpRequest by switching between the responseText and responseXML properties.

Plain-text formats include:

Response Code

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Document, Format, Hierarchical, PlainOldXML, POX, Semantic, Structured, XML

Figure 9-8: XML Message

Dave is creating an Ajax search engine. The results are offered as a RESTful Service, so that external developers can create their own interface. The results are presented as XML, and Dave's own search interface pulls it down with an XMLHttpRequest call, then transforms the result to HTML.

How can you transfer data between server and browser?

Ajax Apps require messages to be transmitted back and forth.
Both browser and the server must be able to access the message. That usually means the format must be easily accessed in JavaScript as well as whichever server-side language is used.

Pass messages between server and browser in Extensible Markup Language (XML) format. It's feasible to pass XML in both directions. On the server side, it's a common way to expose structured data as text, and browser-side applications can download XML with an XMLHttpRequest Call and parse it in different ways. Where the browser needs to upload some complex data, it's fairly easy to serialize the data as XML and upload it in the body of an XMLHttpRequest Call.

XML is the definitive standard for data transfer across the industry, so just about any server-side development language has comprehensive support. The great advantage of XML over custom formats is the massive base of supporting frameworks, libraries, editors, and general tools. How you deal with XML on the server is language-specific, and a few choices are outlined in "Decisions," next. However you do it, make sure the server presents XML content with the appropriate header to ensure its handled correctly by

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ JSON, Marshal, Semantic, Serialize, YAML

Figure 9-10: JSON Message

Dave is creating an Ajax calendar. The browser periodically polls for new appointments, which the server is sending as JSON messages. Since JSON messages are just JavaScript code for object creation, Devi's browser script needs only to run eval against each message in order to reconstruct the appointment.

How can you transfer data between server and browser?

Ajax Apps require messages to be transmitted back and forth.
Both browser and the server must be able to access the message. That usually means the format must be easily accessed in JavaScript as well as whichever server-side language is used.

Pass messages between server and browser in JavaScript Object Notation (JSON) format. JSON is a standard serialization format, created in 2002 as a cleaner and lighter alternative to XML. As with XML, the object can range in complexity from a simple string to a deep hierarchical structure. Also like XML, JSON is language-neutral, meaning that you could marshall a C++ object into JSON notation and unmarshall it to form an object in Perl. But in practice, JSON is particularly suited to browser-server communication because it's a format based on JavaScript.

In fact, a JSON Message is JavaScript. This is a valid JSON Message:


  "Homer J."

You can test browser-based JSON conversion on the Basic JSON Demo (http://ajaxify.com/run/json/). As you'll see there, the JSON Message "Homer J." maps to the JavaScript string,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've looked at the basic technologies for web remoting, which leads to questions about browser-server information flow. How will you deal with multiple calls? How will you keep the browser and the server synchronized? How will you access external domains?

Call Tracking is about tracking calls and dealing with the asynchronous nature of Ajax. The next three patterns concern synchronization. With Periodic Refresh, the browser keeps requesting fresh information from the server. The opposite is Submission Throttling, where the browser keeps uploading new information to the server. An alternative to Submission Throttling, Explicit Submission involves uploading only when the user performs some action.

All of those patterns help manage bandwidth, but keeping things in sync can still be quite complex when there are lots of entities in the server and a rich interface in the browser. Distributed Events help manage the complexity.

Finally, Cross-Domain Proxy is a technique for mediating the dialogue between the browser and external servers.

⊙⊙⊙ Asynchronous, Follow, Monitor, Parallel, Tracking, XMLHttpRequest

Figure 10-1: Call Tracking

Dave is writing an Ajax chat client, and he's concerned the more vocal users will hog server resources, so he decides to enforce a policy of no more than three pending server calls at any time. Thus, the browser script pushes messages into a queue and tracks the progress of each XMLHttpRequest Call (Chapter 6) containing those commands. He can enforce his maximum call count policy by tracking the state of each call.

How can you control parallel XMLHttpRequest Calls (Chapter 6)?

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Asynchronous, Follow, Monitor, Parallel, Tracking, XMLHttpRequest

Figure 10-1: Call Tracking

Dave is writing an Ajax chat client, and he's concerned the more vocal users will hog server resources, so he decides to enforce a policy of no more than three pending server calls at any time. Thus, the browser script pushes messages into a queue and tracks the progress of each XMLHttpRequest Call (Chapter 6) containing those commands. He can enforce his maximum call count policy by tracking the state of each call.

How can you control parallel XMLHttpRequest Calls (Chapter 6)?

Fast users and busy applications often stretch networks and servers to their limits.
Asynchronous interaction is the only practical approach for Ajax applications. You don't want to block all interaction just because the network happens to be slow.
The number of simultaneous requests must be controlled, because browsers can only handle a few at a time, and also to reduce the overall load.

Track XMLHttpRequest calls as they proceed from browser to server and back again. XMLHttpRequest is a fairly basic component that needs to be augmented or wrapped for better control over asynchronous dialogue. Furthermore, it is useful to keep all these wrappers in a collection. Note that this pattern is fairly low level, and the details should generally be encapsulated in a wrapper library.

The standard mechanism for Call Tracking requires an XMLHttpRequest

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Auto-Update, Polling, Sync, Synchronise, Sychronize, Real-Time

Figure 10-2: Periodic Refresh

Devi's coding up a ticket sales web site. For each event, she wants to keep the browser updated with the number of tickets remaining. Thus, she introduces a timer so that every 30 seconds, it calls a web service to pull down the latest sales stats.

How can the application keep users informed of changes occurring on the server?

The state of many web apps is inherently volatile. Changes can come from numerous sources, such as other users, external news and data, results of complex calculations, and triggers based on the current time and date.
HTTP requests can only emerge from the client. When a state change occurs, there's no way for a server to open connections to interested clients.
One way to keep the browser updated is HTTP Streaming (Chapter 6), but, as the "Alternatives" section for that pattern explains, it's not always ideal. In particular, it's not very scalable.

The browser periodically issues an XMLHttpRequest Call to gain new information; e.g., one call every five seconds. The solution makes use of the browser's Scheduling (Chapter 7) capabilities to provide a means of keeping the user informed of latest changes.

In its simplest form, a loop can be established to run the refresh indefinitely, by continuously issuing XMLHttpRequest Calls (Chapter 6):


  setInterval(callServer, REFRESH_PERIOD_MILLIS);

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Buffer, Queue, Performance, Throttle

Figure 10-4: Submission Throttling

Devi's producing an Ajax chat web site and wants to transmit text as the user types. However, she knows some users will type faster than the system can cope with so she introduces a throttling mechanism that ensures no more than one message is uploaded every 200 milliseconds.

How can information be submitted to the server?

Information is often uploaded in bursts; e.g., a chat tool incurs many hits when a user becomes passionate about the topic, or a data entry tool incurs many hits when the user responds to some new information.
It's difficult for the server to cope with lots of messages at once.
Browsers can only handle a limited number of pending XMLHttpRequest Calls at any moment.
Each message has overheads, such as packet headers and requires some processing at each stage of the browser/server round-trip.

Instead of submitting upon each JavaScript event, retain data in a browser-based buffer and automatically upload it at fixed intervals. As with many applications of buffering and throttling, the purpose is to strike a balance between responsiveness and resources. In most cases, it would be ideal to respond to every keystroke and mouse movement—so, for example, like a desktop application, tooltips could come directly from the server as the user mouses around. But that's not practical due to bandwidth considerations, and possibly server constraints too. So to ease bandwidth—and to lessen server processing, call detail is accumulated and periodically uploaded.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Submit, Packet, Performance

Figure 10-6: Explicit Submission

Devi's producing an Ajax chat web site. She decides text will only be transmitted after the user explicitly clicks a "Done" button.

How can information be submitted to the server?

It's difficult for the server to cope with lots of messages at once.
Each message has overheads, such as packet headers, and requires some processing at each stage of the browser-server round-trip.
Users often need to manipulate a small work unit privately, and then upload it as a whole atomic unit to the server.

Instead of automatically submitting upon each browser event, require the user to explicitly request it; e.g., submit upon a button click. Typically, the user performs some work for a few seconds or minutes, and then clicks a button to tell the server. It's a familiar pattern on the Web as it feels similar to standard form submission.

The most common example is a text field, which may be an input or textarea control. While it would be possible to transmit keystrokes as they happen, that's often not desirable. In a wiki, for instance, imagine what would happen if a user deleted a paragraph in order to replace it. Any other user viewing the wiki would see the paragraph disappear! Furthermore, the history would reflect that transition state.

Where there's only one input field, it sometimes makes sense to rely on onchange or onblur events to detect that the change has been made. But how about when there are several closely related fields? Even then, some automatic submission is okay, to provide some validation information, for instance. However, if the information is important enough to cause a change to the server, Explicit Submission is a good way to ensure the user intended what's been uploaded.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Events, Feed, Listener, Messaging, MVC, Notification, Observer, PublishSubscribe, RSS, Refresh, Semantic, Synchronise, Synchronize, Update, WebFeed

Figure 10-9: Distributed Events

Devi's producing a web app for auditors at a financial institution, aiming to highlight substantial transactions. Relevant transactions are already published on the enterprise messaging system, and Devi transforms it into an RSS feed on the web server. The browser script then checks the feed every few seconds, and updates the view whenever it detects a substantial transaction occurred.

How do you decouple code in a complex application?

Ajax Apps involve at least two tiers: a browser tier and a web server tier. In practice, the web server tier is often dependent on further tiers and external systems.
Each tier can be quite complicated, containing many stateful entities (objects, HTML controls, or regular variables).
The state of all these entities must often be synchronized, in order to keep users and external systems up-to-date. The synchronization needs to occur within a tier as well as across tiers—for example, an HTML table needs to change whenever browser-side user preferences change, but also whenever the server-side database changes.
Keeping all these objects synchronized can become complex—there are about n2 possible message paths from one object to another.

Keep objects synchronized with an event mechanism

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Aggregator, Fusion, Mash-Up, Mashup, Mediator, Mix, Proxy, Tunnel

Figure 10-10: Cross-Domain Proxy

Dave's working on a job-hunting web site and wants to "mash up" content from various other sites. Each job ad is accompanied by a review from a corporate forum web site, recent company news, and a stock ticker. To get these details into the browser, the server queries several sites and exposes their content as a web service that the browser can query.

How can you augment your application with services available elsewhere on the Web?

There's a lot of data and useful services on the Web. Much of it is freely available. It's usually more effective to leverage that content than to replicate it yourself.
The "same-origin policy" constrains most Web Remoting (Chapter 6) techniques, meaning that the browser script can only talk to the server from whence it came, and not to anyone else.
External servers often use protocols and message formats that would be difficult for browser-side scripts to process. They may also require authentication, and such details should not be exposed in the browser.
To comply with service agreements, web site owners often have to control and monitor all traffic to and from their web service, which is impossible if their server is being bypassed.

Create proxying and mediating web services to facilitate communication between the browser and external domains

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

WHAT DOES THE BROWSER DO ONCE IT RECEIVES A RESPONSE FROM THE SERVER? SEVERAL OPTIONS ARE covered in this chapter. XML Data Island explains how you can store an XML document within the web page's DOM instead of converting it into a custom data structure. It also touches on some browser-specific features that let you tie the document's value to the display. XML responses are also the primary concern of Browser-Side XSLT, explaining how an XML document can be converted to XHTML for inclusion on the page, or modified for uploading back to the server. Browser-Side Templating is not XML-specific; it brings to JavaScript the embedded scripting template concept popular in many server environments, such as JSPs and PHP scripts.

⊙ Data, DOM, Storage, XBL, XML

Figure 11-1: XML Data Island

Dave's demographics viewer stores each table of statistics as an XML document. A big cache of XML documents is held within the page, one for each table. The user can rearrange the tables and switch them between visible and hidden, but all the XML metadata remains on the page. To render the tables, Dave exploits the browser's ability to translate XML into HTML tables.

How can you render incoming XML and retain the data?

Many Ajax Apps receive XML Messages and must convert them into HTML.
The incoming data often has to be retained as well.

Retain XML responses as XML Data Islands—nodes within the HTML DOM. Strictly speaking, an XML Data Island is an XML document embedded in a standard XHTML document, usually within an

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Data, DOM, Storage, XBL, XML

Figure 11-1: XML Data Island

Dave's demographics viewer stores each table of statistics as an XML document. A big cache of XML documents is held within the page, one for each table. The user can rearrange the tables and switch them between visible and hidden, but all the XML metadata remains on the page. To render the tables, Dave exploits the browser's ability to translate XML into HTML tables.

How can you render incoming XML and retain the data?

Many Ajax Apps receive XML Messages and must convert them into HTML.
The incoming data often has to be retained as well.

Retain XML responses as XML Data Islands—nodes within the HTML DOM. Strictly speaking, an XML Data Island is an XML document embedded in a standard XHTML document, usually within an <xml> tag. Say the initial page looks like this:


  <html>

    <head>

      ...

    </head>

    <body>

      <h1>Top Score</h1>

      <p>Here's the ... </p>

      ...

      <xml id="scoreData"></xml>

    </body>

  </html>

After an XMLHttpRequest Call (Chapter 6) brings the browser an XML Message (Chapter 9), the message is retained in the tag, using techniques described in a moment. The result is a web page DOM like this:


  <html>

    <head>

      ...

    </head>

    <body>

      <h1>Top Scores</h1>

      <p>Here's the ... </p>

      ...

      <xml id="scoreData">

        <score>

          <title>Galaga"</title>

          <player>AAA</player>

          <score>999610</score>

        <score>

      </xml>

    </body>

  </html>

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Presentation, Render, Style, Stylesheet, Transform, View, XML, XPath, XSLT

Figure 11-3: Browser-Side XSLT

Dave has just received a request to change the weather portlet on the homepage. The image must now be on the bottom, not the top, and the wording should be more precise. The browser receives periodic weather updates in the form of an XML specification, and it uses Browser-Side XSLT to get HTML for the portlet. The stylesheet is embedded inside the static homepage HTML file. So Dave just has to tweak the XSLT to get all the browsers rendering the new design.

How can you render incoming XML?

Many Web Services (Chapter 6) output XML Messages (Chapter 9), and Ajax clients have to convert them into HTML.
While modern browsers provide good support for XML parsing via the JavaScript's DOM support, the direct interface is lengthy and tedious to use.
Code gets complex and error-prone when you mix HTML generation with application logic. JavaScript is not well-suited to programmatically building up HTML strings from input XML.

Apply XSLT to convert XML Messages into XHTML. XSLT—Extensible Stylesheet Language Transformations (http://www.w3.org/TR/xslt)—is a language for transforming XML documents into other forms. Here, XML is transformed to XHTML, a type of HTML that conforms to the XML standard. (You could get away with converting to plain-old HTML, but things works better if you stick to XHTML.) XSLT is fairly well-supported in modern browsers and, although browser APIs vary, there are good cross-browser toolkits available.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Pages, Presentation, Render, Template, Transform, View

Figure 11-5: Browser-Side Templating

Devi has just been assigned to make the user profile more verbose. The original version takes an XML document about the user and renders it all with a jungle of JavaScript code that accumulates a big HTML string amid if-then conditions and loops. Devi decides the first step is to refactor all that into a Browser-Side Template, isolating the HTML generation. As a result, introducing the new content becomes trivial.

How can you separate presentation from logic?

Generating HTML in the browser is a good way to isolate all presentation logic in one tier.
To render context-specific information within the browser, you need to rely on a dynamic mechanism. It's not feasible to just set an element's innerHTML property to point to a static HTML page.
Code gets complex and error-prone when you mix HTML generation with application logic. JavaScript is not well-suited to programmatically building up HTML strings.

Produce templates with embedded JavaScript and call on a browser-side framework to render them as HTML. The template contains standard HTML and allows context variables to be substituted in at rendering time, which gives it more flexibility than a static HTML page. In addition, you can also intersperse JavaScript code. For instance, generate an HTML table by running a loop—one iteration for each row.

The templating idea has been used for a long time on the Web, which is evident in frameworks like Perl's HTML::Mason, Java's JSPs, and the layout of languages like PHP and ASP. All of these are syntactic sugar of the "killer app" variety. That is, they technically don't add any new functionality, but make life a whole lot easier for web developers. In the Java world, the standard complement to JSPs is servlets. Here's how you'd write a message in a servlet:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THERE ARE TWO GENERAL PROGRAMMING PATTERNS IN THIS CHAPTER. SERVER-SIDE CODE GENERATION IS one technique people are using to avoid working directly with HTML and JavaScript. Cross-Browser Component is a component that's been developed for portability across the major browsers.

⊙⊙ AutoGenerated, CodeGen, Framework, Library

Figure 12-1: Server-Side Code Generation

Dave's creating a web app with a trendy new server-side framework, ZeroWeb. The framework lets him write everything in Java as if he's writing a standalone GUI application. It's capable of using that code to generate a conventional edition of the application, An Ajax edition, a desktop edition, and—for an extra $99.95—a smartphone app too.

How do you avoid using HTML and JavaScript?

HTML and JavaScript are the only code recognized by standard browser—any Ajax App must be represented in a combination of these formats.
Ajax is increasing the complexity of HTML and JavaScript. Whereas JavaScript was previously used for simple tasks like navigation support or form validation, it's now driving the interaction in many applications.
Most Ajax Apps also have a substantial backend, which is rarely implemented in JavaScript.
It's difficult to completely separate the roles of browser-side developer and server-side developer. In fact, it's often more desirable to have the same developer working on a vertical slice of functionality; i.e., contributing a little to all tiers in order to deliver a new requirement. Thus, the same developer is often expected to work across tiers, where the environment differs significantly.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ AutoGenerated, CodeGen, Framework, Library

Figure 12-1: Server-Side Code Generation

Dave's creating a web app with a trendy new server-side framework, ZeroWeb. The framework lets him write everything in Java as if he's writing a standalone GUI application. It's capable of using that code to generate a conventional edition of the application, An Ajax edition, a desktop edition, and—for an extra $99.95—a smartphone app too.

How do you avoid using HTML and JavaScript?

HTML and JavaScript are the only code recognized by standard browser—any Ajax App must be represented in a combination of these formats.
Ajax is increasing the complexity of HTML and JavaScript. Whereas JavaScript was previously used for simple tasks like navigation support or form validation, it's now driving the interaction in many applications.
Most Ajax Apps also have a substantial backend, which is rarely implemented in JavaScript.
It's difficult to completely separate the roles of browser-side developer and server-side developer. In fact, it's often more desirable to have the same developer working on a vertical slice of functionality; i.e., contributing a little to all tiers in order to deliver a new requirement. Thus, the same developer is often expected to work across tiers, where the environment differs significantly.
Server-side development has certain advantages over JavaScript development. In some cases, there's better support for code editing, refactoring, testing, and so on.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Agnostic, Common, Component, CrossBrowser, Independent, Portable

Figure 12-4: Cross-Browser Component

Dave has developed a cross-browser sprite engine, allowing users to easily drag a sprite around the screen. The library provides a browser-independent interface, taking into account browser incompatibilities regarding detection of mouse position and positioning of icons. When a new drag-and-drop requirement comes along, programmers can code to Dave's library in blissful ignorance of the underlying browser incompatibilities.

How can you manage cross-browser incompatibilities?

A major selling point of Ajax is portability—the ability to run an application on any platform with a modern browser.
There are numerous browsers on the market, and while IE still dominates, the market is becoming increasingly fragmented. IE currently has around 85-90 percent share on average web sites, but within certain user groups, Mozilla is actually far more popular. A recent survey of AjaxPatterns.org traffic showed 47.5 percent hits from Firefox, 30.1 percent from IE, and 2.7 percent from Safari.
Browsers vary from each other in subtle and not-so-subtle ways. Sometimes, a browser simply doesn't support certain functionality. Other times, two browsers offer the same functionality, but it must be accessed in different ways. While the W3C (http://www.w3c.org) establishes standards for browsers, not all are followed.
When creating a web program, you want to focus on business and application logic, without being distracted by idiosyncrasies of underlying browsers. Cross-browser compatibility is a cross-cutting concern, best dealt with as a separate task at a separate time.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THE PERFORMANCE OPTIMIZATION PATTERNS IMPROVE THROUGHPUT AS WELL AS APPLY SOME USER-centered techniques to ease the pain of waiting for the server. Browser-Side Cache talks about implementing a custom cache within the application and explains why it's sometimes more suitable than the standard web browser cache. Predictive Fetch extends the cache concept by proposing that likely actions be anticipated, so that required data is already sitting in the browser by the time it's required. Another very different way to achieve zero network delay is to simply take a stab at the required value, the idea behind Guesstimate.

Multi-Stage Download proposes parallel or scheduled downloads so as to reduce bottlenecks and grab the most critical details as early as possible.

Fat Client is one of several possible Ajax architectural styles that helps optimize performance by pushing as much logic as possible—and potentially storage—over to the browser side.

⊙ Auto-Update, Memoise, Memoize, Sync, Synchronise, Sychronize, Real-Time

Figure 13-1: Browser-Side Cache

Devi's produced a physics simulation and, though it's functional, she's disappointed that it keeps pausing to request calculations from the server. To speed it up, she sets up a cache that will retain the calculations locally.

How can you make the system respond quickly to user activity?

The application should respond to user actions quickly—ideally, instantaneously.
Many user actions require a response from the server.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Auto-Update, Memoise, Memoize, Sync, Synchronise, Sychronize, Real-Time

Figure 13-1: Browser-Side Cache

Devi's produced a physics simulation and, though it's functional, she's disappointed that it keeps pausing to request calculations from the server. To speed it up, she sets up a cache that will retain the calculations locally.

How can you make the system respond quickly to user activity?

The application should respond to user actions quickly—ideally, instantaneously.
Many user actions require a response from the server.
Responses from the server can be noticeably latent due to data transfer and server processing overheads.

Retain server results in a Browser-Side Cache. The cache is a JavaScript map-style object that holds query-result pairs; the queries are cache keys and the server results are server results. So whenever the browser needs to query the server, first check the cache. If the query is held as a key in the cache, the corresponding value is used as the result, and there's no need to access the server. Caching like this is performed in many systems, but there are some interesting Ajax-specific issues, such as the relationship with the browser's built-in cache and the asynchronous nature of calls.

XMLHttpRequest Call (Chapter 6) explains that call results can already be cached by the browser, so you might wonder why this pattern exists. After all, the browser not only handles caching for you, but can cache huge quantities of data using the filesystem, and, unlike a Browser-Side Cache, this data will usually live beyond the current session. The reason you'd use a Browser-Side Cache is to exert more control over caching. You get to choose how much data is cached and how long it lasts, whereas those things are set by the user in a web browser cache. Moreover, you bypass the notorious portability issues associated with cache control, choosing exactly what will be and what will not be cached. Another advantage of a Browser-Side Cache over the web browser's cache is that you can save JavaScript objects you've built up, thus saving the effort of reconstructing them later on (a process known as "memoisation").

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Anticipate, Fetch, Guess, Prefetch, Preload, Prepare, Ready

Figure 13-3: Predictive Fetch

Dave's tuning a music web site and the logs tell him that users who listen to a song for more than a minute are quite likely to click the Purchase button. So he introduces a new timer—at the one-minute mark of each song, the browser will quietly download pricing data just in case the user wants to buy it later on.

How can you make the system respond quickly to user activity?

The application should respond to user actions quickly; ideally, it should feel instantaneous.
Many user actions require a response from the server.
Responses from the server can be noticeably latent due to data transfer and server processing overheads.

Pre-fetch content in anticipation of likely user actions. Pre-fetching attempts to remove the delay altogether for certain user actions.

The obvious motivation for instantaneous feedback is efficiency: the things can happen faster because the user's not sitting around waiting for results. In reality, though, the proportion of overall time waiting might actually be quite small. The more severe problem is distraction, because delays will break the user's concentration, along with the sense of frustration at not being in control. The other problem is that for real-time applications, the user is slower to respond to state conveyed by the server. A chat session will be more strained, and a remote device under browser control will be more erratic.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Approximate, Estimate, Extrapolate, Fuzzy, Guess, Guesstimate, Interpolate, Predict, Probabilistic, Sloppy, Trend

Figure 13-5: Guesstimate

Devi's producing a taxi tracker so the head office knows where its fleet is at any time. The taxis only transmit their location every 10 seconds, which would ordinarily lead to jerky movements on the map. However, Devi wants the motion to be smooth, so she uses interpolation to guess the taxi's location between updates.

How can you cut down on calls to the server?

To comprehend system activity and predict what might happen next, it's useful to have frequent updates from the server.
It's expensive to keep updating from the server.

Instead of requesting information from the server, make a reasonable guess. There are times when it's better to provide a good guess than nothing at all. Typically, this pattern relates to dynamic situations where the browser periodically grabs new information, using Periodic Refresh. The aim is help the user spot general trends, which are often more important than precise figures. It's a performance optimization because it allows you to give almost the same benefit as if the data was really arriving instantaneously, but without the bandwidth overhead. For this reason, it makes more sense when using Periodic Refresh than HTTP Streaming, because the latter doesn't incur as much overhead in sending frequent messages.

One type of Guesstimate is based on historical data. There are several ways the browser might have access to such data:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Download, Incremental, Multi-Stage, Parallel

Figure 13-8: Multi-Stage Download

Dave's been informed an e-commerce homepage is turning many users away with its absurdly slow initial download. He refactors it so the initial download is nothing more than a banner and the key navigation links. News and featured items are still on the page, but they're pulled down separately, after the initial page has loaded.

How can you optimize downloading performance?

Content can be time-consuming to load, especially when it contains rich images.
Users rarely need to read all the content on the page.
Users often have to click through several times to locate a particular item.
Users sometimes browse around by exploring links between pages.

Break content download into multiple stages, so that faster and more important content will arrive first. Typically, the page is divided into placeholders (e.g., div elements) with the content for each placeholder downloaded independently. XMLHttpRequest Calls can be issued simultaneously or in a serial sequence, and the page will gradually be populated as the calls return.

The pattern applies when an application needs to download a lot of content from the server. Typically, this occurs on startup and also when a major context switch occurs. By breaking up the call, you can deliver faster and more important data earlier on. You avoid bottlenecks that occur when a single piece of content blocks everything else from returning.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ BrowserSide, Decoupled, DHTML, Fast, Responsive, Rich, Thick

Figure 13-11: Fat Client

Dave's new mortgage application is very quick as it avoids server calls wherever possible. After some benchmarking, he discovered that optimized JavaScript is actually fast enough to run the financial algorithms in the browser, so that users now receive almost immediate feedback as they tweak parameters.

How can you architect the system to feel truly rich and interactive?

The application should respond to user actions quickly—ideally, instantaneously.
Responses from the server can be noticeably latent due to data transfer and server processing overheads.

Create a responsive Ajax App by performing remote calls only when there is no way to achieve the same effect in the browser. Whereas the server is traditionally the realm of more complex processing, this pattern suggests harnessing the browser for all it's worth. In the extreme case, it means running just about everything inside the browser, but that's not the main message here. The main message is to reconsider the traditional server-centric view of web architecture; for developers to be more conscious about decisions on matters regarding where the various components live. Placing more logic inside the browser gives you the opportunity to make the application more responsive.

Web apps usually have several layers:

User interface

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THE WIDGETS PROVIDED BY STANDARD HTML—TEXT INPUTS, RADIOBUTTONS, AND SO ON—HAVEN'T changed much for ten years and are getting a little tired. So many people have been building their own widgets on top of the standard HTML offerings, and a few patterns have emerged. It's unlikely you'll need to build these widgets yourself, because library implementations are available for almost all of them. Nevertheless, it's worth it to consider when to use them and how to configure them.

The chapter starts with smaller, isolated widgets and builds up to more complex components. Slider is "the widget HTML forgot"—a typical slider widget so useful it's surprising it hasn't yet become standard HTML. Progress Indicator is a simple message or animation shown while waiting for a web remoting call. Drilldown is a control for selecting an element within a hierarchy.

Traditional HTML widgets are turbo-charged in the next couple of patterns. Data Grid is a "table on steroids," with tools for querying and restructuring that will be familiar to users of spreadsheets and database report tools. And Rich Text Editor is a "textarea on steroids," with options such as font size and color similar to those of a modern word processor.

Suggestion is similar to the traditional combo-box, a mixture between browsing and searching that relies on web remoting to locate a set of options against a partial text input. Live Search works similarly but shows search results rather than helping to complete a text field. It also works with nontext controls.

Finally, Live Command-Line and Live Form are higher-level patterns that tie together various widgets and patterns. The former is largely speculative and explores techniques to help people learn and use command-line interfaces within the Web. The latter is a more proven Ajax Pattern—a form that keeps changing in response to user input.

⊙⊙⊙ Continuous, Lever, Multiple, Range, Slider

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Continuous, Lever, Multiple, Range, Slider

Figure 14-1: Slider

Stuart is rating his lecturer online. Each answer lies somewhere between "Strongly Disagree" and "Strongly Agree." Unlike conventional surveys, the scale is continuous, because Stuart uses a Slider to set a precise value along the spectrum.

How can users specify a value within a range?

Most data is constrained to reside within a range.
Prevention is better than cure; the user interface should be designed such that the user is forced to choose a value within the range instead of the interface checking and providing an error message later on.

Provide a Slider to let the user choose a value within a range. The user drags a handle along one dimension to set the value. As a variant, two handles on the same Slider can allow the user to choose a range instead of a single value.

Standard HTML contains two related input controls: radiobuttons and selectors. Each of these lets you specify a value from a fixed list of choices. The biggest advantage of a Slider is that the data range can be continuous as well as discrete. Of course, "continuous" is an approximation, since you can only have as many choices as there are pixels in the Slider range. But with most Sliders, that means you have hundreds of unique values, which is continuous for most intents and purposes.

A Slider can also show discrete data by identifying several points along the range. When the user releases the handle, the Slider jumps to the nearest point. Why use a Slider when radio buttons and selectors already support discrete data? A Slider provides a better visual indication that the data resides in a spectrum. Also, it's often faster because the user can click anywhere in the region as opposed to aiming precisely at a radiobutton or opening up a dialog box.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Activity, Feedback, Hourglass, Meter, Progress, Waiting

Figure 14-4: Progress Indicator

Reta has made a sale and is typing in the details. She completes the credit card details and proceeds down the page to delivery dates. Meanwhile, the status area has appeared beside the credit card details. While she completes the rest of the form, the status area continues to update with the current verification stage—initially "submitted," then "responding," then "verified."

How can you provide feedback while waiting for server responses?

Ajax Apps often make XMLHttpRequest Calls (Chapter 6) to query and update the server.
To provide good feedback, you should provide an idea of which page elements are affected by any update.
Users like to feel in control, and that control is taken away when the user is waiting for a response. It's not just the delay that should be minimized, but the perceived delay.

Indicate the progress of server calls. You can't always reduce delay, but you can include a Progress Indicator to ease the pain. A Progress Indicator helps maintain the user's attention, improves the user's understanding of how the system works, and also communicates that the system is still alive even if a response hasn't yet occurred.

The Progress Indicator is typically introduced to the DOM once an XMLHttpRequest Call begins and removed when the call has returned. The easiest way to detect whether the call has returned is using the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Drilldown, Menu, Progressive

Figure 14-6: Drilldown

Pam is booking a trip on the corporate travel planner. She sees a form with the usual fields and clicks on location. Suddenly, a list of cities fades in beside the form, and Pam selects Paris. Beside the city list, a third list appears, this one showing approved hotels. Pam chooses the Hilton, and both lists disappear. The location field now contains "Paris Hilton" as Pam had intended.

How can the user select an item in a hierarchical structure?

Applications and web sites are often arranged in hierarchies. To navigate, users need to choose a page from within the hierarchy.
Hierarchy navigation should be fast.

To let the user locate an item within a hierarchy, provide a dynamic Drilldown. The Drilldown allows for navigation through a hierarchy and ultimately for an item to be chosen. At each level, there are several types of elements in the Drilldown:

Current category: A read-only name for the present level.
Individual items: Items the user can choose in order to end the interaction.
Child categories

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Database, Query, Report, Summary, Table

Figure 14-11: Data Grid

Reta is doing a little data mining on this season's sales figures. She's scrolling through a table showing a row for every transaction. Noticing that higher sales figures tend to come in the morning, she sorts the table by sales figure. There's too much data there, so she filters out any transactions below $1,000, then groups the transactions by time of day.

How can you help users explore data?

Ajax Apps have their own databases, as well as access to external systems.
Users need a way to explore all this data, in order to verify it, understand how it works, predict future trends, and so on.
You can't anticipate what users will need to do with data.

Report on some data in a rich table and support common querying functions. A Data Grid has the familiar database client interface: a table with a row for each result and a column for each property. Think of it as a traditional table on steroids. Typical database client functionality is as follows (and it's feasible to achieve each of these in an Ajax interface):

Sorting: Each column can be usually be sorted by clicking on the header. To let the user sort by more than one category, use a sorting algorithm that preserves the order of equal values. Then, users can click on one header followed by the other.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Editor, Formatting, Fonts, Rich, Text, Textarea, Toolbar, Write, WordProcessor, WYSIWYG

Figure 14-14: Rich Text Editor

Pam is working on a presentation for the steering committee; style will count here. From the toolbar, she sets the font to Arial, the size to 24 pt, and switches italics on. She then types out the heading, selects it, and moves to the toolbar again to set the color scheme.

How can users create and maintain rich content?

Many Ajax Apps let users create and edit substantial chunks of content.
Rich content for the Web needs to make the most of HTML and go well beyond a string of plain-text.
Most users don't know HTML; even "easy" markup substitutes for HTML are complicated and inconsistent.

Incorporate a Rich Text Editor widget with easy formatting and WYSIWYG display. Typically, the widget looks like a mini word processor: a toolbar on top with a rich editing area underneath. The editing area is usually a div rather than a textarea, meaning that any HTML content is possible.

Typical features include:

Flexible font styles, sizes, boldfacing, etc.
Flexible color schemes
Embedded images
Embedded tables
Bullet-point and numeric lists

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Auto-Complete, Fill, Intelligent, Populate, Predict, Suggest, Wizard

Figure 14-18: Suggestion

Doc is typing out an electronic prescription. He intends to prescribe "Vancomycin 65 mg," but as soon as he types in "V", the system has already detected a handful of likely choices, based on the patient's history and Doc's prescription style. Doc selects "Vancomycin 65 mg" from the list and proceeds to the next field.

How can you improve throughput?

Free text remains the most powerful way for humans to communicate with computers. The trend seems to be toward more typing than ever before due to instant messaging, blogging, and email. Even search engines are undergoing a transformation to become general-purpose, as described in Live Command-Line later in this chapter.
When presented with a free text area, people don't always know what they're meant to type in.
Though many users are now quick on the keyboard, there are still many users for whom the Web is a click-mostly experience.
Typing speed remains a bottleneck even for fast typists, most of whom think faster than they can type.
People make mistakes when they type.

Suggest words or phrases that are likely to complete what the user is typing. The user can then select the Suggestion and avoid typing it in full. The results usually come from an

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Feedback, Immediate, Live, Real-Time, Search

Figure 14-21: Live Search

Browsing a trade magazine, Reta has just spotted the "Curiously Costly" line of shoes and declared them a "must-have" for the upcoming season. She heads over to her favorite wholesaler's web site and sees an empty search form with an assortment of products underneath it and the message, "50,000+ items." First, she selects "shoes" from a drop-down and watches as the products below morph into a collection of shoes; the message is now "8,000+ shoes." Then, she begins typing. As she types "C," she now sees all 500 shoes beginning with "C." This continues until the search field contains "Curio," at which point only three items remain. One of those is "Curiously Costly," which is what Reta clicks on to successfully conclude the search.

How can users quickly search for an item?

Ajax Apps often require a search capability. Users search for business objects, other users, web sites, and more.
Sometimes the user is searching for a needle in a very large haystack. In the case of search engines, a haystack of over a billion items.
To help deal with the complexity, users should be free to experiment.

As the user constructs and refines his search query, continuously show all valid results. The search query is a combination of controls that lets the user narrow down the collection of items. It may be a straightforward text field, or a complex arrangement of Sliders

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

○ Assistive, CLI, Command-Line, Grammar, Supportive

Figure 14-25: Live Command-Line

Frank is using an advanced query tool to run a report on current output. He begins entering an SQL-like query: "list all." At this point, a suggestion list appears with all the things that can be listed, and he chooses "products." Continuing on, the query now reads "list all products where" and a new list appears: "creationTime," "quality," and so on. He chooses "creationTime," and. then enters the rest manually, preferring to ignore further suggestions. The query ends up as "list all products where creationTime is today and quality is faulty." There's a tick mark next to the query to indicate that it's valid.

How can a command-line interface be supported?

Users can only say so much with point-and-click interfaces. The command line is more expressive and remains the tool of choice for expert users.
URLs and search fields are becoming general-purpose command-lines (http://www.codinghorror.com/blog/archives/000296.html).

In command-line interfaces, monitor the command being composed and dynamically modify the interface to support the interaction. The interface changes according to data, business logic, and application logic. When the command line is to be executed on the server, as is often the case, the browser usually delegates to the server the task of evaluating the partial command.

The command line is the quintessential expert interface and it's worth bearing in mind that most users are "perpetual intermediates" (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Dynamic, Live, Real-Time, Validation

Figure 14-27: Live Form

Tracy is using a Live Form to apply for a new online brokerage account. Upon declaring her place of residence, some additional regulation-related questions specific to her region appear. Several asset classes can be traded. She clicks a box to indicate that she wants to trade in bonds, and further questions specifically for that asset class appear. She then clicks on another box, for options. A moment later, a warning appears that new users can trade in either options or bonds, but not both. After further refinement, she successfully submits the form and sees it fade into a welcome message.

How can the user submit data as quickly as possible?

Most data submission tasks require some flexibility. A particular answer for one item may necessitate further questions. Often, this must occur server side, where business logic and data usually reside.
Most data submission requires validation. This must occur server side to prevent browser-side manipulation of inputs.
Users get frustrated waiting for data to be validated and continuously refining data upon each explicit submission.

Validate and modify a form throughout the entire interaction instead of waiting for an explicit submission. Each significant user event results in some browser-side processing, often leading to an XMLHttpRequest Call. The form may then be modified as a result.

Modifying the form is similar to responding to a Microlink

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THE "PAGE ARCHITECTURE" PATTERNS ARE A VARIETY OF INTERACTION STYLES AND STRATEGIES FOR structuring content. In many cases, it is the possibility of web remoting that makes these patterns worth using.

Drag-And-Drop has been a fixture on the desktop for a couple of decades but is only now gaining currency in the browser. One situation in which it's used is with the Sprite pattern. A Sprite is a little icon that lives "in front of" the main document and can move around freely like a character in a video game. The next pattern, Popup, uses the same overlay technique, but for larger, dialog-style content.

Malleable Content is content that appears to be read-only but becomes editable upon a gesture such as a mouse rollover, a fairly new idiom because it relies on web remoting. Similarly, a Microlink is a link that uses remoting to conjure up content for insertion in the page.

A Portlet is a small component of the page that acts like a mini-application, capable of conducting a conversation with the server independent of the main page flow. A Status Area provides information about current and past activity and is relevant to Page Architecture because it helps reduce the space occupied by each individual element. Update Control allows the user to control information flow on the page. The final pattern, Virtual Workspace, lets the user explore a large server-side structure, yet it makes the remoting transparent, creating the illusion that everything's happening in the browser.

⊙⊙ Drag, Move, Pull, Rearrange

Figure 15-1: Drag-And-Drop

Stuart is purchasing books online. Each time he wants to buy one, he drags the book icon into a shopping cart.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Drag, Move, Pull, Rearrange

Figure 15-1: Drag-And-Drop

Stuart is purchasing books online. Each time he wants to buy one, he drags the book icon into a shopping cart.

How can users rearrange objects on the page?

Object relationships are important and the user's task often involves changing those relationships.
Ajax Apps often represent object relationships visually.
Rearranging the visual structure from a separate form is messy—i.e., trying to map between the form and the visual structure is confusing and error-prone. It's easiest if users can directly manipulate the visual structure.

Provide a Drag-And-Drop mechanism to let users directly rearrange elements on the page. Drag-And-Drop has proven itself to be a powerful control mechanism in conventional desktop applications; it is certainly achievable using standard web technologies. The basics are straightforward: the user holds down the mouse button while the mouse hovers over a page element, then moves the mouse with the button still depressed. The element follows the mouse around until the user finally releases it.

Constraints are sometimes applied to the extent of movement. For example, an element may only be able to move in one direction, or within a bounding box. Also, the element might move permanently when the mouse is released, or flip back to its original position. Another variable is exactly which part of the element must be dragged. Sometimes it's better to define a "handle" region—a specified place where the element can be "picked up" for dragging. The main benefit to this is that it allows the user to click elsewhere in this region.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Bitmap, Buffer, Character, Layer, Overlay, Shape, Sprite, Z-Index

Figure 15-2: Sprite

Not for the first time, Pam is negotiating to eliminate a stack of requirements from the project goals. Having successfully convinced the client that "Security Features" was never really worthwhile, she drags a "Magic Eraser" Sprite from the Tool Palette to the "Security Features" requirement, jiggles the mouse a couple of times, and the eraser is animated for a second as the requirement fades away.

How can you ensure that visual content is flexible?

Rich visual displays are often the most effective way to present information.
Information frequently changes as the user interacts with and new data is received from the server; hence, the visual display needs to update frequently.
It's expensive to continuously download new visual content.

Augment the display with Sprites—i.e., small, flexible, icon-like blocks of content. Typically, the Sprites are images, but they may also be div elements containing text or images or a combination of both. The name refers to the Sprites used in traditional graphics programming, particularly gamin—those little graphics representing players, enemies, and other objects capable of moving around a scene and animating themselves to reflect current activity. The entire scene does not need to be recomputed each time, only the Sprites. DOM elements are not (yet) capable of more advanced features such as arbitrary rotation, but many aspects of Sprites can actually be translated to a web context.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Balloon, Dialog, Hover, Popup, Transparent, Tooltip

Figure 15-5: Popup

Frank is monitoring the factory equipment online and notices the T1000 machine is acting a little funny. He clicks on the icon, holds the mouse button down for a second, and up pops an information sheet about the T1000 model. The sheet is partially transparent and overlayed on top of a region of the plant diagram.

How can the user perform a quick task without distracting from the main flow?

Users often need to make a quick change, which requires that they have some extra controls with which to interact.
Users often need to perform a quick lookup, get further details about an object in the application, or just find some general information. This requires that extra information appear.
Screen real estate is limited, and minor, quick changes don't warrant a major change to the user interface.

Support quick tasks and lookups with transient Popups, blocks of content that appear "in front of" the standard content. Usually, the content is partially transparent, is about the size of a standard dialog, and hovers above the page until the user explicitly closes it. A more subtle variant is the tooltip, a solid block usually containing content between one word and a paragraph in length. The tooltip itself has a trendy new variant, a cartoonish balloon. For Progress Indicators (Chapter 14), a popular idiom is to use a small label in the corner with a message like "Saving . . . ." Figure 15-6 illustrates several popular styles.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Affordance, Collaborate, Edit, Hint, Input, Microcontent, Mutable, Outline, P2P, Selection

Figure 15-9: Malleable Content

Reta is logged in and is revamping the catalogue web site. It looks clean, a replica of the read-only page that public users will see. But as she runs the mouse down the screen, she sees that many regions can be edited.

How can you let users change content?

The Web is not just about consuming information. Administrators, and increasingly everyday users, spend a lot of time adding and editing content.
All users, no matter what their roles are, need to know what they're allowed to change.
To encourage contributions and improve user experience, editing should be simple and free of barriers.
Editable content pages are often ugly, with an overload of form controls, labels, and buttons. Worse, they create a divide between the contributors and the readers; while editing content, it's often difficult to imagine how a reader will see it.

Compose the page of Malleable Content blocks—small chunks of content that can be edited in page. The page is structured in chunks of small "microcontent," each editable in isolation. There might be a way to edit the whole page too, but the usual style of editing is to view the read-only display and carve up little pieces as you see fit.

The reload problem is one reason why conventional web sites must present large forms in which everything can be set at once. It's often the only practical way to edit content. However, users have difficulty relating the editing interface to the readable interface. Worse, it discourages editing; users are subjected to a sequence of at least two-page reloads in order to change a single character.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Appear, Conjure, Emerge, Hyperlink, Insert, Introduce, In-Page

Figure 15-13: Microlink

Frustrated with a developer's productivity, Pam logs into the version control system and sees a "Project Committers" table. Each row includes a developer's name and photo, and Pam immediately clicks on one of the names. The row expands out to reveal a mini-summary of the developer's project activity, and a bunch of links to further content.

How can the user quickly navigate through content?

Ajax Apps often respond to user requests by providing new content.
To encourage interaction with the system, content should be shown quickly and without distraction.
Page reloads slow down interaction, break concentration, and obscure the nature of whatever changes have occurred.

Provide Microlinks that open up new content on the existing page rather than loading a new page.Microlink is an Ajaxian upgrade of the traditional hyperlink. Most often, it entails fetching content from the server with an XMLHttpRequest Call and inserting it onto the page. The content is usually a tightly scoped block of Microcontent, though it need not be—a Microlink could be used to open a whole page of content, for example.

The term Microlink should not be taken here as a literal translation of textual hyperlinks. It's used to represent any form of content being inserted into the page. The trigger might be something as subtle as a form field focus event.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Block, Conversation, Dialogue, Gadget, Independent, Parallel, Portal, Portlet, Widget

Figure 15-15: Portlet

The sidebar of Tracy's stock trading system contains a few independent blocks down the side: a currency Portlet, a calculator, and a miniature chart generator. Right now, she is checking on the USD/EUR exchange rate in one of those blocks. She types "USDEUR" into the text field, and the block updates a moment later to show the rate. Everything else on the page remains the same.

How can the user conduct rich conversations in parallel?

A complex application contains a range of loosely related functionality. The user often needs to work on these things in parallel, gathering knowledge about one thing and using it to influence another.
It isn't just different functionality, but different data that users need to work with in parallel.
These conversations need to be "rich." They require conversational state to keep track of what's occurred so far and what can happen next, and they require interaction with the server.
It's important to retain the state of each conversation between the user and the application. You don't want to invalidate one activity just because the user chose to initiate another.

Introduce Portlets—isolated blocks of content with independent conversational state. A Portlet is like a mini-application inside a regular application. It presents a little bit of information and usually some controls. The user can communicate via the controls, which causes the Portlet to update.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Console, Log, Message, Status

Figure 15-18: Status Area

Pam wants to revise the list of project issues. As she begins checking off those that are now resolved, she notices the Status Area below update, which is showing the number of issues resolved and the number still outstanding.

How can you show auxiliary information?

The same data can be represented in different ways.
Users often benefit from redundant summary information.
Screen real estate is limited; you can't augment each field with its own summary information.

Include a read-only Status Area to report on current and past activity. The Status Area is usually auto-generated text based on some aspect of system state. The main purpose is to save space by occupying a region with information from different sources. This is done by dynamically altering the information according to current context.

Applications of the Status Area include the following:

Summarizing information about elements the mouse is hovering over.
Summarizing information about the element being edited.
Summarizing information about the overall application state.
Capturing past events in a log.
Offering a preview.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Backwards, FastForward, Forwards, Freeze, Pause, Push, Refresh, Rewind, Reverse, Speed, Sticky, Update

Figure 15-20: Update Control

Sasha is entranced by a world map that continuously updates with events from around the world. She plays around with the velocity controls, first speeding it up so there's a new event every second (no matter how trivial), then backtracking through previous events, and finally pausing on something that catches her eye.

How can the user deal with continuous information entering the browser and updating the page?

Many Ajax Apps continuously grab data from the server and place it on the page.
The web page has a limited area, so you'll need to remove or relegate older content.
The optimum speed of updating depends on the user and his task. It should be fairly quick if the user is actively monitoring, for example, and probably quite slow if the content is a bit of eye candy at the edge of a page.

Let the user control the rate and criteria of updates. When using patterns such as HTTP Streaming (Chapter 6) and Periodic Refresh (Chapter 10), it's possible to keep grabbing fresh content from the server, so you can show news updates, system events, and more. The trend is increasing, with photo slideshows, news updates, and so on, and it can easily lead to information overload. This pattern is about giving the user control over the incoming stream of information. It takes several forms.

First, the user can control the rate of change, by pausing, rewinding, and fast-forwarding. Pausing is important for several reasons: it gives the user an ability to reflect on the content, it lets him keep the content open while perform work related to it, and it lets him interact with the content in the case that it contains links or other forms of control. This is a serious issue in interfaces like Digg Spy (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Camera, Desktop, Illusion, Infinite, InfiniteScrollbar, Lens, Move, Pan, Portal, Scroll, Solipsism, Viewport, Virtual, Visible, Window, Zoom

Figure 15-23: Virtual Workspace

Bill is using a meta-search engine to receive insurance quotes. The browser can't retrieve all 500 results at once, but Bill sees a table containing what looks like all the results. He can scroll up and down as if it were a regular table, and the newly appearing rows are populated on demand.

How can the user navigate through a large workspace?

Ajax Apps often require data from the server.
On the server side, data storage is virtually unlimited—search engines, for example, store billions of web pages. Even on corporate intranets, query results are often huge; try searching for every retail transaction on a given day.
The application should respond to data requests as quickly as possible.
Bandwidth constraints mean it's not feasible for an interactive application to download the entire search result. Yet users should be free to explore the whole thing.

Provide a browser-side view into a server-side workspace, allowing users to navigate the entire workspace as if it were held locally. The illusion is that the entire workspace is already in the browser, but the reality is that the server actually provides content on demand. At any time, the user is looking at an "opening" or "portal" into the entire workspace. He can pan across, jump to a different region, and zoom in and out. Each of these actions requires a view change, so the browser transparently fetches the data for the new portion of the workspace and renders it accordingly.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

ARICH INTERFACE IS MORE THAN STATIC WIDGETS; THERE'S A DYNAMIC COMPONENT THAT HAS A BIG impact on usability. Used carefully, visual effects can guide the user's attention and help him understand what the application is doing. And don't underestimate the aesthetic benefits. It might be eye candy, but good eye candy (not just "how good am I" hacks) makes passionate users.

The "One-Second" effects are fleeting effects that sometimes convey a permanent transition from one state to another, and other times are used just to highlight something. One-Second Spotlight is a more general version of the popular "Yellow Fading Technique" and involves changes to brightness and color. In One-Second Mutation, the element changes shape, and in One-Second Motion, the element moves around.

Highlight is a more permanent effect where one or more elements are highlighted, typically because the user has selected them.

⊙⊙⊙ Attention, Effect, EyeCandy, Fade, Fading, Graphics, Refresh, Update, YellowFadeTechnique

Figure 16-1: One-Second Spotlight

Tracy is checking out her portfolio, which shows each stock in its own row. Suddenly, "Neverland Mining Co." stock plummets, and its row lights up to reflect the change. Tracy's attention is drawn instantly to this visual effect, and she immediately begins to offload her stake in the company.

How can you direct the user's attention to spots on the page?

To ensure that the user is working with current data, the browser display must be frequently updated.
With Ajax, it's possible to update only the portion of the screen that has changed, and if nothing has changed, the display will remain exactly as is.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Attention, Effect, EyeCandy, Fade, Fading, Graphics, Refresh, Update, YellowFadeTechnique

Figure 16-1: One-Second Spotlight

Tracy is checking out her portfolio, which shows each stock in its own row. Suddenly, "Neverland Mining Co." stock plummets, and its row lights up to reflect the change. Tracy's attention is drawn instantly to this visual effect, and she immediately begins to offload her stake in the company.

How can you direct the user's attention to spots on the page?

To ensure that the user is working with current data, the browser display must be frequently updated.
With Ajax, it's possible to update only the portion of the screen that has changed, and if nothing has changed, the display will remain exactly as is.
The screen can get cluttered with a lot of information, much of which might change at any time.
While human vision is good at spotting changes, it's easy to miss a sudden change, especially if it's a subtle one.

When a display element undergoes a value change—or any other significant change—dynamically increase its brightness for about a second. As a device for communicating system activity, the One-Second Spotlight accomplishes several things:

It highlights changes so the user doesn't have to actively monitor for changes and try to remember what—if anything—has changed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Auto-Update, Sync, Sychronize, Real-Time

Figure 16-4: One-Second Mutation

Doc monitors a patient's condition, watching some histograms shrink and grow to reflect changes in the patient's body.

There's a lot of activity in an Ajax App; how can you help the user digest it all?

To ensure that the user is working with current data, the browser display must be frequently updated.
With Ajax, it's possible to update only the portion of the screen that has changed; if nothing has changed, the display remains exactly as is.
The screen can get cluttered with a lot of information, much of which could change at any time.
While human vision is good at spotting changes, it's easy to miss a sudden change, especially if the change is a subtle one.
There are different types of changes, and those differences are important to users.

When a page element undergoes a value change or some other significant event, dynamically mutate its shape for about a second. In most cases, the mutation is used to reflect a permanent change. Instead of flipping from one form to another, the element gradually transitions into another form. The effect serves a few purposes:

The mutation and the extended transition time make it likely that the user will notice that something has happened.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Copy, Displace, Duplicate, Jump, Leap, Move, Movement, Motion, Rearrange, Transfer

Figure 16-7: One Second Motion

Bill is adding a new monthly bank order. The existing orders are shown in the usual way—as a table with one row per order, sorted by cost. Once he is verified the new order form, it morphs to become a table row, then slowly drifts down the table. It soon reaches its rightful place in the sorted table, which is ordered by amount, and comes to rest after bouncing up and down a little due to reverberation.

How can you communicate that an element is shifting from one position to another?

An element's location is important, as it can provide cues about its prominence and its relationship to other elements.
An element sometimes needs to move from one place to another.
Similarly, a new element sometimes needs to be created and then move from where it was created to another location.
When an element changes position, the user often needs to know about it.

Incrementally move an element from one location to another, or temporarily move it, to communicate that an event has occurred. In most cases, the motion of the element involves a permanent change in its position. It can also be used to show a temporary displacement or gesture, such as a vibration effect.

There are several benefits of showing the motion explicitly:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙⊙ Auto-Update, Sync, Sychronize, Real-Time

Figure 16-8: Metaphor

Sasha notices that a few spam comments have appeared on an old blog posting. When she clicks on the comments, they are successively Highlighted—the background color switches from white to yellow. Because she's already logged in, there's a Delete Spam button below the comments, which she clicks to send them where they belong.

How can you make elements stand out?

An Ajax App can enable a lot of information to be shown at once—often information with many with different states.
There is usually one element which the user is working on or about to activate.
In addition, the user often needs to group several elements together to perform a common function. These elements must stand out from the crowd.

Highlight elements by rendering them in a consistent, attention-grabbing format. This pattern has been applied to dynamic web sites prior to Ajax but is particularly important in the context of rich displays and interaction.

Consistency is important here; when items are selected, they should look the same. One straightforward way to achieve this is with selected and deselected CSS classes. By dynamically switching the element's className property, you can easily Highlight and de-Highlight.

Highlighting is useful in the following ways:

To show which particular element has input focus.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THIS CHAPTER CONTAINS A NUMBER OF HIGHER-LEVEL PATTERNS THAT ARE MORE GEARED TOWARD offering new functionality than modifying the user interface. Technical barriers have prevented these from being used much on the Web, but Ajax technologies are helping to break down the barrier.

Lazy Registration addresses the issue of managing the lifecycle of a user profile. Instead of a binary "you're registered or you're not" perspective, Lazy Registration advocates a more gradual accumulation of user data and authentication credentials. A related pattern is Direct Login, which explains how to let the user securely log in without forcing a page refresh. It incorporates browser-side encryption, a theme at the heart of the next pattern, Host-Proof Hosting. The purpose of this pattern is to encrypt and decrypt data within the browser so that it can't be inspected by the hosting organization.

The next two patterns address monitoring the user's activity level. Timeout uses event-handling and scheduling to decide when the user is no longer active. Heartbeat is similar, but it brings the server into the equation; the browser keeps sending a heartbeat message to tell the server that the user is still active and that the application is still sitting in the browser.

Finally, Unique URLs restores some functionality that Ajax, to some degree, takes away. Bookmarkable URLs and browser history have always been an issue on the Web, but Ajax exacerbates the problem when developers choose not to use page refreshes. The Unique URLs pattern identifies a range of tricks to handle bookmarking, deep linking, the Back button, and related concerns.

⊙⊙ Account, Authentication, Customisation, Customization, Incremental, Login, Password, Personalisation, Personalization, Profiling, Registration, User, Verification

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Account, Authentication, Customisation, Customization, Incremental, Login, Password, Personalisation, Personalization, Profiling, Registration, User, Verification

Figure 17-1: Lazy Registration

It's Saturday afternoon, and Stuart is busy planning the evening's activities. He visits a band listings web site, where he clicks on a map to zoom into his local area. Even though he has never visited the site before, a profile, which he can see on the top of the site is already being constructed. At this stage, the profile guesses at his location based on his actions so far. As he browses some of the jazz bands, the profile starts to show an increasing preference for jazz bands, and some of the ads reflect that. Since the jazz thing is a one-time idea, he goes into his profile and tweaks some of those genre preferences but leaves the location alone since the system's guess was correct. Finally, he decides to make a booking, at which point he establishes a password for future access to the same profile including his address, which is posted back to the profile.

How can the user customize the site while deferring formal registration?

Public web sites thrive on registered users. Registered users receive personalized content, which means that the web site is able to deliver greater value per user. And registered users can also receive more focused advertising material.
For nonpublic web sites, such as extranets used by external customers, registration may be a necessity.
Most users don't like giving their personal information to a web server. They have concerns about their own privacy and the security of the information. Furthermore, the registration process is often time consuming.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Access, Account, Authentication, Login

Figure 17-7: Direct Login

When Stuart logs in to perform an online exam, he is presented with a standard username-password form. He enters his username and password, but a few seconds later, the form becomes red and shows an error message underneath. He switches off Caps Lock and re-enters his credentials. This time, they're accepted. The form morphs to show his name and balance, and a new menu appears alongside it.

How can users present their credentials to the server?

Login is a necessary evil—it should be as transparent as possible.
Casual users may not bother to log in if the process interrupts their browsing experience.
Login requires the browser to interact with the server in order to validate the username and password.
The password should not travel in plain-text; it could be intercepted while traveling to the server.

Authenticate the user with an XMLHttpRequest Call instead of with a form-based submission, hashing in the browser for improved security. The essence of this pattern is a routine transformation from a submission-based approach to an Ajaxian, Web Remoting (Chapter 6) interaction style. But, in this pattern, I also discuss a very useful, though optional, technique that involves JavaScript-based hashing and is specific to the login process.

Conventional authentication usually requires the user and password to be uploaded as a standard form submission. The server usually converts the password to a hash (or "validator") value and checks it against a stored hash value in the database. If they match, the user is in.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

○ ASP, DataCloud, Key, Secure, Untrusted

Figure 17-9: Host-Proof Hosting

Reta is dismayed to learn that a malicious hacker managed to download a chunk of the company's database containing personal details about all the customers in her store. Fortunately, she also learns that the pass-phrase she always entered was actually used to encrypt all that data, so the hacker won't be able to make sense of any of the contents.

How can you mitigate the effects of unauthorized access to your application data?

Web apps require that some form of persistent data hold information about users, business state, past events, and so on.
Security restrictions—using standard web technologies—prohibit users from storing web apps on the user's own hard drives. Even with Richer Plugins that allow it, many benefits of using a web app in the first place are lost. This means that persistent data is usually stored server side.
Cookies allow some data storage within the browser, but cookie data is also transmitted to the server where it's vulnerable.
Server-side storage is open to abuse: the administrators, along with anyone who is able to gain access to it, are able to extract sensitive information by reading the data, as well as effect malicious changes by tampering with it. The abuse can occur within an organization's own IT department or be inflicted by a third-party hosting company entrusted with the data.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙⊙ Logout, Screensaver, Session, Suspend, Timeout

Figure 17-11: Timeout

Tracy was so keen on leaving the office Friday afternoon that she forgot to shut down the market news web site. Fortunately, the web site monitors mouse movements, meaning that if she doesn't interact with the page for an hour, it will suspend itself, saving a lot of wasted refreshes. On Monday morning, Tracy walks in and sees a screensaver-like animation in the browser, with a message indicating that updates have ceased. She clicks a mouse button and sees the screen update with the latest prices.

How can you tell whether the user is still working with the application?

Users often leave an application in a browser window for hours or days without interacting with it. Many times, they abandon it altogether. The practice is becoming more prevalent as all major browsers now support multitab browsing.
Ajax Apps often use Periodic Refresh or HTTP Streaming to keep informed about server state. The user may not care about the application anymore, but if it's still in the browser, a naïeve implementation will continue to poll the server indefinitely—a massive waste of bandwidth and resources.
Ajax Apps often contain sensitive data which is at risk if the user forgets to log out when leaving a public terminal.
Ajax Apps often involve collaboration and communication between users. To cultivate an awareness of other users and their activities, the server must track the state of individual browsers.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

○ ACK, Announcement, Flash, Heartbeat, Monitor, Signal

Figure 17-14: Heartbeat

For auditing purposes, Frank must run the factory decision support system all day long, so the server needs to ensure that it's always alive in the browser. But requests won't come in very often because it's a fat client, with the business logic in JavaScript. To ensure that the server keeps getting requests, the browser explicitly uploads a Heartbeat message every 10 minutes.

How do you know the user still has an application in the browser and is actively working with it?

It's useful for the server to track whether the user is active, with several applications highlighted in the Solution of Timeout.
Due to the stateless nature of HTTP, the server doesn't know when the user has quit the browser, experienced a browser crash, or surfed away to a different URL. Note that you could use the JavaScript onunload event to catch the last of these, but it won't work for the first two. In tracking the user's activity, the server may assume the user is still active when he has in fact abandoned the application.
The user sometimes spends a long time working in the browser, but in a manner which yields no calls to the server—for example, filling out a long form or playing a game. The server has no way of knowing that the user's still around if no calls are made.

Have the browser periodically upload Heartbeat messages to indicate that the application is still loaded in the browser and the user is still active

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Address, Bookmarks, Cut-And-Paste, Distinct, Favorites, Hyperlink, Location, Link, Mail, Share, Unique, URL

Figure 17-18: Unique URLs

Sasha is exploring a recent news event by browsing a map of the area. There's a Unique URL for each location, so she's able to link to it in her blog and add it to her social bookmarking account.

How can you assign distinct URLs to different parts of your application?

Expressive URLs are vital. The ability to link from one site to another is arguably what made the Web successful. Furthermore, web surfers like to bookmark pages for later on. And these bookmarks are now a social phenomenon, with the advent of "linkblogs" and social bookmarking software like del.icio.us (http://del.icio.us).
Browsers retain URLs in their histories, and the Back button will only work if URLs vary. The Back button is a big habit for many users. It can mean "Go back to where I was a minute ago." For many users, it can also mean "Undo my last action," and that mental model must be respected even though some experts deem it to be technically incorrect.
A single address for your whole site is not enough; you need to support deep linking for links to be effective. That is, each distinct component of a web site should have its own URL.
In conventional web sites, the URL changes when the page is refreshed—e.g., when the user submits a form or follows a link. But in Ajax Apps, the page never refreshes, so the browser won't change the URL.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

IF THERE'S ONE CERTAINTY IN THE LIFE OF A DEVELOPER, IT'S BUGS. AJAX PROGRAMMING ISN'T ROCKET science, but you can still expect the odd moment of pain during development and maybe even in production. Fortunately, there are plenty of techniques, tools, and libraries available to help you isolate problems as they arise. This chapter breaks them into four categories.

Logging is just good old logging applied to the browser, where log messages can be shown in a popup, uploaded to the server, or shown in some browser-specific way. Likewise, Debugging is general-purpose debugging applied to JavaScript that is running within the browser.

The next two patterns are more Ajax-specific. DOM Inspection is about analyzing the dynamic state of the DOM. Traffic Sniffing is about watching traffic between browser and server.

⊙ Capture, Log, Message, Monitor, Record

Figure 18-1: Logging

Dave's search engine keeps giving a blank result for certain queries. Fortunately, he previously added some Logging commands to see how the query is processed, so he makes the console visible and sets log level to verbose. After entering the query again, he now sees that one of the regular expressions is not matching the query as expected.

How can you track program process?

Instrument your JavaScript with log messages. Typically, the page contains a div element especially for Logging, and each significant action is appended there, e.g.:


  $("log").innerHTML += "User searched for " + query + ".<br/>";

Even this simple implementation offers several benefits over the common alternative, debugging with an alertbox. Most importantly, the log element can be a

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Capture, Log, Message, Monitor, Record

Figure 18-1: Logging

Dave's search engine keeps giving a blank result for certain queries. Fortunately, he previously added some Logging commands to see how the query is processed, so he makes the console visible and sets log level to verbose. After entering the query again, he now sees that one of the regular expressions is not matching the query as expected.

How can you track program process?

Instrument your JavaScript with log messages. Typically, the page contains a div element especially for Logging, and each significant action is appended there, e.g.:


  $("log").innerHTML += "User searched for " + query + ".<br/>";

Even this simple implementation offers several benefits over the common alternative, debugging with an alertbox. Most importantly, the log element can be a Popup (Chapter 15): you can easily toggle visibility by dynamically switching CSS properties such as display, or even make it partly transparent. Further, Logging is unobtrusive—that is, there's no impact on application flow. Another benefit is that you have a history to consult if something goes wrong; there's no need to try replicating the problem.

Inspired by libraries such as Java's log4j (http://logging.apache.org/log4j/docs/), JavaScript Logging libraries usually provide some sort of filtering. Typically, a message is tagged with a priority level, e.g., "debug," or "info," or "error." You can then choose to only see messages above a certain level.

Logging impacts performance, not just in DOM manipulation but also in producing the messages themselves. You can end up with a memory problem as well unless some measure is taken to clear old messages, e.g., using a buffer to discard old messages.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Break, Debug, Deduce, Fix, Inspect, Repair, Step, Test

Figure 18-3: Debugging

Devi is scratching her head, wondering why a particular visual effect is so jerky; instead of growing gradually, the icon transitions from small to large in just a few, erratic, steps. Code analysis is getting her nowhere, so she fires up her JavaScript debugger, which allows her to step through the effect in her own time. After adding the box dimensions to a watchlist, she quickly diagnoses the cause as a number-rounding issue.

How can you diagnose errors and strange behavior?

Diagnose problems with a JavaScript debugger. JavaScript Debugging used to be as sophisticated as adding a few alert messages, but it has come a long way. A tool such as the Venkman debugger (http://www.mozilla.org/projects/venkman/), a popular Firefox extension, makes the point. Venkman has all the basic features you'd look for in a debugger of any language: breakpoints, call stacks, step in/out/over, watches, and error and exception triggers. Also, an interactive session lets you type code for immediate execution as well as basic profiling support.

That is the question many developers have asked over the years, with many deciding that there are often more productive things to do. The main problem with Debugging is that you have to invest time setting up breaklists and watches and thinking up strategies for diagnosis, yet all of that is thrown away after the problem's solved. The same problem might arise later on, and you'll have to set it all up again. Even if you can save breakpoints and watches—as Venkman lets you do—they are often too fragile to be useful, whereas if you can create a unit test to check the same thing, or introduce a log message to monitor state, you'll have created a permanent asset for yourself and your team.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ DOM, Dynamic, Explore, Inspect, Interrogate, Investigate, Presentation, Render, Snapshot, State, View, Visualise, Visualize

Figure 18-6: DOM Inspection

Devi keeps clicking on the Clear button, but the document text remains stubbornly unaffected. She fires up a DOM Inspection tool and discovers that the button's onclick event handler isn't present, which explains why nothing was happening.

How can you inspect the DOM's state at any time, taking into account DOM manipulations that may have occurred since the page was loaded?

Use a DOM Inspection Tool to explore the dynamic DOM state. The initial HTML for an Ajax App is often minimal and, in any event, likely to change over time due to DOM Manipulation. A DOM Inspection tool traverses the browser's current DOM model, rather than the initial HTML source, to build up a presentation of the current DOM. Many times, the tool is interactive, allowing you to drill down the hierarchy, search for keywords, and so on. All of this is very useful for checking assumptions and diagnosing problems, since many Ajax bugs arise because the programmer misunderstood the DOM state at a particular time.

Incidentally, DOM Inspection is useful beyond the fact that the DOM is dynamic. Even for static applications, an interactive exploration tool is often a good complement to the mound of text that makes up a complex HTML document.

Section 18.3.4.1: Firefox DOM Inspector

Firefox ships with a DOM Inspector tool, accessible from the tools menu (Figure 18-7). The inspector is a popup window showing the DOM hierarchy on one side and facing a summary of the selected node. The summary shows node attributes such as registered event handlers, as well as CSS style information.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Capture, Intercept, Log, Monitor, Network, Record, Sniff, Traffic

Figure 18-12: Traffic Sniffing

Dave hears a report that critical form data isn't being saved on the database. He turns a sniffer on and tries uploading the same data himself. The sniffer shows him an XML message being uploaded via XMLHttpRequest. When inspecting the message in an XML editor, he discovers that the JavaScript hasn't formatted it correctly.

How can you diagnose errors and strange behavior?

Diagnose problems by sniffing Web Remoting traffic. Many Ajax problems arise because Web Remoting (Chapter 6) messages are either wrong or are not sent at all. Debugging (see earlier in this chapter) and general Logging on either side of the network might help you infer what's being transmitted, but it's better to grab the traffic directly. There are various ways to do this:

In the browser, use XMLHttpRequest Calls (Chapter 6) in a wrapper that logs the request and response (see Logging earlier in this chapter). This may be the most convenient technique, because the programmer is probably already looking at the browser. The downside is that you'll miss out on non-Web Remoting (Chapter 6) traffic, e.g., full page refreshes.
Employ a generic network traffic monitor, filtering HTTP traffic to and from the server.
Configure your browser to use a generic HTTP proxy and have the proxy log interesting traffic in either direction.
In the server, intercept incoming and outgoing traffic for

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THANKS TO THE AGILE MOVEMENT, TESTING IS NO LONGER SEEN AS THE BIT AT THE END WHERE QA gives its stamp of approval. It's a core development technique, and if you're creating complex web apps, it's worth testing within and across all tiers.

Because of remoting, Ajax browser scripts usually rely on web services. But it's not much fun working on both sides at the same time, so Simulation Service explains how to create a "dummy" or "stub" web service to call from the browser. You can use it for tests or for prototyping. Browser-Side Test is simply a test of the JavaScript code sitting in the browser. The hardest thing is to exercise it in an automated fashion; the pattern also looks at that issue. Service Test involves no JavaScript, because it actually takes the place of the browser; an HTTP client is used to test the web service. System Test effectively simulates a user to exercise the application across all layers.

○ Canned, Double, Dummy, Fake, Masquerade, Mock, Service, Shunt, Sim, Simulation, Stub

Figure 19-1: Simulation Service

Dave is beginning to work on a new email application. Eventually, the server will need to expose a mail API, so the browser can query for recent messages and upload new ones. However, that will require email expertise, and Dave wants to focus on the user interface in the browser for now. Thus, he hardcodes the responses he'd like in a "fake" server-side service. This allows him to proceed with user-interface development while his colleague takes care of the real server implementation.

How can you develop the browser script in parallel with the services it uses?

Develop the browser application against "fake" web services that simulate the actual services used in production

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

○ Canned, Double, Dummy, Fake, Masquerade, Mock, Service, Shunt, Sim, Simulation, Stub

Figure 19-1: Simulation Service

Dave is beginning to work on a new email application. Eventually, the server will need to expose a mail API, so the browser can query for recent messages and upload new ones. However, that will require email expertise, and Dave wants to focus on the user interface in the browser for now. Thus, he hardcodes the responses he'd like in a "fake" server-side service. This allows him to proceed with user-interface development while his colleague takes care of the real server implementation.

How can you develop the browser script in parallel with the services it uses?

Develop the browser application against "fake" web services that simulate the actual services used in production. A Simulation Service is typically a hardcoded response that ignores any input parameters. So instead of:


  $taxRate = calculateTaxRate($userId, $year);

  print $taxRate;

a Simulation Service would just say:


  print "0.1235";

It's also possible to do all this in a browser. If you use a library to perform Web Remoting (Chapter 6), you could make the implementation produce a hardcoded response, and ignore the server altogether.

In some cases, you might make the service more flexible; e.g., it can expose an operation to let the browser tell it what to output later on.

Simulation Service decouples the server and browser components of the application. Once the interface is defined, each can be developed in parallel. Moreover, this pattern paves the way for an agile process for building the application, based loosely on concepts such as Test-Driven Design (TDD) and lean manufacturing.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Automated, IntegrationTest, JavaScript, Regression, UnitTest, TDD, Test

Figure 19-2: Browser-Side Test

Devi is about to embark on upgrading a blog reader and realizes she will be tinkering with the JavaScript RSS parser. The parser will need some refactoring, but fortunately there's already a JavaScript unit test for it. She proceeds to refactor the parser, ensuring the test still passes, and continues to enhance the test as she builds in further functionality.

How can you test JavaScript components?

Create automated tests of browser-side JavaScript components. This pattern is a mapping from automated testing in other languages, where frameworks like the xUnit series (http://en.wikipedia.org/wiki/XUnit—e.g., JUnit; see http://junit.org—are now popular. Several frameworks do the same for JavaScript. As with other languages, you can unit test an individual JavaScript component (e.g., a function) you've created, and also perform integration tests and system tests that work across several objects. And also like other languages, you can accumulate tests into a test suite object, so it's possible to run a full regression test.

This pattern is heavily influenced by the "xUnit" testing frameworks (http://en.wikipedia.org/wiki/XUnit), which includes frameworks like JUnit for Java, PHPUnit for PHP, and NUnit for .Net. If you haven't used any of these before, it's worth learning the basic principles involved in xUnit-style testing, as these apply universally to all xUnit frameworks including the JavaScript ones. Kent Beck's Test-Driven Development By Example (Addison Wesley) is an excellent overview.

The test is usually some JavaScript that performs some task and includes assertion to check the state is as expected. Usually, JavaScript frameworks include a Test Runner that will run a given set of tests, then morph the DOM to show results in a table. You usually build an HTML page, with test code embedded, and perhaps some inputs to control the test; e.g., Start and Stop buttons.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Automated, JavaScript, Remoting, UnitTest, TDD, Test, WebService, XMLHttpRequest

Figure 19-4: Service Test

Dave is creating a trading application. On the server, there are services to give quotes and accept orders. To help develop and test the web service, he builds a suite of Service Tests. One test, for example, submits an order and checks that the database registered it. These tests are automated and re-executed every time the project changes.

How can you test web services?

Build up automated tests of web services, using HTTP clients to interact with the server as the browser normally would. The browser-server interaction of an Ajax App is usually a sequence of XMLHttpRequest Calls (Chapter 6). That's fortunate, because testing the service is usually as easy as simulating the browser—passing a certain request and checking the response. Sometimes, verification might also involve checking what happened on the server, e.g., a database state change or a message to an external system.

The test itself can be built in any language and testing framework you like, because it's completely decoupled from both the browser and the server. The only practical constraint is that you should be able to run it from a script, to allow for continuous integration. Many languages provide an HTTP client library, so it's easy to build a test pass request to the server and make assertions against the response. Indeed, there are client frameworks like HTTPUnit (http://httpunit.sourceforge.net/) that are specifically for the purposes of testing web apps. They're typically used for testing conventional applications, where the response contains an entire page, but they work fine for the terse responses usually provided by web services.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

⊙ Automated, FunctionalTest, JavaScript, PerformanceTest, Regression, Robot, UnitTest, TDD, Test

Figure 19-5: System Test

Devi has completed the first cut of a new Ajax App and wants to build an automated test of the whole thing. With the help of a testing application, she records a typical usage so it can be played back later. The software takes note of the final state, which will be used for verification during automated playback.

How can you test an entire Ajax App?

Build automated tests to simulate user behavior and verify the results. A System Test exercises a complete system in much the same way as a user would. The most common category of system test is a functional test—verifying the functionality—but system testing also encompass qualities such as performance and robustness. While they are often conducted manually, with users clicking and mousing around, it's highly preferable to automate as much as possible in order to promote continuous integration.

Automated system tests remain somewhat difficult, but tools are improving. They can be broadly categorized as follows:

Browser Controller (Figure 19-6): A specialized, "robot"-style testing tool will fire up the browser, then use the underlying operating system's API to create the effect of a user interacting with the browser. Several commercial controllers are able to record user actions for later playback.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

An explosion of libraries and frameworks has been one of the fortunate consequences of the Ajax phenomenon. They come in all shapes and sizes and in any licensing model you'd care to name. Throughout the Ajax Patterns, the importance of using frameworks and libraries has been emphasized—it's worth knowing the low-level details, but often not worth implementing them yourself. For this reason, the listing here makes a good companion to the Ajax Patterns.

The initial list was published back in June 2005, when I documented what seemed like an overwhelming 20 products. Maintained in an openly editable wiki, it's blossomed to 160-odd products, and doubtless many still to come—stay tuned to http://ajaxpatterns.org/Ajax_Frameworks for the latest updates.

Some of these were around long before Ajax was "Ajax," but all are here because they support Ajax development. This section is a lightly edited snapshot of the wiki in January 2006—many of the descriptions come straight from project owners and users. It begins with two sections on pure JavaScript frameworks, where you have to provide your own server-side integration. Following that are frameworks for a large number of server-side environments, many including some JavaScript library API as well as a server-side API. Note that there's a multilanguage section, since some frameworks address multiple server-side environments. Therefore, consult the multilanguage section in addition to the section for any particular server-side environment you're interested in.

People getting into Ajax often ask me for a "quick-fix" framework to help get started. So at risk of offending many worthy projects, each section points out a few of the frameworks that have generated buzz. This is, of course, a subjective measure, and it is one of popularity more than intrinsic value; do investigate further for any serious development work. In addition, look at the patterns, many of which discuss specific frameworks.

Section A.1: JavaScript Multipurpose Frameworks

Section A.2: JavaScript Remoting Frameworks

Section A.3: JavaScript Effects Frameworks

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

These are pure-JavaScript libraries used to achieve a range of functionality in the browser—usually in a manner that protects you from dealing with browser compatibility issues, as described in Cross-Browser Component (Chapter 12). The Prototype framework has been very popular for general JavaScript infrastructure, and many frameworks mentioned here build on it. At a higher level, Dojo and Scriptaculous are probably the two best known products here and are good options if you're looking for a multipurpose library. Along those lines, Mochikit and OpenRico have also been popular as well. In the commercial space, there's been a lot of interest in Backbase and Tibco General Interface, though the products here are so varied, it really depends where you look.

AjaxFace (http://www.vertexlogic.com) is an Ajax, JavaScript UI framework.

High-level JavaScript API for building UI
Open architecture for updating and retrieving data from the backend
Automatic synchronization of data and UI
Easy extensibility
High performance
Easy customization of look-and-feel through well-defined stylesheets
Online demo (http://www.vertexlogic.com/demo.html)
Commercial license by VertexLogic

Backbase (http://www.backbase.com) is a comprehensive browser-side Ajax framework with cross-browser support. The Backbase Ajax framework is compatible with any server-side platform (e.g., Java, .NET, PHP, or Coldfusion).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As many of the Ajax Patterns establish, Web Remoting (Chapter 6) is error-prone, tedious, and broad in functionality, which makes it ideal to encapsulate in a library or framework like those covered here. The multipurpose frameworks covered earlier will do it too, but if you're looking for a standalone simple option, SACK is a popular choice. HTMLHttpRequest is a good option for compatibility as it supports IFrames as well as XMLHttpRequest. A more feature-rich API is offered by Ajax Client Engine (ACE).

AjaxCaller (http://ajaxify.com/run/Lib/js/ajaxCaller.js) is a basic, threadsafe wrapper around XMLHttpRequest that is mainly for Ajax newcomers packaged with the Ajax Patterns demos. See TestAjaxCaller (http://ajaxify.com/run/testAjaxCaller).

RESTful calls to the server (GET/POST/PUT/DELETE) with plain-text or XML routed to a callback operation
Aimed at Ajax newcomers—instead of optimizing performance or footprint, the library aims to be a readable code base and provides debugging support
Open source license (Creative Commons) by Michael Mahemoff (http://softwareas.com), with some ideas from John Wehr and Richard Schwartz

Ajax Client Engine (http://www.lishen.name) is a powerful remoting wrapper.

Object-oriented API
Cross-browser support
Flexible features: request options; request parameter validation; callback argument; callback option; callback timeout; tracing service; caching service; polling service; common callbacks; and exception handling

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

FAT (http://www.axentric.com/posts/default/7) handles the Yellow Fade Technique (see One-Second Spotlight [Chapter 16]).

Open source license (stated as Creative Commons in the page comments) by Adam Michela

Moo.fx (http://moofx.mad4milk.net) builds on a lite version of the Prototype library to provide an extremely compact effects package.

Visual effects
Cookie memory for effects
36 KB total file size
Open source license (MIT) from Volerio Proietti

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Richer Plugin pattern points out how Flash can benefit Ajax development; these frameworks support Ajax-Flash crossovers.

AMFPHP (http://amfphp.sourceforge.net/) is an open source implementation of the Flash Remoting framework.

Fast, reliable, 100 percent free, and open source. With this new version, we strived to make a product as stable and full-featured as ColdFusion-based remoting (the reference implementation). You also get to use the wonderful NetConnection debugger, which shows you exactly what's being sent between the client and server. Remoting uses AMF, a very lightweight binary format that cuts the bulk out of packets, meaning data exchange is a lot faster than with XML.
Open source license (GPL) created by Wolfgang Hamann and maintained by various developers.

The Flash JavaScript Integration Kit (http://www.osflash.org/doku.php?id=flashjs) allows for the integration of JavaScript and Flash content.

Enables JavaScript to invoke ActionScript functions, and vice versa.
All major data types can be passed between the two environments.
Open source license (modified Apache 1.1) by multiple open source Flash contributors.

Stream (http://www.stormtide.ca/Stream) is a bi-directional Ajax platform that brings Flash XML socket support to JavaScript. Also includes an extensible open source stateful socket server and client management platform.

Plugin API (C# and JavaScript client libraries).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

These libraries support patterns such as XML Message, Browser-Side XSLT, and XML Data Island.

Google AJAXSLT (http://goog-ajaxslt.sourceforge.net/) is a JavaScript framework for performing XSLT transformations, as well as XPath queries.

Builds on Google Map work
Open source license (BSD) by Google

Sarissa (http://sarissa.sf.net) is a JavaScript API that encapsulates XML functionality in browser-independent calls.

Portable XMLHttpRequest creation
Portable XPath queries
Portable DOM manipulation
Portable XSLT
Portable serialization to XML
Open source license (GPL 2.0 or LGPL 2.1, your choice) by various contributors

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

These are a couple of useful libraries that don't fit well in other sections.

Walter Zorn's Drag-Drop library (http://www.walterzorn.com/dragdrop/dragdrop_e.htm) is a well-featured drag-and-drop library (see also Drag-And-Drop [Chapter 15]).

Open source license (LGPL 2.1 or later) by Walter Zorn

GSV (http://mike.teczno.com/giant/pan/) lets you place a massive image on the server and allow the user scroll around as if it was all stored locally (like scrolling around Google Maps; see Virtual Workspace [Chapter 15]).

Open source license (custom) by Michael Migurski

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Each library here integrates browser-side JavaScript with several server-side languages. Usually, an individual project will only need to integrate with one server-side language, but the library includes several to make it applicable to a broader market. JSON has had a big impact, because it is as much a popular data format as it is a collection of open source libraries for remoting. SAJAX has also received considerable attention in this area, in part because it supports so many languages. CPAINT is popular as well.

CPAINT (http://cpaint.sourceforge.net/) is a true Ajax implementation and a JSRS (JavaScript Remote Scripting) implementation that supports both PHP and ASP/VBScript. CPAINT provides you the code required to implement Ajax and JSRS on the backend, while the returned data is manipulated, formatted, and displayed on the frontend in JavaScript. This allows you to build web applications that can provide near real-time feedback to the user. See Ajax Stub (Chapter 9).

Supports both PHP and ASP
Unified JavaScript file for all functions
Supports both remote scripting and XML
Supports both local and remote functions
Single or multiple XMLHTTP objects
Returns backend data as text or as a JavaScript XML/DOM document object
Can support both POST and GET requests
Backend proxy functions for accessing remote functions and data

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Wt (http://witty.sourceforge.net/) is a C++ widget library, which uses Ajax to render changes to the widget tree when available.

API inspired by existing GUI libraries. It targets C++ application developers.
The widget library makes complete abstraction of the underlying technology (JavaScript, HTML, Forms, CGI, Ajax).
Documentation is at http://jose.med.kuleuven.ac.be/wt/doc/index.html.
Open source license (Affero General Public License) by Koen Deforche.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

AjaxCFC (http://www.robgonda.com/blog/projects/ajaxcfc/) is a ColdFusion framework meant to speed up Ajax application development and deployment by providing developers seamless integration between JavaScript and ColdFusion. It also provides built-in functions that quickly adapt to any type of environment, security, and help overcoming cross-browser compatibility problems. It contains:

ColdFusion components following the best practices of object-oriented programming and design patterns. Programming with AjaxCFC involves extending components and creating your own Ajax facades.
Restricted open source license (free to use in any context but not redistributable) by Rob Gonda.

JSMX (http://www.coldfusion-ajax.com) is a very simple Ajax implementation for ColdFusion developers (or for any language that can easily build JavaScript Strings). This API does not return XML but String representations of JavaScript expressions.

Smaller packet sizes over the wire (JavaScript versus XML).
Reduced latency due to less parsing of the responses.
Parameters can be sent to the server in multiple formats including strings, objects, and entire forms without having to build extra logic to handle each type.
API has no server-side components, which makes it more portable (planned).

Extremely simple syntax shortens the learning curve and speeds up development:


params = document.myForm;

http( "POST" , "remote.cfc?method=dosomething", my_callback, params );

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In the .NET world, all eyes are on Microsoft with their in-progress Atlas framework. It's not yet clear exactly what it covers, how portable it will be, and how it will affect the existing frameworks here. In any event, Michael Schwartz's Ajax.NET is one popular choice, and for a broader-scoped framework, the Monorail project—similar to Ruby on Rails—has a lot of interest too.

Ajax.NET (http://ajax.schwarz-interactive.de/csharpsample/default.aspx) is an Ajax framework for ASP.NET 1.x/2.0.

A basic Ajax library for ASP.NET that provides the very basic Ajax capability to make XMLHTTP callbacks. Does not have any Ajax-enabled controls or support for Viewstate, etc.
Open source license by Michael Schwartz.

Anthem.NET (http://anthem-dot-net.sourceforge.net/) is Jason Diamonds' new version of a long-established Ajax library, now a SourceForge open source project.

Athem.NET provides a set of Ajax-enabled controls inherited from ASP.NET server controls, with most Ajax behaviors pre-built, avoiding lots of client JavaScript. It supports Viewstate so that you can actually modify server controls (either Anthem controls or ASP.NET controls inside an Anthem control—e.g., panel) in your server-side code, in C# or VB without having to mess about in JavaScript. Still in its early days (DEC 2005) but promising!
Open source license by Jason Diamonds.

AjaxAspects (http://www.mathertel.de/AJAXEngine/) is an engine that uses JavaScript proxies to call server-side web service methods.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Java has always had many wide and varied frameworks. With Ajax, we've seen new ones emerge, and we've also seen add-ons for the earlier projects. Two popular libraries have been the Ajax JSP Tag Library and Direct Web Remoting.

AjaxAnywhere (http://ajaxanywhere.sourceforge.net) returns any set of existing JSP, JSF, Struts, Spring, etc., components into Ajax-aware components without JavaScript coding. (see the Quick Start Demo at http://ajaxanywhere.sourceforge.net/quickStart.html).

Does not break existing server-side MVC architecture.
Less JavaScript to develop and maintain. Absence of commonly accepted naming conventions, formatting rules, and patterns makes JavaScript code messier then Java/JSP. It is extremely difficult to debug and unit-test in multibrowser environments. AjaxAnywhere eliminates all these complexities.
Easy to integrate. AjaxAnywhere does not require changing the underlying application code.
Graceful degradation. Switch whenever you need to between Ajax and the traditional (refresh-all-page) behavior of your web application. Your application can also support both behaviors.
Open source license (Apache 2).

The AJAX JSP Tag Library (http://ajaxtags.sourceforge.net/) is a set of JSP tags that simplify the use of Asynchronous JavaScript and XML (Ajax) technology in JavaServer Pages. This library eases development by not forcing J2EE developers to write the necessary JavaScript to implement an Ajax-capable web form. The tags are:

Autocomplete

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

CL-Ajax (http://cliki.net/cl-ajax) directs JavaScript calls directly into server-side Lisp functions.

The export function script is as follows:
```
(export-function #'my-function)
```
Generates a JavaScript stub with arguments.
Can callback to a JavaScript function or DOM object.
May be integrated into SAJAX.
Open source license (custom, very flexible, license) by Richard Newman (http://www.holygoat.co.uk/).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

CGI::Ajax (http://pjax.sourceforge.net/) is a Perl module to make it trivial to write Ajax scripts using Perl. The module is object-based Perl, and creating a link from a JavaScript event to your Perl code is as easy as defining the JavaScript function name to Perl subroutine name mapping.

Can be used to link any Perl code to an HTML event, including fetching other URLs (using LWP, for example)
Nestable, so an HTML event can start a chain of Ajax events (e.g., onClick= "do_this( ); now_that(); finally_this( )")
Can handle GET or POST
Not necessary to have your exported subroutines named in a specific way—name them what you want
Very small overhead—allows you to keep thinking Perl and not get bogged down
Active development community
Open source library (Perl and Artistic license) by Brian Thomas

HTML::Prototype (http://search.cpan.org/dist/HTML-Prototype/) contains some code generators for Prototype, the famous JavaScript object-oriented library, and the script.aculous extensions.

Basically similar to the Prototype helpers in Ruby on Rails
Open source license (GPL and Artistic) by multiple contributors

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

PHP frameworks tend to focus more on remoting than HTML generation. XOAD is one popular remoting library, as well as CPAINT and SAJAX (covered earlier in "JavaScript Multipurpose Frameworks").

AJASON (http://ajason.sourceforge.net/) is a PHP-based framework.

Uses JSON (JavaScript Object Notation) to encode/decode data between server and browser
Open source license by multiple contributors

AjaxAC (http://ajax.zervaas.com.au/) encapsulates the entire application in a single PHP class.

All application code is self-contained in a single class (plus any additional JavaScript libraries).
Calling a PHP file or HTML page is very clean. All that is required is creating the application class, and then referencing the application JavaScript and attaching any required HTML elements to the application.
Built-in functionality for easily handling JavaScript events.
Built-in functionality for creating subrequests and handling them.
Allows for custom configuration values, so certain elements can be set at runtime.
No messy JavaScript code clogging up the calling HTML code—all events are dynamically attached.
Easy to integrate with templating engine.
Easy to hook in to existing PHP classes or MySQL databases for returning data from subrequests.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

CrackAJAX is a Python framework (http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework) that does not require JavaScript skills.

Open source license by Peter Hunt

Turbo Gears (http://turbogears.org) is a "mega-framework" combining many libraries and frameworks.

Open source licence (MIT license) and multiple licenses from incorporated frameworks by multiple developers

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Ruby On Rails (http://www.rubyonrails.org/) is a general web framework with strong Ajax support.

Rails was still in its early days when Ajax hype began, so Ajax may become increasingly important to the Rails framework.
Generates most or all of the JavaScript for widgets and animation in the browser.
Supports calling server side.
Provides scheduling support.
Open source license [MIT or similar (http://wiki.rubyonrails.com/rails/show/License) by David Heinemeier Hansson and contributors (http://www.loudthinking.com/).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A SINGLE PACKAGE CONTAINING ALL CODE FOR CHAPTER 2 AND THE AJAX PATTERNS DEMOS AS WELL IS at http://ajaxify.com/run. Inside there is a INSTALL.txt file containing installation instructions. These instructions are reprinted below, but if you have any trouble, please do check the electronic version as it may include updates.


INSTALLING PHP

==============



* If you don't have it already, install PHP5 and integrate with Apache (or

  another web server). The demos rely on the PHP5 OO features, and won't work

  with PHP4 or below.



  There are various installers available that will create an "AMP" (Apache,

  PHP, and MySQL) setup for you (You'll need MySQL for the wiki demo - see

  below). e.g. XAMPP for all major platforms

  (http://www.apachefriends.org/en/xampp.html).  For Apple, consider

  http://www.entropy.ch/software/macosx/php/. For Linux, you may try the

  appropriate Redhat/Debian packages. Alternatively, try the compilation

  instructions at http://dan.drydog.com/apache2php.html.



SETTING UP AJAX DEMOS

=====================



* Unzip the package to a temporary location and copy run/, tutorial/, and

  records/ to the apache document root. Assuming the doc root is

  /apache/document/root:



    cp run tutorial records /apache/document/root.



  (Alternatively, if you have sufficient access, set up a new virtual host in

  apache's httpd.conf and point it to the root of the unzipped directory,

  ajaxdemos/).



* Ensure the server can write to (the initially empty) records/ directory. The

  easiest (though not the most secure) way is:



    chmod 777 apache/document/root/records



* Open up run/.htaccess and follow instructions there to set the library path.



* Finished! Visit http://localhost/run/ and http://localhost/tutorial. If you

  can access http://localhost/run/index.phtml but not http://localhost/run/,

  read the following note.



NOTE ON CONFIGURATION: You hopefully won't need any configuration because

run/.htaccess and tutorial/.htaccess contain the relevant settings. But some

apache installations will ignore those settings (depending on the AllowOverride

directive), so be ready to transfer some of the contents of run/.htaccess into

httpd.conf.  (run/.htaccess is a superset of tutorial/.htaccess.) Specifically,

modify the existing DirectoryIndex directive to include index.phtml, and add a

new type for phtml as in .htaccess. If the PHP include_path isn't working,

you'll probably need to modify it in php.ini according to the setting in

.htaccess.



SETTING UP THE WIKI DATABASE

============================



NOTE: The wiki demo and its refactorings are the only demos that require a

database. The setup isn't particularly difficult, but if you don't want to mess

with MySQL, you can still run all the other demos.



* Install MySQL if necessary

* Prepare for database access.

  * Enter mysql as power user, e.g.:

          mysql -u root

  * Create "ajaxify_wiki" power user with password "ajaxify_wiki", e.g.:

      GRANT ALL PRIVILEGES ON *.* TO 'ajaxify_wiki'@''localhost'

          IDENTIFIED BY 'ajaxify_wiki';

  * If you'd prefer to use an existing account instead, set the details in

    Model/DAO.php for any wiki demo you wish to run.

* Run run/wiki/Model/freshDB.sh. You only need to do this once, as the tables

  can be shared by all versions of the wiki. NOTE: Ensure your command-line

  path is set up so that "php" will resolve to php5.

* Point your browser at the wiki, e.g. http://localhost/run/wiki/, and you

  should see three fresh messages.



TROUBLESHOOTING

===============

If you run into any problems:

* Check the section below, as some demos require some extra setup.

* Try the tutorial demo first. It's less error-prone because there's no library

  path involved.

* Verify file permissions are correct. The easiest way is to run "chmod 755

  document/root". In addition, ensure the records/ directory is writable.

* For the wiki, manually check the database is ready and can be accessed with

  the settings in DAO.php.

* Verify your PHP setup - create a file with "<? php_info ?>" and see if you

  can access it from the browser.

* Ensure you're using PHP 5 (or later).

* Check that you can run a test file, with both .php and .phtml suffixes.

* Check that index.phtml is recognised as a valid directory index. (Check this

  by visiting path/index.phtml instead of just path/.)

* Check that you set the library in .htaccess.

* Check remoting is working as expected with a traffic sniffing tool. (See

  those listed in the Traffic Sniffing pattern).

* Inspect log files. Your PHP log might be different to your Apache error log,

  depending on your setup.

* If problems persist, mail michael@mahemoff.com.



DEMOS REQUIRING EXTRA SETUP

===========================



These demos won't work unless you do some extra setup.



* As mentioned earlier, all the wiki demos (/wiki/..) (but nothing else) require a

MySQL database.

* For all portal (/portal/..) and reader (/reader/..) demos, you need net

  access. For the portal synclinks demo (/run/portal/drilldown/syncLinks/), you

  also need to run prepareDrilldown.php first.

* For the shop demo, if you want to run the whole lazy registration process,

  you'll need some form

* For the progress indicator in the Ajaxagram tutorial

  (/tutorial/ajaxagram/..), you either need to run it with net access, or

  change the image source in index.html to point to "/resources/progress.gif".

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

ONE SIDE BENEFIT OF THIS PROJECT HAS BEEN TO SEE HOW "PATTERNS" ARE BEING ACCEPTED BY THE development community. Since the Ajax Patterns began to be published, the focus has always been on the "Ajax" and not the "Patterns." For patterns, this is a good thing, and a welcome change from the late '90s, when you not only had to explain the concept but also justify its existence. "Ajax" itself is a pattern—one whose popularity is further evidence for the power of "just a name." For all these reasons, this discussion of patterns and their relationship to Ajax Patterns is kept brief.

Patterns came about in the late 1970s, after Christopher Alexander and colleagues spent years studying the towns and buildings of many diverse cultures. The findings were summarized as 253 distinct patterns, derived from a global pattern describing the division of nations to town-planning patterns such as "Market of Many Shops," all the way down to building patterns like "Soft Tile and Brick." Each pattern is a "thing" you often see in good designs, combined with instructions on making the thing.

Patterns have mostly been confined to academia in their original field, but they have really taken off in software design. Their rise over the past decade has been a great boon to the industry, allowing us to learn about design from real examples and not just vague comments about cohesion, coupling, and encapsulation. The pool of real examples to draw upon has itself risen exponentially, thanks to the Web and the open source movement.

The best-known patterns are software design patterns like Gamma et al.'s Design Patterns (1995). But that's not the only domain of software patterns, which have been applied to development processes, deployment practices, and—most important here—usability. Just as the original architecture patterns were fundamentally about improving the experience of inhabitants, usability patterns focus on the people who use—rather than develop—software systems. They have been especially popular for web design (e.g., The Design of Sites (Duyne et al., 2003), A Pattern Language for Web Usability

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

THESE ARE REFERENCES CITED THROUGHOUT THE TEXT.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996). Pattern-Oriented Software Architecture. John Wiley & Sons. See http://c2.com/cgi/wiki?PatternOrientedSoftwareArchitectureOne.
Cooper, A. (1999). The Inmates are Running the Asylum. Sams. See http://www.uidesign.net/1999/books/oct_books1.html.
Duyne, D.K., Landay, J.A., Hong, J.I. (2002). The Design of Sites. Addison-Wesley Professional. See http://www.designofsites.com/.
Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1995). Design Patterns. Addison-Wesley Professional. See http://c2.com/cgi/wiki?DesignPatternsBook.
Graham, I. (2003). A Pattern Language for Web Usability. Pearson Education. See http://www.wupatterns.com/.
Norman, D. (2003). Emotional Design: Why We Love (Or Hate) Everyday Things. Basic Books. See http://www.jnd.org/dn.mss/emotional_desig.html.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsverzeichnis

Section 2.1.2.1: Hello World!

Section 18.3.4.1: Firefox DOM Inspector

Themen

Buchreihen

Special Interest

International Sites