[jdom-interest] Common interface for "node" classes.

[Jason Hunter]

Brad's looking into something like this, but there are tricky pieces
everywhere.  detach() for example: if it returns a Node and people want
to do doc.addContent(something.detach()) then that would require doc's
addContent() took a Node so as to avoid the need for a cast.  But a
Document can't accept all styles of Node (no EntityRef/Text/CDATA) so
we'd end up moving what used to be a compile-time check into a runtime
check.

If it was easy, we'd have done it a long time ago.

-jh-

> "O'neil, Jerome" wrote:
> 
> I've been working with JDOM for creating object models for
> semi-complicated XML, and it's been great.  One of the smaller nits
> I'm constantly picking is the lack of a shared type for "node" classes
> like Element and Text.  Common tasks like getParent and detach should
> be specified by a common interface, say JDOMNode or some such thing.
> 
> For example...
> 
> // Methods of particular interest to Jerome for the
> // immediate future. :)
> interface JDOMNode{
>         public JDOMNode detach();
>         public Element getParent();
> }
> 
> class Element implements Serializable, Cloneable, JDOMNode{ .... }
> class Text implements Serializable, Cloneable, JDOMNode{ .... }
> 
> This would mean not having to check for explicit types before casting
> while iterating over child collections, which would be handy-dandy,
> IMO.  I know there was some brief discussion of this kind of thing in
> the list archives, but I don't know if anything was ever decided.  I
> know it starts to tinker with existing interfaces, but I think it's a
> good thing.
> 
> Polymorphism.  It's not just for breakfast anymore.
> 
> Thanks!
> 
> --
> Jerome O'Neil
> Sr. Software Engineer
> The Cobalt Group
> 206.219.8008