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: Laurent Bihanic <laurent.bihanic AT atosorigin.com>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: John Cowan <jcowan AT reutershealth.com>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] The mysterious LeafNode class
  • Date: Fri, 20 Sep 2002 10:49:16 +0200

Elliotte Rusty Harold wrote:
Actually, you don't have to distinguish between containers and leaves when
navigating now. LeafNode is a subclass of TreeNode. TreeNode is a subclass of Node. Most of the navigation methods (except getParent()) are in TreeNode. LeafNode could go away without really affecting the model at all. Currently it's effectively an implementation detail, not part of the public API.

:-( If you get rid of LeafNode, you may end up adding a method such as isLeaf() in TreeNode.

Mvoing to a single Node class is simpler. That's good. I originally started with just the Node class, but then I decided that Attributes and Namespaces needed to be distinguished from pieces of the tree. But then I got rid of the Namespace class completely, so now the only non-TreeNode node is an Attribute. That's not a very big benefit for what amounts to a relatively large complexity.

What bothers me with TreeNode is that, in addition to navigation methods, it is full of append/insert/remove methods. Wouldn't be better to reverse the model so that Node includes the navigation methods (including child navigation) and TreeNode defines the append/insert/remove methods. With this model, Comments, PIs, Attributes and Text would be Nodes and only Element and Document be TreeNodes (BranchNode would be more appropriate then).

This would not change anything in the way to navigate the document tree. Extra typecasts would be required to adding/removing children but who cares since one has to test the node type before doing so or risk a runtime exception.

By the way, -1 for the one-size-fits-all Node class. DOM4J tries that and it's way too cluttered with methods that only apply to one or two classes.

Laurent





Archive powered by MHonArc 2.6.24.

Top of Page