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>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] The mysterious LeafNode class
  • Date: Thu, 19 Sep 2002 14:58:45 -0400

At 2:36 PM -0400 9/19/02, John Cowan wrote:


I think it does make sense to put the navigation in Node. It's an open
question, IMHO, whether sibling navigation makes sense for Attributes,
but the *methods* make sense: it's just whether they should return another
Attribute in the list or else null.

I'll have to look at the code to remind myself of how this is going to affect the implementation. I think internally I depend pretty deeply on the difference between Node and TreeNode. It certainly can be fixed. It's just that this may not be as quick as changing howmanyChildren() to getChildCount()

That way you don't have to distinguish between containers and leaves when
just navigating, and Container is the proper home of addChild, getChildren,
and all those mutators.

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.

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.

You know, I wonder? Does Attribute deserve to be a Node at all? Would anything be lost if Attribute did not extend Node? It could still have all the methods. You just wouldn't be able to pass it to a function that expected a Node object.

Actually, I do know what this would screw up. It would be a royal pain for XPath, because location paths can return a node list that may contain elements, attributes, or both. If we don't make Attribute a subclass of Node, then we'll be back in the JDOM-world of lists of objects. Yuck. So Attribute has to be a Node. The question remains, is it worth distinguishing between Attribute nodes and all other nodes?

One advantage to not distinguishing (everything is a Node): when we do implement XPath then we can do more useful things with the contents of the NodeList the location path returns without casting, because the Node class has more methods.
--

+-----------------------+------------------------+-------------------+
| 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