Section 11.1. XML Data Island

11.1. XML Data Island

Data, DOM, Storage, XBL, XML

Figure 11-1. XML Data Island

11.1.1. Developer Story

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.

11.1.2. Problem

How can you render incoming XML and retain the data?

11.1.3. Forces

  • Many Ajax Apps receive XML Messages and must convert them into HTML.

  • The incoming data often has to be retained as well.

11.1.4. Solution

Retain XML responses as XML Data Islandsnodes 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 ></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 >         <score>           <title>Galaga"</title>           <player>AAA</player>           <score>999610</score>         <score>       </xml>     </body>   </html> 

How do you do something like that in JavaScript? You might assume it's pretty trivial, given that HTML itself is XML (or close enough to it). But unfortunately, it's not as easy as you'd expect and also is browser-dependent. If you have the XML string, you can set scoreData element's innerHTML as the string value. If you have only a DOM node, you can convert it to an XML string by inspecting its innerHTML property. However, this won't work on all browsers and might lead to portability problems as browsers interpret the string in different ways. An alternative is to avoid string manipulation and directly graft one DOM node onto another. The document object has two useful methods here: cloneNode( ) and importNode( ). Again, there are plenty of portability issues to considersee Peter-Paul Koch's discussion ( In most cases, the easiest, most portable, solution will be to use a library like Sarissa (

In a more general sense, this pattern involves retaining XML Messages regardless of how you store them. While the DOM is a convenient place for storage and has some value-added features described below, you could also save the XML in a normal JavaScript variable. The key characteristic of the pattern is that you're retaining the XML Message and using it as a data structure, rather than transforming it into a custom JavaScript object.

It's easy enough to do this, but what's the point? Here are three applications:

Transforming XML Data Islands to and from HTML

XML Data Islands are traditionally an IE-specific capability. From IE5, you can tie HTML controls to an embedded XML document. When the XML data changes, the HTML is also updated. And when the HTML changesif the control is mutablethe XML is updated. In IE, to tie an HTML element to a data island, you indicate the XML data island, preceded by a # and the field within that island. So to create an input field based on the player field above:

 <input type="text" datasrc="/books/2/755/1/html/2/#scoreData" datafld="player"> 

Now, this is an IE-specific function, but Firefox has its own alternative: eXtensible Binding Language (XBL) (,39044903,39236695,00.htm). The idea is similar, but the updating behavior isn't automatic. With Mozilla, you have to create an XBL document that explicitly states how HTML controls relate to the XML.

Even without these browser-specific capabilities, it's still fairly straightforward to make the transformation using a technology like Browser-Side XSLT (see later in this chapter).

Retaining XML for later use

Sometimes it's useful to retain the response for later use. For example, you can keep it to build up a Browser-Side Cache (Chapter 13). Another application is for validationthe browser might receive a raw XML document containing some form fields, then augment it with user responses before uploading it back to the server.

To store a response for later use, you could wrap it into a custom data structure. But that requires some coding effort and also complicates things a bit by adding a new data structure. When the response is an XML Message, you have an alternative: just keep the XML. While it may not be the optimal format, it's still a structured format that you can query quite easily.

Including an XML document on initial page load

The initial page load sequence sometimes requires an XML document. For example, the XML document might describe the initial data to be viewed or it might be a stylesheet for Browser-Side XSLT. You could go through the motions of extracting it with a further XMLHttpRequest Call, but it would be faster to load the XML as part of the initial page load. An XML Data Island is an easy way to do this. Just output the XML content wrapped inside an <xml> tag. Alternatively, IE lets you specify a URL in the src attribute.

11.1.5. Real-World Examples PerfectXML Demo

Darshan Singh's IE demo ( is explained in the corresponding PerfectXML article ( It's a straightforward table, populated by an XML Data Island embedded in the corresponding HTML. The demo works in IE only. demo

Thad Hoffman's Mozilla demo ( is explained in a corresponding article ( corresponding article. It simulates IE's behavior, using standard XML parsing in JavaScript, to convert XML to HTML. The demo works only in Mozilla or Firefox. TechRepublic demo

Philip Perkin's example explains how to use Mozilla's answer to XML Data Islands, eXtensible Binding Language (XBL); see Figure 11-2 ( The code's online and there's a demo available (

Figure 11-2. XBL demo

11.1.6. Code Refactoring: AjaxPatterns XML Data Island Sum

This example adds a very simple caching mechanism to the Basic Sum Demo ( The most recent XML response is retained as an XML Data Island, so if the user tries to resubmit the query, no server call occurs. In the absence of an XML Data Island, the script would need to retain the call and response in a custom data format. But retaining it as XML means no data format has to be created. Instead of manually navigating the document with the standard DOM API, the Interactive Website Framework (IWF) library ( is used. IWF lets you treat the DOM object more like a custom data structureas the following code shows, it lets you drill down using tag names rather than generic XML names.

Some minor changes are made to the XML format for easier parsing, leading to the following data format (

   <sum>     <inputs>       <figure1>4</figure1>       <figure2>6</figure2>       <figure3></figure3>     </inputs>     <outputs>10</outputs>   </sum> 

To the initial HTML, a placeholder has been introduced to retain the most recent XML responsethe XML Data Island:

   <xml ></xml> 

The XML is retrieved as a plain-text document and IWF is used to transform it into a special DOM-like format for convenient parsing. The IWF document is interrogated to get the sum, which is injected onto the DOM status element as before. Finally, the XML Data Island is populated with the XML response in its plain-text format (as opposed to a DOM object). The XML response includes the input figures as well as the resulting sum, so we'll be able to use it later on to decide whether the figures have changed since the last response.

   function onSumResponse(xml, headers, callingContext) {     var doc = new iwfXmlDoc(xml);     $("sum").innerHTML = doc.sum.outputs[0].getText( )     $("sumResponse").innerHTML = xml;   } 

The XML Data Island is used to decide whether a call is necessary. To make the effect more visible, the status area is blanked as soon as the user clicks submit. It's repopulated with the retained value if it turns out the current data is the same as the previous query:

   function submitSum( ) {     $("sum").innerHTML = "---";     var figures = {       figure1: $("figure1").value,       figure2: $("figure2").value,       figure3: $("figure3").value     }     var sumResponseXML = $("sumResponse").innerHTML;     if (sumResponseXML!="") {       doc = new iwfXmlDoc(sumResponseXML);       var alreadyStoredInDOM = (             figures.figure1 == doc.sum.inputs[0].figure1[0].getText( )         && figures.figure2 == doc.sum.inputs[0].figure2[0].getText( )         && figures.figure3 == doc.sum.inputs[0].figure3[0].getText( )       );       if (alreadyStoredInDOM) {         // No need to fetch - just retrieve the sum from the DOM         $("sum").innerHTML = doc.sum.outputs[0].getText( );         return;       }     }     ajaxCaller.get("sumXML.phtml", figures, onSumResponse, false, null);   } 

11.1.7. Alternatives Browser-Side XSLT

Browser-Side XSLT (see the next pattern) is a more general way to transform XML into HTML. In addition, the patterns are related insofar as Browser-Side XSLT can use an XML Data Island to store stylesheets. Browser-Side Templating

Browser-Side Templating (see later) is a general technique for converting XML or other data formats into HTML. Browser-Side Cache

XML Data Island can be used to store a Browser-Side Cache (Chapter 13).

11.1.8. Metaphor

The name itself is the metaphor: an island of data amid a pool of HTML content.

Ajax Design Patterns
Ajax Design Patterns
ISBN: 0596101805
EAN: 2147483647
Year: 2007
Pages: 169

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: