[jdom-interest] How to ease traversal of JDOM tree

[rpcee]

There are 2 options:
  1. use an interface based api such as dom4j or dom

  2. use decorators to provide interface functionality. This is covered in 
Java and XML, also the reasons why interfaces aren't used. Having seen how 
elegant and customisable the decorators are, I no longer see the need for 
interface approach.

Rich


>===== Original Message From Laurent Bihanic <laurent.bihanic at atosorigin.com> 
=====
>Hi,
>
>I just wrote my Nth implementation of traversal of a JDOM tree and I got
>tired of all these instanceof tests. So, I'd like to propose to introduce
>a minimum interface to ease the traversal of JDOM trees.
>
>The idea is to have a small interface all JDOM classes representing
>XML data (Document, Element, Attribute, Comment, Text..., except
>Namespace) would implement.
>
>This interface (let's call it Node) would only define the following
>methods:
>
>  Node addContent(Node)
>  boolean removeContent(Node)
>  List getContent()
>  Node setContent(List)
>
>  Object clone()
>  Node detach()
>
>  Document getDocument()
>
>  Element getParent()
>  Node setParent(Element)
>
>  String getText()
>
>  int getNodeType()
>
>clone, detach, get/setParent and getDocument are already defined by
>all JDOM "node" classes.
>
>add/remove/get/setContent are today only defined by Element and Document
>but should be defined in all classes if we want to be able to traverse
>the tree downward. The add/remove/setContent would then throw an
>exception while getContent could return either an empty List or a List
>containing a single Text object.
>
>Finally, getText returns text data from the leaf nodes (Attribute,
>Comment, PI, etc.). It can be mapped on the existing methods (getValue
>for Attribute, getText for Comment and CDATA, getData for PI...).
>
>To totally remove the need for instanceof, the method getNodeType(),
>returning an integer value, has been added to allow using switch() to
>apply type specific code.
>
>In the future, additional methods could be added to this Node interface
>for example XPath support (selectNodes) or to return the path of a Node from
>the document root (String getPath()).
>
>The main drawback of using this kind of interface is that some methods
>will return Node object instead of the object itself, hence not allowing
>to chain methods defined by the interface and methods specific to specific
>classes.
>On the positive side, this should help reduce the code size both in JDOM
>core and in applications.
>
>For Jason: My use cases are very simple: I'd like to be able to apply the
>same code on Document and Element objects to copy or move parts of a Document
>or Element children. I'd also like my objects to provide a single method
>regardless whether the processing starts on the document or on any element.
>
>Opinions?
>
>Laurent
>
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost
.com