Preamble:
I thought I'd try to do something a little different than what you've typically seen here on AlphaFilter. I'm going to try to make this a weekly column, focusing on - Microsoft Internet Explorer and JScript. The reason for this is not that I'm a 'Nix basher or totally and blindly in love with all things Redmond but rather it's simply what I do all day professionally and unless the browser statistics out there change, developing for IE specific is not a completely insane thing to do. Plus, Microsoft has enhanced some things to make it an extremely attractive development platform. So be warned: I know a lot (if not all) things here won't work on Mozilla or Safari or whatever...but that's not my purpose here. My plan is to make it episodic, so just like other more famous episodic works, you'll have to endure some JarJar to get to the point where Darth cuts off Luke's hand. I'll try to keep things moving...not too much JarJar. So let's dive in....
An Introduction:
My day job is to develop business applications. No more, no less. These apps need to be highly scalable and preforming, easy to deploy and maintain, and we (like most US companies) are a pure Windows shop on the client. We'll talk about our server environment in a later episode. My apps are not public facing but rather internal use, on site only applications (network connect only), primarily used for data entry and financial analysis. So we chose IE 6 for our platform of client development and DHTML (HTML, JScript & CSS) as our interface development technology. Clients communicate with the server via XMLHTTP, avoiding the traditional Form-POST style of web (ASP) application. My project, affectionately known as the "Monster", that I've worked on for the last 18 months will be mentioned and referred to many times throughout these articles, so be warned. It's a huge database driven application containing around 100K lines of client-side JScript using every Microsoft trick in the book. It deals with lots of data: around 1000 fields, yet had to be high performance as it was replacing clunky old (but fast moving) green screens and had a bunch of other features (such as looking like a Win32 application) that we'll hit over the next few months. So that's my environment, let's move on...
So why data islands?
So what the heck is the data island (as mentioned in the title) and what does it have to do with all of this? Let's start at the beginning: Back in 1999 or so, Microsoft extended the HTML standard tags and added the <XML> tag -- and what is between these tags is affectionately known as the data island. At the same time, Microsoft introduced a ton of other things, including binding HTML controls to the data in the Island. While truly cool, this has proven to not be very practical and that's not what I'm covering here. Just the plain old data island.... The basic layout is:
<body>
<XML id="Foo" [src="Bar.xml]>
...Valid XML....
</XML>
</body>
So a populated Data Island looks like this:
<body>
<XML id="TheIslandName">
<top>
<row>
<field name="txtFirstName" value="Mike" />
<field name="txtLastName" value="Shaffer" />
</row>
</top>
</XML>
</body>
A couple of things to note: While IE won't display what's in between the <XML> tag, it has to be valid XML or the page won't load. The <XML> tag is a special HTML tag that can only have an id attribute and optionally a src attribute, (no events, which would be cool). While the page is loaded, IE automatically loads the XML content into an MSXML DOM object. I place them between the <body> tags, but I believe they can go any where between the <html> tags.
You can include XML on a traditional HTML page, or it can be"bolted" into the HTML while the page is being built up in IIS in ASPland. So when the HTML lands on the client, the "data" is there too. That's a nice feature. Another nice feature is that the XML is "attached" to the HTML in a single file. So for distribution purposes, you can provide foo.htm and have script, presentation, style and data all in one. The last reason that I think they're worth while is that they are so easy...you can see what I mean at Example 1.
The button throws an alert that displays the XML from above. .xml is a native property of all XML DOM objects that casts the entire XML content to a string type. So loading the XML goes from:
function init()
{
var oXML = new ActiveXObject("MSXML2.DOMDocument.3.0");
oXML.async = false;
oXML.loadXML("<?xml version='1.0'?><books><book>Test</book></books>");
oXML.setProperty("SelectionLanguage","XPath");
oXML.setProperty("SelectionNamespaces","xmlns:my='urn:http://www.my.com/schema/'");
}
to:
nothing....The DOM already has the object loaded, ready to go. No new ActiveX Object or .load/.loadXML..it's all ready to go. It's that easy... Sure you can instantiate the XML DOM object, load the XML etc...but this is simpler and there isn't any performance hit from doing it this way.
I mentioned the src attribute on the <XML> tag. An example of this style is Example 2.There is no apparent difference between the two examples, but viewing the source tells a different story... The <XML> tag has a src attribute of "foo.xml" which is conveniently located on the server. Rather than it being inline, in the source, it is obtained when the page loads and then loaded into the XML DOM. Why would you do this versus a local data island? There are lot's of good reasons, one might be that if you are dynamically building your HTML in something like XSLT or ASP, you may not have a local script section or easy access to it. So it might be easier to reference the source in the HTML portion of the page. A bit of a single use admittedly... In this instance it might be easier to use the create an ActiveX Object method as listed above, replacing the oXML.loadXML.. with oXML.load("http://server/foo.xml");.
The Down Side:
So what's the down side? As my pal Brian James (a JScript master) points out: IE natively uses the default MSXML version when it creates the data island. So if your default version is 3.0, but you've got 4.0 installed too, the data island can only be 3.0. If you create the MSXML object explicitly in JScript, you can specify the version. If Microsoft wanted to do us a favor, they'd let you specify a version when creating the <XML> tag....oh to dream. They'd also let us bind events to the XML content. It would be sweet to be able to have an onchange on the island, and then be able to identify the "source element" of the change...
Many people want to know why you'd use this instead of associative arrays in JScript or hidden fields or any of the many ways of traditionally representing data in JScript. Microsoft has poured a ton of effort into making MSXML work fast, and Data Islands take advantage of that just like all XML. To do a look up in XML is lightning fast. Plus the flexibility and power of XPath (think SQL statements morphed with filesystem directory commands..) make XML a dynamo. Plus, I think XML is much easier to read and construct for us mere mortals. Complex hierarchies are simple in XML, but can be mind-boggling spread out through multiple arrays. Think of XML Data Islands as mini client side databases, they can be queried, modified, deleted, inserted and refreshed...all very fast. Looking at the "Monster" for a moment: This thing is loaded with data islands, like 30 at last count. Some of them are huge (500K), some just 50 lines or so. All are filled and refreshed via XMLHTTP (we'll cover that in a few weeks..) and updated, then they are shipped back up to the middleware in their entirety for persistence to the "real" database.
An Aside:
As you look at my sample files, you might see a cool feature that I just have to mention. Like many companies, we're standardized on IE, 6.0 in specific. But when we first started deploying this style of applications, the complaints rang in from all over the US. It seems that the corporate standard is a little loose. So we had some IE 5.5's, 5.01's, 4.73's...even some Netscape show up. So scrounging on MSDN, we found this very effective test code(here's a basic skeleton):
<html>
<!--[if gte IE 6]>
<head></head>
<body></body>
<![endif]-->
<![if lt IE 6]>
This application requires Internet Explorer 6.0 or greater.
<![endif]-->
</html>
Nails it fast and fool proof, without having to build it in code, which results in a better user experience, or denial of one, if you will. I had never used it or even seen it before, so I thought I'd point it out. The XML tag is actually supported in IE 4.73 (hope that number is right) but the actual MSXML object is really limited to IE 5.01 and greater. If you change the IE 6 test above to 5.01, you'll still get Data Island support.
The Finish Line:
Well, there you go, the first episode and only a couple lines of JScript! We'll do more next week when we use our Data Islands like an ADO recordset and manipulate and display the data...it'll be great fun.
If anyone has any comments or questions, email me at ms_@_mybluecoat.com (remove the underlines first...)