TEXTBOX: TEXTBOX_HEAD: Process XML with JavaBeans: Read the whole series!
:END_TEXTBOX
The result of last month's article was an XML editor that edited an XML document containing a single tag, <Name>. Though the little application provided a good example of how IDEs wire applications together with event relationships, I
think the result was disappointing. I certainly wasn't hurrying home from work every night to play with the Recipe Name Editor.
Figure 1 shows the extensions I've created to make the application more useful. I call this improved Recipe Editor the ComplicatedRecipeEditor.
Figure 1. ComplicatedRecipeEditor, a (slightly) improved Recipe Editor
I'm making three extensions to last month's editor. I start by adding a <Description> tag (indicated by the letter A in Figure 1). Second, I add a Save File button (B), which saves the editor's DOM document as an XML file. Third, I add a status bar for error messages (C), which also indicates the name of the file being edited.
I'll do all of this the hard way first, using nonvisual beans and connecting them to standard AWT (Abstract Windowing Toolkit) interface components. The result will be a tangled web of event and property relationships. Then I'll show you how to use XMLConvenience beans to create the same application with just a few objects and connections.
Figure 2 shows last month's application. I'm going to add a TextArea so you can edit a recipe's description as well as its name.

Figure 2. Last month's Recipe Editor application
Figure 3 shows the additional components and connections that I made to generate a <Description> tag to the editor. Don't be intimidated by Figure 3's complexity. (My apologies for the event and property connection lines
overlapping the object labels. That's how VisualAge for Java's Visual Composition Editor draws things.)
The only additions are that of another ElementContainer (F in Figure 3), which holds the <Description> element, and a TextContainer (H), which holds the text inside the <Description>.

Figure 3. Adding a <Description> tag to the editor
Take a look at the objects underneath the DocumentContainer1 object (C) in Figure 3. DocumentContainer1 has an ElementContainer called ECFindRecipe, which itself has two ElementContainers, ECFindName and ECFindDesc, each of which has a TextContainer.
This structure of XML JavaBeans objects exactly reflects the structure of the DOM tree it represents, as Figure 4 illustrates. XML JavaBeans container classes are designed to can contain any structure that can be described by an XML DTD (document type definition). XML JavaBeans programmers can then connect these containers to other objects, such as GUI components, to do useful work.

Figure 4. DOM tree and XML JavaBeans container structures are similar
A number of readers have been a bit confused about what the labels in the diagram refer to: classes or instances. Each object
label in the diagram is the name of the instance, and it is the value of that instance's beanName property. VisualAge for Java makes up instance names by adding a number to the class name (as in the case of DocumentContainer1). In some cases (like DOMGenerator), I changed the instance name to the class name. It would be like naming my dog "Dog." Just remember that all of the objects
in the diagram are instances, not classes, and the whole discussion will make a lot more sense.
The class diagrammed in Figure 3 works by objects passing events and values to one another. A look at the diagram may not
make it clear how these DOM elements are "passed" from one XML JavaBean to another as I've been describing. It's really quite
simple. The connection between the output of one XML JavaBean and the input of another is a bound property relationship. A bound property is a property whose value is set to track some other property of an object. In this case,
the result property of each XML JavaBean is bound to the input property of another bean. When the first bean produces a result, it sets
its result property, and the property relationship (by way of a PropertyChange event) updates the other bean's input to that same value. It is as if the first bean passed its result to the second bean.
The class whose structure is displayed in Figure 3 works almost the same as RecipeEditor did in last month's article. When a user clicks the Open File button, the DOMGenerator (B in Figure 3) acquires an input filename from ExtendedFileDialog and produces a DOM tree that represents the XML document in the file. DocumentContainer1 (C), which receives the DOM tree as input, passes any <Recipe> element it finds at the top level of the tree through to its output. The <Recipe> element in DocumentContainer1 is passed to an ElementContainer called ECFindRecipe (D), whose outputs are in turn connected to two other ElementContainers, ECFindName (E) and ECFindDesc (F). These containers search for the <Name> and <Description> nodes (respectively) of the Recipe that contains them. Connected to the output of those last two containers are the TextContainer objects NameContainer (G) and DescContainer (H), which contain Text nodes that hold the text values of the recipe's name and description. The content of the two Text nodes is edited in the GUI.
xml4j package is available free for noncommercial use. It's even free for commercial use, but be sure to read the license agreement
first