Section 9.4. HTML Message | Ajax Design Patterns

9.4. HTML Message

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

Figure 9-4. HTML Message

9.4.1. Developer Story

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.

9.4.2. Problem

What format should be used for server responses?

9.4.3. Forces

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.

9.4.4. Solution

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 "<strong>You Win!</strong>". That's not an XHTML document because there's no <xml> tag, nor are there HTML header and body sections.

HTML Messages should be used with caution because they couple server-side services with browser display. That means it's difficult to develop the tiers in parallel. In maintenance, if you change the display by altering its initial HTML or any JavaScript manipulation, you often need to change the HTML-generating service too. There's also a risk on the server side that you might be coupling business logic with HTML generation. So when might an HTML Message be appropriate?

Performance: Since browser-side parsing and rendering can be expensive, HTML Messages can make an application more responsive, especially if the HTML is cached on the server or the browser.
Server-Side Code Generation: One case where HTML Messages make some sense is with Server-Side Code Generation (Chapter 12), where the server builds all the browser-side code for you. There are strengths and weaknesses of such frameworks, and if you decide to use one, then browser-server coupling is not really an issue because all maintained code is server side anyway.
Legacy Code: Most legacy applications will use the conventional approach of publishing pages from the server. They therefore already have all the HTML generation present in the server-side environment, so if you're Ajaxifying a legacy application, a quick migration path is to retain the server-side HTML generation where possible.
Complex HTML: In the rare case that your HTML or JavaScript is particularly complex, you might prefer to generate it all on the server side, where development and debugging is sometimes easier.
Graceful Degradation: When there's a chance users won't have a recent browsers, HTML Messages allow you to encapsulate more logic in the server. Of course, if JavaScript is not enabled at all, the "messages" will have to be full pages.
Server-Centric Attitude: If you're concerned about keeping as much logic as possible in the one language and environment, or you'd prefer not to work much with JavaScript, HTML Messages are more appropriate.

