XML JavaBeans, Part 2

Automatically convert JavaBeans to XML documents

1 2 3 4 Page 4
Page 4 of 4
  • Check to see if the property is the bean's Class -- The very first thing this getAsDOM() does (lines 114 to 116) is to check to see if the property name is class and the property type is java.lang.Class, and if it is, it returns null. This is because the Introspector (unless it's told otherwise by BeanInfo) notices that the JavaBean has a method called getClass() that returns a Class. So, by definition, it treats the object's class as a property. For most beans, this method will be asked to create XML for the object's class. This is not a valid property for our purposes (we deal with the property's class by asking the JVM about it, not by reading it from the XML), so we tell the caller to ignore this property by returning null.

  • Check to see if the bean provides custom XML for a property -- Next, lines (lines 130 to 136) check to see if the bean has a method called getPropertynameAsDOM(). This is just like the test we mentioned above for the getAsDOM(), except it tests an individual property instead of an entire bean. Looking for a method with a particular name in this way defines a naming convention that XMLBeanWriter uses to make programming both easy and flexible. If a bean has a Price property, for example, a programmer may define int getPrice() and void setPrice(int price) as usual, but then also define getPriceAsDOM(), and return an arbitrarily complex DOM fragment when this chunk of code requests it. We've created a new type of property accessor, which gets a property not as a value, but as a DOM tree. Of course, XMLBeanReader needs to be modified to handle a setPropertynameAsDOM accessor. We'll tackle that next month.

  • Get the property value -- If the bean doesn't define an accessor for the property as XML (let's call it an "XML property accessor"), then we've got to figure out how to represent it ourselves. In Figure 9, lines 157 to 159 use the property's getter method (which came from the PropertyDescriptor) to get the property's value (in the bean we're processing) as a java.lang.Object. Hereafter, any representation of this property must depend on having the property's value -- because otherwise, what are you formatting?

  • See if the property class knows how to represent itself as XML -- Lines 130 to 148 ask the PropertyDescriptor for the class of the property, and then use reflection to determine if the property's class defines a getAsDOM() method. In the first version of getAsDOM() (Figure 5, the one that gets the DOM fragment for a bean, rather than a property), we looked for a getAsDOM() method in the bean class; here, we're looking for one in the property class. As an example of this, I added a getAsDOM() method to the PersonName.java from last month. Now, when a Player is being converted to XML, this version of getAsDOM() detects that PersonName.getAsDOM() exists, and uses whatever that method returns as the representation of the name property. You can see the results of this substitution in the comments and formatting of the PersonName object in Figure 8.

  • Try to represent the property as a string using the PropertyEditor for the property -- Lines 190 to 220 try to get a string representation of the property. The idea here is to represent the property as a single string, which can be appended to the <Property> element as a Text node. The PropertyEditor for a property, found in the PropertyDescriptor, has methods to set and get the property as text. This means we can use the PropertyEditor to convert the object to and from a string. So, we ask the PropertyDescriptor for a PropertyEditor, and if that doesn't work, we ask the system (via PropertyEditorManager) for a default editor for the property's type. If we get a property editor in either of these two ways, we set its value (PropertyEditor.setValue()) to the value of the property, and then get its value as text. If all of that succeeds, lines 215 to 219 will create a Text node with the property text value inside, and return that as the DOM representation of the property.

  • Try to represent the property as a JavaBean -- If all of these other methods fail, we assume that the object returned is a JavaBean. We recursively call the first version of getAsDOM() on the property's value and hope for the best. Note that there's no guarantee that just any class will be a bean. What that means is, if you are going to define properties that return nonprimitive types, and have no property editor, and you don't want those properties to be lost, you'll have to define either getAsDOM() for the property, getPropertynameAsDOM() for the property, or getAsDOM() for the whole bean. If the property is a bean, however, these last few lines (lines 229 to 231) will correctly create the DOM document for the property, which is then (as you remember from the discussion of TXDocument above) used to write the XML to the output file. Voilà!

Conclusion

This month, we've created a class that turns a JavaBean into XML. Next month, we'll look at (and fix) some of the problems that our new code will cause for XMLBeanReader, and discuss some reader feedback. Please keep writing: it's gratifying to know that this column is helping people to better understand JavaBeans, XML, and how they work together. Please feel free to suggest improvements to the code you see here.

Mark Johnson has a B.S. in Computer and Electrical Engineering from Purdue University (1986), and has been writing for JavaWorld since August of 1997. He knows nothing about spectator sports and likes it that way. On a good day, he can watch a game being played on TV and tell you what sport it is, usually on the first guess. Mark currently works as a designer and developer for Object Products, Inc. in Fort Collins, CO.

Learn more about this topic

  • You can read the complete XML standard, called Extensible Markup Language (XML) 1.0 W3C Recommendation, here http://www.w3.org/TR/1998/REC-xml-19980210
  • Read the RDF (Resource Definition Framework) standard -- a work in-progress -- at http://www.w3.org/RDF/
  • One of the better "one-stop shopping" sources for XML information is at XML.com. It has links to just about everything in the XML world. One of the more interesting things at this site is, believe it or not, the commentary on XML technology http://www.xml.com
  • A current version of the XML FAQ by Peter Flynn, et al. This is the version of the FAQ recommended by the W3C http://www.ucc.ie/xml/
  • The parser from IBM's xml4j package is available free for noncommercial use. It's even free for commercial use, but be sure to read the license agreement http://www.alphaWorks.ibm.com/formula/XML
  • In a note unrelated to JavaBeans, but still too cool for words, check out Jikes, IBM's new open source java compiler! Find out about it at the alphaWorks site at http://www.alphaWorks.ibm.com/formula/JikesOS
  • For IBM's Bean Markup Language (BML), see http://www.alphaWorks.ibm.com/formula/BML
  • If you're interested in the fine details of the current Document Object Model (Level 1) specification, you can find it at the W3C's Web site at http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html
  • Microsoft has a good set of tutorials on XML at http://www.microsoft.com/xml/tutorial/default.asp
  • There's also a whole XML "workshop" area. Don't try to access the workshop in Netscape, thoughthe table of contents doesn't work! These documents are free training, and are well written (though the examples don't always work, even in IE5beta.) Just don't be fooled into thinking that everything there is open standard. Some of the tutorials and many of the articles are about Microsoft-only technology that won't work with all browsers or platforms http://www.microsoft.com/xml/default.asp

1 2 3 4 Page 4
Page 4 of 4