Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

XML and Java: A potent partnership, Part 4

Learn how Java, laced with JavaScript, pushes XML's flexibility into new dimensions

By Todd Sundsted, JavaWorld.com, 09/20/99

XML is quickly becoming the standard for both document markup and data exchange. Many factors are driving XML's popularity, including its inherent flexibility, exemplified by its ability to be extended to include tags not found in the original tag set.

XML's flexibility comes with a price, however. Consider HTML, XML's predecessor. HTML sports a fixed tag set (although in the early days of the Web, Netscape and others defined new tags at such a frantic pace that at times the tag set seemed anything but fixed), which allows developers to completely specify an HTML tool's functionality -- up front. No such guarantee exists for many XML tools. Instead, these tools must be as flexible as the XML they work with. They must "do the right thing" when they encounter a novel tag in their XML input. They must expect the unexpected.

"XML and Java: A potent partnership:: Read the whole series!



Java, with its ability to dynamically load code into an executing program, provides a clean solution to this problem. A Java-based XML tool can load code and, thereby, flexibly extend its core functionality to meet the needs of any document it encounters.

This is the heart of the concept that I've been pursuing for the last few months.

Last month, I introduced JavaScript into the mix because it enables us to push XML's flexibility into a new dimension. Consider this: with scripting support, XML documents can include code, affecting their own processing.

I've provided the complete source code for those readers who can't sleep until they see it all. For instructions on downloading, extracting, setting up, and running the code, please read the accompanying sidebar, "Install and run the code."

The design in review

Let's begin with an examination of our basic design from two months ago. If you're new to this series, or in need of a refresher, I'd suggest going back and reading the first two articles in this series (see Resources).

The core of our design, as shown in Figure 1, consists of two tree structures: one is the DOM (Document Object Model) tree, representing, in memory, the information in an XML document; the other is the element tree, corresponding one-to-one with the nodes in the DOM tree that represented tags in the XML document.

Figure 1. The core design

A design like this isn't bad for static information. However, if we intend to modify the information by adding, deleting, or moving nodes or subtrees, keeping two parallel trees in sync quickly becomes a maintenance headache. Therefore, let's consider another design, as shown below in Figure 2.

Figure 2. An alternate design

In this design, we still have handlers (or hooks, in the parlance of two months ago) that encapsulate the behaviors we want to associate with elements in the DOM tree, but we don't compose them into another tree. Instead, we map the handlers to the elements they handle (and vice versa) with a hash table. Now maintenance has to be performed only on one tree -- the DOM tree.

1 | 2 |  Next >
Resources