Section VII.2. Application Design Considerations


VII.2. Application Design Considerations

Before diving into how to use the XMLHttpRequest object, it will be helpful to understand some of the challenges that you will likely face along the way when deploying an application that uses the technology. All too often in the DHTML world, high-flying ideas are quickly brought down to Earth when harsh realities of non-technical users' expectations get in the way. The earlier you can start planning for these challenges, the greater your chance at defining the right specifications for your application.

VII.2.1. Ajax and the Server

In truth, Ajax technologies extend beyond just the browser XMLHttpRequest object. A robust application that takes advantage of the browser technology will also likely have a major server programming component to assist. The server will be doing jobs such as database retrieval, assembly of XML or JSON output for the client, and retrieving data from third-party sources to effect "mash-ups" of two or more external applications blended into your super-duper application. Application blending is often cited as one part of a tech trend that has (for better or worse) been labeled "Web 2.0."

The primary need for the server preprocessing is to bypass browser and scripting security restrictions that you have likely encountered while pursuing other application dreams. Specifically, the XMLHttpRequest object in the browser is subject to the identical same-origin security restrictions that affect scripting tactics such as cross-frame or cross-window communication. In the case of XMLHttpRequest, your scripts cannot access the data returned from the server unless it originates from the same domain from which the current web page arrived (even getting the technology to work across different servers of the same domain will lead to gut-wrenching workarounds). Your dream of client-side mash-ups just went out the window.

Another factor to consider is that if you intend to (or must) provide the same data to all visitors, including those who do not visit with a JavaScript-enabled browser, your server should be programmed to supply updates the old-fashioned waythrough full-page refreshes. That combination of server- and client-side functionality is in the best spirit of DHTML, whereby those who visit with modern browsers benefit from the nifty technology (e.g., faster response), but every visitor has a chance to use the data. Since we're talking about DHTML in browsers, this Online Section addresses stricty the client-side deployment for script-enabled browsers.

VII.2.2. Browser History and the Back Button

With the long heritage of web pages making individual requests for entire pages at every click of a link or button, users are quick to aim for the browser's Back button to return to the previous view of the page or site they're visiting. But now think for a minute what happens when a click of a link or button doesn't refresh the entire page, but simply fetches a few tidbits of data to update a portion of the current page. Unfortunately for the user, requests and postings made through the XMLHttpRequest object are not automatically logged anywhere, nor does the transaction register with the browser's history. A click of the Back button zooms the user back to a completely different pageperhaps a different web site altogether.

One possible workaround for this issue is to modify the location.hash property with each request so that its value contains information your scripts can use to recreate the current state of your DHTML page. Each change to the property is not only reflected in the browser's Address field, but the history also receives an entry. Unfortunately, Safari shows the spinning "loading" animation after you assign a value to the location.hash property, even though the page has completed loading.

VII.2.3. URLs and Bookmarks

An issue related to the browser history problem is what happens when a user wants to add the current page and data as a browser bookmark (or, in IE's terminology, "favorite"). If a user has been doing a bunch of Ajax operations to reach a particular state of the data, how can that state be bookmarked?

Normally, a bookmark request grabs only the current URL of the page, which would be the initial state of the page prior to any user interaction. Google Maps faced this problem because a user could have navigated through dozens or hundreds of twists and turns around a map to reach a particular destination. To solve the problem (partially, anyway), the page provides a dynamically updated link that is hard-coded with enough information for the server to open the current page with the current map stateanother reason to have the same capabilities duplicated on the server. A user, however, must know to right-click on the link to reach the contextual menu choice that bookmarks the clicked link.




Dynamic HTML. The Definitive Reference
Dynamic HTML: The Definitive Reference
ISBN: 0596527403
EAN: 2147483647
Year: 2004
Pages: 120
Authors: Danny Goodman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net