Let's talk about exceptions ...
How do you handle exceptions? Do you think upfront about the type of exceptions that you want to catch or do you just let the outside world handle it?

-- Jeroen van Bergen in JW Blogs

Newsletter sign-up

Sign up for our technology specific newsletters.

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

Process XML with JavaBeans, Part 1

Interconnect JavaBeans to process XML

By Mark Johnson, JavaWorld.com, 11/20/99

The expression "eating your own dog food" has gained currency over the last few years. It means taking the product you're selling in your daily business and using it yourself, so that you understand it from the consumer's point of view. I've been churning out columns on JavaBeans (my particular brand of dog food) for the last couple of years, teaching readers how to create new JavaBeans and use them in novel ways. But I haven't focused on using JavaBeans in applications -- I haven't been eating my own dog food. And it's about time I sat down to a big chunky bowl of it.

TEXTBOX: TEXTBOX_HEAD: Process XML with JavaBeans: Read the whole series!

:END_TEXTBOX

With that in mind, this month I am going to cover not how to create JavaBeans, but how to use them. Using JavaBeans to create applications in an integrated development environment (IDE) is a great way to learn how to think in components. Component designers and implementers who are forced to chow down on what they've been dishing up quickly learn what makes a component useful -- or useless. Many developers who assemble JavaBeans into running applications have experience primarily with GUI components; thus, in this series, I'll particularly focus on components that do data processing and have no runtime user interface.

The software package I'll be using for this discussion is IBM's XML Bean Suite, available for free from IBM's alphaBeans site (see Resources for a link). This package is very different from the XML JavaBeans and BML I've covered in the past. Those discussions dealt with converting JavaBean components to XML, or creating JavaBeans from XML. The XML Bean Suite, on the other hand, is a set of JavaBean components designed for processing XML data. The suite contains JavaBeans that a developer interconnects visually in an IDE in order to read, write, display, search, and filter XML data. Many of these JavaBeans have no user interface at runtime; they do most of the application's work internally. They're also excellent design examples of how to encapsulate functionality into a component.

This article assumes that you're familiar with the basics of JavaBeans and XML. Links to background material for this article appear in the Resources section.

This month's column is mostly an overview of the XML Bean Suite, which contains a large number of classes for processing XML. I'll also discuss how IDEs interconnect JavaBeans in response to your input, and I'll point out useful design principles as we go along. Columns to follow will use the XML bean classes to create applications (such as an XML file editor) that process XML data.

Contents of the XML Bean Suite

The alphaBeans site (see Resources) is the JavaBeans section of IBM's alphaWorks site, which provides "early adopter developers direct access to IBM's emerging 'alpha-code' technologies." This means that the code is freely downloadable from the site. Some of the code is even available for free commercial use, but the licensing restrictions vary by package. The designation alpha also means that the software is not ready for prime time. APIs are not guaranteed to be stable, the software may be updated erratically, and IBM makes no guarantees about ever turning the material on alphaWorks (and alphaBeans) into commercial products. Still, several projects that began on alphaWorks have graduated to full commercial status. Most, if not all, alphaWorks technologies have online discussion forums where users can get advice from the developers creating the software, and can make suggestions for improving the products.

The XML Bean Suite is a set of 39 Java classes available for free from the alphaBeans site. Since it's alpha software, it doesn't yet work with the latest version of Swing (it requires Swing 1.0.2), and doesn't even work with the newest version of IBM's XML processor xml4j (it requires version 1.1.4). The license agreement that appears at download time grants redistribution rights to the code (though you shouldn't take my word for it -- read the license yourself).

The 39 classes in the suite are divided into five sets of related JavaBeans. Many of these beans are nonvisual; that is, they may have a design-time user interface (such as a property sheet), but have no user interface at runtime. The five sets of XML beans appear in Table 1.

Table 1. Five sets of XML beans in the XML Bean Suite
Bean Set # of Beans Description
XMLCoreBean 4 Nonvisual beans that convert XML between text and DOM representations and manage DOM Nodes


XMLViewer 5 Visual beans that display XML documents or DTDs in various ways


XMLEditor 12 Nonvisual operator beans that allow construction of DTD-directed XML editors


XMLProcessing 5 Nonvisual beans that provide filtering, tokenizing, searching, and other operations on XML data


XMLConvenience 13 Beans that implement common XML editing subfunctions by combining XMLEditor beans and java.awt GUI objects




Each of these bean sets provides a domain of XML processing. You can wire instances of the beans from these sets together to create XML applications. Let's look at the XMLCoreBean set first.

XMLCoreBean set

The most basic set of XML beans is XMLCoreBean. This set of beans lets you convert XML text to a Document Object Model (DOM) representation of the XML and convert the DOM to XML text. These XML beans all operate on DOM documents or parts of documents, so they act as the gateway between the DOM and XML. The most central of these is the XML parser DOMGenerator.

Talkin' 'bout DOM generation

The DOMGenerator bean is a JavaBean encapsulation of an XML parser, as shown in Figure 1. The bean has three properties: inputXmlFileLocation (a string), inputXmlText (also a string), and inputXmlURLLocation (a URL, which may specify the source of the XML data to be parsed). When any of these properties are set, DOMGenerator immediately reads the text from the XML source and produces a result of type org.w3c.dom.Document, which is the root of a DOM-object tree that represents the input XML. This Document can then be passed for processing to any object that receives a Document as input.

Figure 1. DOMGenerator produces a DOM result from XML input



DOMGenerator also fires several events to let any interested listener know how the parsing is coming along. DOMGenerator fires a DOMGenerationEvent before it starts parsing, as well as after it completes parsing, or after an error occurs. The event contains a code that indicates which type it is. An object that needs to know what a DOMGenerator is up to implements the interface DOMGenerationListener, which has methods generationStarted(), generationError(), and generationOver(). The object registers itself as a listener with the DOMGenerator in which it's interested, and the DOMGenerator then fires events at the listening object(s) by calling the appropriate DOMGenerationListener interface methods.

What does it mean for the DOMGenerator to fire an event? And what does its firing an event provide to the application developer? The answers to these questions lie in an explanation of how IDEs hook objects together.

SUBHEAD_BREAK: Event listener interfaces This is a good opportunity to discuss how IDEs interconnect objects. When you're writing a class, it's common to want an instance of your class to be notified when an event source fires an event. A good example is a label that changes when a DOMGenerator object begins parsing, which we'll set up shortly. To catch an event (because you're interested in the object firing the event), you write the class to implement the listener interface for that event, and then register yourself with the event source by calling addEventtypeListener, the event source's method.

So, some object (which object depends on your IDE) in the system implements DOMGenerationListener, and then calls DOMGenerator.addDOMGenerationListener(this). The DOMGenerator calls that object's generationStarted() method before it starts parsing, and that object sets the label's text value to reflect the fact that parsing has started.

A visual IDE sets up such a listener interface by letting you visually indicate the source and target objects, usually by drawing a line between them. Once the information about the event type, the event source, and the event target are indicated in the IDE, the IDE automatically generates the calls to addEventtypeListener and implementations for the listener interface.

Let's look at a quick example using DOMGenerator in IBM's VisualAge for Java. Note that these XML beans will work in any JavaBeans-compliant IDE, not just VisualAge. Any IDE worthy of the name will let users create event connections graphically. The diagrams may look a bit different, but the basic idea is the same across the different IDEs.

Figure 2 shows a tiny application that uses the DOMGenerator class to parse an XML file. This figure is a screen shot taken directly from the IDE (except that I added the letters A through D to aid discussion below.

Resources
Download the source code for this article XML and XML JavaBeans Suite resources