WebReference.com - Part 2 of Chapter 21: Professional JavaScript, from Wrox Press Ltd (2/7) | WebReference

WebReference.com - Part 2 of Chapter 21: Professional JavaScript, from Wrox Press Ltd (2/7)

To page 1current pageTo page 3To page 4To page 5To page 6To page 7
[previous] [next]

Professional JavaScript 2nd Edition

Hidden Frames and Layers

This technique passes textual content in a hidden frame or layer. Layers are already risky, because they are deprecated. Hidden frames are a good solution although there is a flaw that we'll consider in a moment. At News Online, the HTML design authorities mandated that we should not use additional frames on the front page. That effectively ruled out that technique, even though it would be a fairly optimal approach. The downside, is that you need to hide the frame somewhere. The same JavaScript eval() trick would work though.

There's another more serious shortcoming in this technique, which is to do with the way web browsers load pages and web servers respond to simultaneous requests. The outcome of that, is that you simply cannot be sure when that frame containing the hidden data is loaded. The necessary tricks to set synchronization flags require onLoad handlers in the data frame and the ticker, which both call functions in the parent frameset container. That's guaranteed to be loaded, because otherwise the child frames wouldn't have been requested. You can then set semaphores to indicate loading is complete and then access the data conditionally on those semaphores being set. It's all a bit too uncertain and any connection failures and loading errors can cause even more problems.

DOM Navigation

DOM navigation of document structures has been proven to be unworkable. Both IE and Netscape 6 provide the same API to the document content. Unfortunately, they treat whitespace and empty textNodes differently, and so the childNodes collections that might have been useful for walking down the tree are of no use, because none of the index values correlate between browsers. Indeed, IE on the Macintosh and Windows platforms are even further apart than the Macintosh versions of IE and Netscape 6.

Setting those problems aside, it's quite desirable to use DOM techniques to extract content from within the same document that the SCRIPT tag is located.

If only the DOM implementations provided a way to examine the child nodes of an object in a consistent manner, this would be a really useful technique, because the structured DIV block approach is widely supported. The biggest problem with DOM is that the interstitial text between each DIV tag is treated differently in IE and Netscape. In fact, IE on Macintosh and Windows platforms are significantly different. This means that the childNodes collection on each platform puts the child DIV blocks in completely different index locations in the collections. You can fix this by manually filtering the childNodes collections to discard all the textNodes. That way you could walk down the childNodes tree.

The DOM situation is under development and the DOM Level 2 traversal and range module provides the necessary filters, node iterators and tree walking capabilities that we currently lack. Without these, the DOM implementations are really so incomplete as to only provide marginal help over and above what we had with DHTML.

Structured DIV Blocks

Building a document structure from nested DIV blocks has the same disadvantage of needing to be statically included in the same document, although that can be done with a server-side include. It has the major advantage of providing structure. There are limitations, such that the ID values need to be unique and HTML 4 compliant in their naming conventions. That may cause problems with generating ID names algorithmically, so they can be fetched more easily.

So, here is an example data block formatted with DIV tags and showing how to build a simple childNodes filter that produces consistently the same list of childNodes on all browsers:

<HTML>
<BODY>
   <DIV ID='Level0' STYLE='display:none'>
   <DIV ID='Level1'>
   <DIV ID='Level2'>
      Content
   </DIV>
   </DIV>
   </DIV>
<SCRIPT LANGUAGE="JavaScript">
   var myArray = new Array();
   var ii;
   var jj;
// Get a reference to the top level <DIV>
myObject = document.getElementById("Level0");
// Filter the childNodes collection
jj = 0;
for(ii=0; ii<myObject.childNodes.length; ii++)
{
   if(myObject.childNodes[ii].id)
   {
      myArray[jj] = myObject.childNodes[ii];
   }
}
// Display filtered childNodes
document.write(myArray.length);
document.write("<BR>");
document.write("<BR>");
for(ii=0; ii<myArray.length; ii++)
{
   document.write(myArray[ii]);
   document.write(" : ");
   document.write(myArray[ii].id);
   document.write("<BR>");
}
</SCRIPT>
</BODY>
</HTML>

In the News Online ticker, the DIV blocks are structured so that the content is a collection of several story headline texts and the associated links where we can see a page full of text about the story. The additional meta-data is just an item count, so we know how many stories there are. We could store other meta-data too. We could store some controls for the ticker speed, and how often it should be reloaded.

The entire story content and meta-data tree is also enclosed in a single top-level DIV block. This is helpful, because we can set the style of the block so its display: property makes the DIV block invisible. That's also shown in this simpler example. Without that, the content of the DIV blocks would be visible.

On a site, such as News Online, the news story data for the ticker is published into a separate file and a server-side include is used to insert it into the outgoing response from the web server.


To page 1current pageTo page 3To page 4To page 5To page 6To page 7
[previous] [next]

Created: November 8, 2001
Revised: November 8, 2001


URL: http://webreference.com/programming/javascript/professional/chap21/2/2.html