 | Level: Intermediate Brett McLaughlin (brett@newInstance.com), Author and Editor, O'Reilly Media Inc.
01 Dec 2002 In this tip, you'll learn about a better way to bootstrap in your DOM applications. This builds upon the previous tip, which examined the abilities that DOM natively provides for this task.
In my last tip, I explained the basics of DOM bootstrapping, and in particular how those basics behaved when using DOM Level 1 or 2. You learned how to obtain your vendor's implementation of the DOMImplementation class, and how to use it to produce Document and DocumentType objects. And most importantly, you saw the various problems with the bootstrapping that DOM provides for.
As a short refresher, I'll summarize what those problems are before moving on to a solution:
- A dependence is created on a specific parser
- In many cases, a dependence is created on a specific version of a specific parser
- Changes to the DOM implementation or parser require code-level changes and recompilation
-
Changes to the DOM implementation require CLASSPATH changes
Of these various issues, only one is really acceptable in a production environment -- the last one, 4, changes to an application's CLASSPATH. All the other limitations are serious ones, and affect your ability to have a reusable (and sometimes resellable) application.
If you recall, the last tip left off with the code fragment shown in Listing 1.
DOMImplementation domImpl =
new org.apache.xerces.dom.DOMImplementationImpl();
DocumentType docType =
domImpl.createDocumentType("rootElementName", "public ID", "system ID");
Document doc = domImpl.createDocument("", "rootElementName", docType);
|
While this is not a horrible solution for bootstrapping, it is not a particularly good one. Instead of using this approach and accepting its limitations, let's look at a better solution. Ideally, you need to be able to remove all of the vendor-specific code from the bootstrapping process, and specify that information outside of the application.
Ideally, you could set a system property in your code or at application startup (through the -D flag to the java process); I prefer org.w3c.dom.DOMImplementationClass as the name of this property. The value of this property is the implementation class that the code needs to instantiate an instance of DOMImplementation. In the examples, I've been using Apache Xerces, so this property's value is org.apache.xerces.dom.DOMImplementationImpl.
Once you get this basic idea in place, it's fairly simple to write a helper class that reads in that property, instantiates it, and returns the new object to the code that needs to get a DOM instance up and running. Listing 2 shows such a helper class.
package com.ibm.xml;
import org.w3c.dom.Document;
import org.w3c.dom.DocumentType;
import org.w3c.dom.DOMImplementation;
public class DOMFactory {
/** System property name */
private static final String IMPL_PROPERTY_NAME =
"org.w3c.dom.DOMImplementationClass";
/** Initialization flag */
private static boolean initialized = false;
/** The DOMImplementation to use */
private static DOMImplementation domImpl;
private static void initialize() throws Exception {
domImpl =
(DOMImplementation)Class.forName(
System.getProperty(IMPL_PROPERTY_NAME)).newInstance();
initialized = true;
}
public static Document newDocument(String namespaceURI, String rootQName,
DocumentType docType)
throws Exception {
if (!initialized) {
initialize();
}
return domImpl.createDocument(namespaceURI, rootQName, docType);
}
public static DocumentType newDocumentType(String rootQName,
String publicId, String systemId)
throws Exception {
if (!initialized) {
initialize();
}
return domImpl.createDocumentType(rootQName, publicId, systemId);
}
}
|
This turns out to be pretty straightforward. The entry points for this class are the two public methods, each of which returns one of the two DOM startup classes. These are the same two classes that a DOMImplementation generates, so this provides some uniformity in your use of the helper class. Both methods ensure that initialization has occurred, and then produce the requested object.
Initialization isn't that complex, either. The system property returns a class name (assuming it's used correctly!), and that class name is instantiated through the Class.forName().newInstance() mechanism. Once that's done, it's easy to store the object and use it to generate objects.
So there you have it! A better bootstrapping approach is really that simple. Just add this class to your class path, along with whatever parser JAR file you need, and set the system property before you start parsing. You'll be able to obtain DOM types without even dipping into vendor-specific code. This should tide you over until DOM Level 3 is in public release, and an even better approach to bootstrapping shows up. Curious? Good! I'll detail how DOM Level 3 is set to work in the next tip, and give you a jump on what's coming down the pipe. Until then, I'll see you online!
Resources
-
Part 1 of this series of tips on bootstrapping with DOM explains what bootstrapping is, explores the problems associated with it, and lays the basics for use in DOM Levels 1 and 2 (developerWorks, November 2002). Part 3 explains the changes to DOM Level 3 that relate to bootstrapping and improve upon DOM Levels 1 and 2 (developerWorks, December 2002).
- Read about the DOM API on W3C.org.
- Learn about the structure of a DOM document, and how to use Java technology to create a document from an XML file, make changes to it, and retrieve output, in Nicholas Chase's tutorial "Understanding DOM" (developerWorks, August 2001).
- Find more XML resources on the developerWorks XML zone.
-
IBM trial software: Build your next development project with trial software available for download directly from developerWorks.
- Find out how you can become an IBM Certified Developer in XML and related technologies.
- Want us to send you useful XML tips like this every week? Sign up for the developerWorks XML Tips newsletter.
About the author | 
| |
Brett McLaughlin has been working in computers since the Logo days (Remember the little triangle?). He currently specializes in building application infrastructure using the Java language and Java-related technologies. He has spent the last several years implementing these infrastructures at Nextel Communications and Allegiance Telecom, Inc. Brett is one of the co-founders of the Java Apache project Turbine, which builds a reusable component architecture for Web application development using Java servlets. He is also a contributor of the EJBoss project, an open source EJB application server, and Cocoon, an open source XML Web-publishing engine. |
Rate this page
| |