Typically, HTML Messages rely on a block-level element existing in the DOM, often a div or form. The HTML Message will contain a specification for the entire contents of the element. Some of the XMLHttpRequest wrapper libraries, such as JAH/AHAH (http://microformats.org/wiki/rest/ahah) and Sack (http://twilightuniverse.com/2005/05/sack-of-ajax/), support HTML Messages by letting the caller directly state a DOM element as the callback destination instead of the usual callback function. When the response returns, the DOM element is automatically morphed with the service's response.

A variant of this pattern is Behavior Message; see On-Demand JavaScript (Chapter 6). Also, note that HTML Messages almost flow from server to browser; you'd rarely need to upload an HTML Message back to the server.

9.4.5. Decisions

9.4.5.1. At what level of granularity will the HTML apply?

In the extreme, the service could generate HTML for the entire document, making it similar to a conventional page refresh. In practice, you'll usually want to limit the HTML's level of granularity to well-defined, distinct page elements. For example:

An account status
A form
A menu

9.4.5.2. How much style will be contained in the message?

You'll need to decide how much style is contained in the message. An HTML Message already ties the server to the browser somewhat, but style directives will tie it further to the server. In general, it's good practice to just include class names and element IDs so that the browser application can influence the style, usually with a standard CSS stylesheet. If you do this, you'll need to ensure the names are unique, and you'll need to decide on exactly which elements need to be given ID and class declarations.

9.4.6. Real-World Examples

9.4.6.1. Digg Spy

Digg Spy (http://digg.com/spy) shows new stories and events such as user moderation as they happen (see Figure 5-5). The XMLHttpRequest Call (Chapter 6) accesses a static URL (http://digg.com/last10) containing the last 10 submissions and integrates them into the page. The HTML looks like this:

   <div  >     <h3 >       <a href="http://digg.com/movies/How_LEGOs_Are_Made_"> How LEGOs Are Made! </a>     </h3>     <p >       <a href="/users/Akshun"><img src="/books/2/755/1/html/2//img/user-small/user-default.png" alt= "Akshun" height="16" width="16"> </a>     submitted by <a href="/users/Akshun"> Akshun </a> 14 hours 22 minutes ago       (<a href="http://www.popandco.com/archive/moab/"  title= "How LEGOs Are Made!"> ... </a>) </p>   <p> </p>   </div>   <div  >   ...

9.4.6.2. Rapha

Rapha (http://www.rapha.cc) is an e-commerce web site for cycling gear (Figure 9-5). The shopping cart is Ajaxian, requiring no page refresh to update. Each time an item is purchased, the HTML for the shopping cart is retrieved. For example:

   <div >     <h3>Your basket:</h3>     <ul>       <li>Small Softshell Jacket x 2</li>     </ul>     <p><a href="/basket/">Edit selection</a> | <a href= "/checkout/">Go to checkout</a></p>   </div>

Figure 9-5. Rapha

9.4.6.3. Amazon Zuggest

Francis Shanahan's Amazon Zuggest (http://www.francisshanahan.com/zuggest.aspx) provides a Live Search: results are shown as you type. The server responds by providing the entire HTML for each resultfor example:

   <table>     <tr><td valign=top width='20%'><b>Vempire Or Dark Faerytales in Phallustei</b><br>     <a href='http://www.amazon.com/exec/obidos/redirect?tag=francshanacom-20%26link_ code=sp1%26camp=2025%26creative=165953%26path=http://www.amazon.com/gp/ redirect.html%253fASIN=B0000525ZY%2526tag=francshanacom-20%2526lcode=sp1%2526cID= 2025%2526ccmID=165953%2526location=/o/ASIN/B0000525ZY%25253FSubscriptionId= 16KBB0XN5XP4WSNNVKG2' target=_blank>Click to View</a><br>     [Music]<br>List Price<span class='lp'>$23.99</span><br>     <span class='lnp'>1 NEW from $14.99[$13.50 used]</span>     ...   </td></tr><table>

9.4.6.4. TalkDigger

TalkDigger (http://talkdigger.com) is a webfeed meta-search. Enter a query, and it fires off parallel queries to different search engines (an example of Multi-Stage Download). Each result is returned as an HTML table to be added to the page.

9.4.7. Code Example: Digg Spy

Digg Spy (http://digg.com/spy) responds with the full HTML to be displayed as well as some meta-content at the end. The results are fetched periodicallyfilldigs( ) is triggered by the recurring lastdigs( ). filldigs( ) executes an XMLHttpRequest Call, extracts the HTML from the full response, and morphs the results panel using its innerHTML property:

   function startlastdigs( ) {     window.setInterval("lastdigs( )",15000);   }   function filldigs( ) {     ...     s.open("GET",url2,true);     s.onreadystatechange=function( ) {         if (s.readyState == 4) {         ...         b = responsestring2.split(split);         ...         document.getElementById('diggspy').innerHTML = b[0];         ...       }     }     ...   }

9.4.8. Alternatives

9.4.8.1. Plain-Text Message, XML Message, JSON Message

Plain-Text Message, XML Message, and JSON Message (see more on these later in this chapter) all involve sending raw data as opposed to concrete display detail. When the browser receives such responses, it can render it or use it in some other way, such as retaining some information. In contrast, HTML Messages are likely to be display directly and are not retained. A further difference is that HTML Messages tend to be responses only, whereas these other formats are often used for uploading data as well.

9.4.9. Related Patterns

9.4.9.1. On-Demand JavaScript

Where HTML Message provides snippets of HTML to be fused on to the page, On-Demand JavaScript (Chapter 6) can provide snippets of JavaScript to be executed immediately. The idea is introduced in that pattern as "Behavior Message."

9.4.10. Metaphor

Sending an HTML Message is like sending a photographthere's a lot of visual detail, but any metadata, such as location and subjects, can only be inferred.