Examining Extra Functionality in MSXML
Microsoft XML Parser (MSXML) 3, which ships with IE 6, provides some additional properties and methods that you can use with the DOM interfaces discussed previously. You'll see examples of some of these additions later, as well as how to create similar functionality in Mozilla.
Let's start by looking at extensions to the
Additions to the MSXML Document Interface
MSXML includes the following additions to the Document interface:
load() method loads XML content from the URL argument:
The loading happens asynchronously, which means that the method returns immediately
and the parser loads the XML. As the content loads, it changes the value of the
readystate property and raises the
load() method is also part of the DOM Level 3 Save and Load module. Mozilla supports both this method and the async property from DOM Level 3.
loadXML() method loads XML string data into a
readyState property is read-only and indicates the state of a loaded document. Table 8-2 summarizes the values for this property and their meaning.
This event fires every time the readyState property changes. You can use it to assign a handler for the event:
MSXML Node Interface Additions
MSXML includes the following additions to the
xml property is a read-only property that returns the serialized contents of a node. In other words, it converts the raw XML into a text format:
This method returns the next node in the node collection:
The method will return the first node if no previous node has been selected. You can use
reset() method to return to the starting point.
selectNodes() method creates a
NodeList of all nodes that match the specified XPath expression:
If no match is made, the method returns null.
This method works in the same way as the
selectNodes() method, except that it selects the first matching node:
transformNode() method performs XSLT transformations on the current node and returns the result of the transformation as a string. This method takes a stylesheet argument, which is a
DOM Document containing the XSLT stylesheet:
transformNodeToObject() method is very similar to the previous method. The difference is that it fills the
OutputDOM document with the result of the transformation:
XMLHttpRequest ActiveX Object
MSXML also includes an ActiveX object called the
Browser Support for the W3C DOM
You can use the following code to create an instance of the MSXML parser:
Bear in mind that different versions of IE use different ActiveX objects. Mozilla creates a document using this line:
These lines are just the start of the differences between the two major browsers.
Using the xDOM Wrapper
browserDetect.js with your resources.
The wrapper needs to use a common method to create documents. It also needs to be able to provide a mechanism for Mozilla to deal with MSXML-specific methods and properties and the application of XSLT stylesheets on the client side.
Table 8-3 summarizes the functions available in
browserDetect.js), along with
This section walks through the
The code starts by declaring global variables that library functions will use. The most important line follows:
This line creates an array of strings that contain the ProgIDs for creating different versions of the MSXML DOMDocument object.
The next step initializes the wrapper. The method used depends on the browser version.
Initializing in IE
For IE, the initialization code determines which version of MSXML a user has available on his
or her machine by iterating through the
Initializing in Mozilla
_Moz_Document_load is a function that the wrapper declares later.
The preceding code replaces the default load method in the Mozilla DOM with a new method,
_Moz_Document_load(). It keeps a reference to the default method by first assigning it to a prototype of a different name,
Document.prototype.__load__. The wrapper must do this because it still needs to call the original method from within the new method. From an objectoriented perspective, this is like overriding a method and then calling that method on the super/parent class within the new method implementation.The wrapper also declares a new event handler called onreadystatechange:
The wrapper initially assigns the event handler a
null value. Later, the wrapper attaches code that runs when the event fires.
The final prototype declares a
Getter method to get the value of a variable:
Getter method appears as a property to the end user, but is implemented as a function. You don't need a corresponding Setter method because the xml property is read-only.
DOM Document object using the appropriate method for that browser.
The method also attaches an event handler to the Mozilla load event so that you can raise this event in the same way as in IE:
Private xDOM Library Functions
The remainder of the library file contains the implementations of the prototypes that you declared earlier. You can look through these to see how Mozilla natively handles some of its more advanced XML features.
The first method implemented is the Mozilla version of the
MSXML loadXML() method. This uses the
XMLParser object that is included in the Mozilla
XMLExtras library. This library ships with all Mozilla installations:
This method copies the nodes from the newly parsed DOM.
Moz_Document_load() overrides the Mozilla
load() method. This allows the wrapper to include code for firing the MSXML equivalent events:
updateReadyState() function is a helper method that sets the
readyState property and fires the necessary events:
The two functions that deal with XSLT are very similar. The only difference is that one of them serializes the result to a string, and the other returns the processed result as a
DOM Document object. Both functions allow the Mozilla
XSLTProcessor object to mimic XSLT transformations in MSXML:
Some of the extra functions in the wrapper aren't included in this brief walkthrough. You can look through the code if you want to explore further.
There are some important points to note when using xDOM. The first is that the wrapper cannot check the version of XSLT supported by the
DOM Document you create. If you need to support much older browsers, you may need to load a different XSLT document based on the version of MSXML installed. You can do this by looking at the value of the
strMSXMLProgID variable initialized when the xDOM library loads.
The xDOM library doesn't allow the free threaded version of the MSXML DOM Document to be created. The free threaded version is most important when running code on the server side. The object uses a different threading model to interact with the operating system, and this is important when there are multiple requests for the
DOM Document at the same time, as in serverside applications.
The xDOM wrapper doesn't provide a complete solution to the differences between MSXML and Mozilla. You still need to test your application rigorously in all browser versions that you're targeting. I checked xDOM with IE 6.0 and Mozilla 1.0.
So far, you've seen some of the theory behind scripting the DOM. Now it's time to look at how to apply this code in some examples.