- Introduction to Utopia
- A Fresh Beginning
- How This Enhances the DataGrid
- The JavaScript Scope of Things
The JavaScript Scope of Things
So now we have the data model and the customization strategy in place. As the silver XML bullet wings its way toward the heart of our DataGrid, what's a poor browser/JavaScript interpreter combination to do?
Start by getting the data from the server and feeding it to the object. At the heart of the data transfer will be the familiar hidden frame. For those who haven't had to make display changes in the background, the mechanism rests on the fact that pages returned from the same domain have unfettered access. With our page in a named frame in a frameset, JavaScript calls can be made to the other frame by reference:
parent.frames[<main frame>].addData(<XML data>);
Provided that the addData function exists in the <main frame>, all will be well. If not, the familiar Object expected error will be thrown.
Now, what happens once the data arrives within the object? Rather than rewriting the object to accommodate the data format and violating the often-underused principle of reusability, let's just make the data look right. Yet again, saved by the future that is XML. While the best browser support for XML once was IE5, the newest offering from Netscape has full standards compliance with XML 1.0. While that may seem like the makings for a repeat of the DHTML crisis of the past few years, in this case the XML standard is sufficiently strict to avoid that. Instead of ignoring data it doesn't understandlike most HTML parsersXML is case-sensitive and will choke at the sight of a single illegal character or unquoted attribute value.
Paradoxically, this compiler-lite behavior actually makes the job much easier. The rapidly shifting nature of the XML standards, however, has caused Microsoft, at least, to provide multiple, not-fully-compatible versions. Two steps forward, one step back. This looks to be clearing, but until then, if data is to be traveling to unknown locationssuch as different versions of Explorerstick to the basics.
In this instance, two basic utility functions are requireda main one to parse the data, and a smaller function to strip off the attributes list. These functions are to be reused, so the switch case structure for actually applying the results will remain in the DataGrid code, leaving only the following:
function parseXMLData(srcData) { var NODE_ELEMENT = 1; var xml = new ActiveXObject("Microsoft.XMLDOM"); var arReturn = new Array(); xml.async = false; xml.loadXML(srcData); if (xml.parseError.errorCode != 0) { alert("DATA Error: " + xml.parseError.reason); return false; } else { for (ix = 0; ix < xml.childNodes.length; ix++) { ... conversion from structure to arrays } } }
Voilà once more. All the data has been digested, and the DataGrid can now process the arrays as if they had been submitted in our original format.
Having completed this arduous journey, I can safely say in true developer fashion that I have every intention of tearing it down and rewriting it the first chance I get. Everyone's familiarity with XML and associated complexities will grow. New and better techniques and technologies will be created to accommodate the rise of a new understanding. I just wanted to prove that, with a little effort, even the staid, lowly browser and JavaScript can still be taught new tricks.