Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] The mysterious LeafNode class

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: John Cowan <jcowan AT reutershealth.com>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] The mysterious LeafNode class
  • Date: Thu, 19 Sep 2002 14:13:57 -0400

At 1:02 PM -0400 9/19/02, John Cowan wrote:
The Javadoc on the site (which is all I am looking at just now, as I'm
trying to do an architectural review) has an undocumented LeafNode class,
which is the parent of DocType, Comment, ProcessingInstruction, and Text
(and the child of TreeNode). Presumably this is an attempt to abstract
the idea of a node which is not a container. What's the story here?

That's my laziness showing. :-)

LeafNode adds no new API. It simply implements about half a dozen methods like howManyChildren() with common code. For instance, howManyChildren() always returns zero for a leaf node.

If it proves confusing, it would be straight-forward enough to factor out those methods into the individual classes like Comment and Text, and remove it completely. The other way to go would be to expose it as public, which would allow tests of whether or not a particular node was a leaf node. I'm not sure if this is useful or not.

FWIW, I think it would be better to have Node and a child Container
whose children are Element and Document, and move the other stuff from
TreeNode to Node. It simplifies the architecture.


Could you be more specific about what would go where? Are you asking for Node --> ParentNode --> Element and Document, with other classes extending Node directly? Maybe that makes sense.

This is, however, possibly the first time in seven years I've actually regretted Java's lack of true multiple inheritance. I'd like to have separate ParentNode and ChildNode classes extending Node, with Document and Element subclassing ParentNode, Element also subclassing ChildNode, and the others just subclassing ChildNode. dom4j does this with interfaces, but I'm trying to stay away from interfaces.

On the other hand, having just the one TreeNode class does make tree walking a lot easier. There are no instanceof tests to distinguish between nodes and leaf nodes. That's sort of nice.

I could move some more stuff into Node. Most of the methods don't really make sense for attributes though. :-( getNextSibling() and getPreviousSibling() could be used for navigation from one attribute to the next. The child methods could behave pretty much the same as they do for leaf nodes. Maybe that makes sense.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| XML in a Nutshell, 2nd Edition (O'Reilly, 2002) |
| http://www.cafeconleche.org/books/xian2/ |
| http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+




Archive powered by MHonArc 2.6.24.

Top of Page