Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Process XML with JavaBeans, Part 2

How IDEs interconnect components

By Mark Johnson, JavaWorld.com, 12/29/99

In last month's column, I discussed the creation of XML-processing applications that have little or no user interface. That article covered the DOMGenerator, XMLTokenizer, XMLFileGenerator, and XMLStringGenerator components, all of which are nonvisual beans.

Last month's components showed you how to read and write XML trees. This month, I'll show you how to use the nonvisual XMLEditor bean set to process those trees. This article will be highly technical, so you must have prior knowledge of how JavaBeans interconnect in an integrated development environment (IDE) at the lowest level. I'll give a detailed example of a very simple application, with explanations of event and property connections, and describe how you can use them to create applications without programming.

This article assumes you've read Part 1 of this series and that you're familiar with the basics of XML, the Document Object Model (DOM), and JavaBeans, as well as the concept of building applications in an IDE. It would also be helpful to download and install IBM's XML Beans from IBM's alphaBeans site (see Resources).

The XMLEditor bean set

XMLEditor beans do not necessarily edit XML, despite what their name implies. Instead, these beans form a hierarchy of containers and operators that match particular features of an org.w3c.dom.Document or a org.w3c.dom.Node (which I will simply call Document, Node, Element, etc.), and hold a reference to that object for processing.

That object represents a part of the input XML tree being edited. As shown last month, a DOMGenerator bean creates a Document object, representing the tree of XML nodes. But that capability is almost useless if you can't pick the tree apart and use its pieces. That's where XMLEditor beans come in.

I'll start with an example that clarifies what I'm discussing here. Part of the sample XML I've been using for these articles, a recipe for Lime Jello Marshmallow Cottage Cheese Surprise, appears in Figure 1 in two different forms.

Figure 1. Recipe XML as text (left) and as objects (right)

The left side of the figure represents part of the sample XML document, encoded as ASCII text. (You can find a link to the entire sample XML code in the Resources section below.) On the right is the same document, represented as a tree of DOM Node objects (subclasses of org.w3c.dom.Node). The DOMGenerator (by way of its underlying parser) produces this tree from the input XML stream.

The top-level element is the Document node, only one of which exists for any given XML document. The DOMGenerator object creates an object of this type and provides it as its result property. A Document is a container that, if not empty, holds one and only one object of type Element, which is in turn given the same name as the Document's top-level tag. This element is called the document element. In this example, the document element is <Recipe>. (With the notation <Tagname>, I indicate both the name of an XML tag and the tag name returned by the getTagName() method of a corresponding DOM Element object.)

The <Recipe> contains a single <Name> that contains a Text item. The Text item's value is the name of the recipe. This structure is defined and enforced by the Document Type Definition (DTD) for the XML document. (You can see the simple DTD for this Recipe XML in Resources below.)

What does all this have to do with XMLEditor beans? Each container bean class in the XMLEditor bean set recognizes a particular Node type at the bean class's input. For example, a DocumentContainer XMLEditor bean takes a Document node as its input. A DocumentContainer's input is the value of its inputDocument property, which is write only. The DocumentContainer contains a read-write property called currentNode, which is the document to be edited. The DocumentContainer has a third property, result, which is read only, and returns the Document object that the DocumentContainer currently contains.

The inputDocument (write only) and result properties (read only) can be different because the document within the DocumentContainer (the currentNode) is editable. After editing (setting the currentNode property to refer to a different Document object, for example), the result document -- that is, the output -- may well be different from the input.

Let's apply this to the example above. Imagine setting a DocumentContainer's inputDocument to the Document object at the top of the object tree in Figure 1. The DocumentContainer will make the Document available as a Node (since a Document is a subclass of Node, and therefore is a Node), and then make that Node available as its currentNode property. It will also make the Document available as its result property.

To understand how an application composed of interconnected objects works, you must understand how to interconnect objects. What does it mean for objects to be connected to one another?

Object connection: An in-depth example

Returning to the example in Figure 1, let's build a small application that gives the user a view of a recipe's name -- that is, the contents of the <Name> element inside a Document's <Recipe> element. Figure 2 shows the configuration of just such an application running inside the IBM VisualAge for Java IDE. Other IDEs may present the connections between beans in completely different ways, but all serious IDEs allow connections between bean properties, events, and methods.

Figure 2. Configuration of the RecipeEditor application

The purpose of the RecipeEditor bean is simply to extract the text of the <Name> element of a Document containing a <Recipe> and display that <Name> to the user.

For the rest of this section, I'm going to delve into the inner workings of how IDEs connect objects to one another, using the simple RecipeEditor as an example. If you already understand event listener relationships and the ways in which IDEs interconnect components to create applications, you can skip down to the section titled An unprogrammed application .

Clicking the Open File button causes the DOMGenerator object (marked A in Figure 2) to read its input, parse any XML it finds, and produce a DOM Document as its output. But how exactly does clicking the button cause this to happen?

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.