[jdom-interest] Node implementation

[Trimmer, Todd]

I am now submitting an implementation of JDOM with an underlying Node
interface to act as a base for the other content type classes.

It impacts pre-existing client code in a single place --
Element.getMixedContent().

Then why bother with it at all? To make it much, much easier for
subclassing, writing tree iterators, and visitors. This will help developers
extend JDOM beyond its core functionality.

The main objections against such an interface have been:
1) No way to properly abstract such broad differences between the content
types.
2) Pure Java strings are used for textual content.
3) No advantage will be gained from such an implementation.
4) JDOM will unneccessarily become more complicated -- it will be both hard
to use and hard to learn.


I am here to debunk these myths by backing my claims with source code. The
reasoning for why I did certain things in a certain way can be found in the
README.TXT in the attached zip file.

For those who never bother reading *ANY* README.TXT, let me reiterate the
following points, to avoid flames:
1) I was a bit sloppy in modifying parts of JDOM that are in need of a major
overhaul anyway, as documented in the TODO list. Because changes were going
to be made anyway, I took the liberty of exchanging code correctness for
quick delivery of this proof of concept.
2) I designed a quick and dirty Text node, solely for this proof. It plays
nice with all the pre-existing API that use String. A better Text design
will be needed later for XML 1.0 compliance.
3) I didn't modify org.jdom.output.* yet to handle Text.
4) Some of the names are silly (NodeX, goDown(), etc.), but can easily be
changed if we do decide Node is the way to go. I used NodeX instead of Node
for now, since I didn't want to fully qualify all instances of
org.w3c.dom.Node.

Please feel free to attack and question everything I did in this proof of
concept. If I can survive the onslaught, the idea of having a Node interface
can no longer be casually tossed aside....


Todd Trimmer

 <<src.zip>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: src.zip
Type: application/octet-stream
Size: 196913 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20010510/7f12831e/src.obj