[jdom-interest] Content as a Text Node (was JDOM JSR)

[philip.nelson at omniresources.com]

> The Node (also known as NodeX) source code I submitted weeks ago does
> EXACTLY as described above: All the pre-existing String-based 
> API work the
> same even though Text objects are used internally; not to be 
> exposed until
> getMixedContent() is called.

that's good :-)

> Switches on CDATA will make the patterns harder to implement. 
> Does anyone
> see mixed content like "<element>text<![CDATA[more text]]>even more
> text</element>" ? Now THAT's funky!

I'm not convinced one way or the other on this issue.  Could somebody put
together some code samples that show consequences of either approach?

> From: Jason Hunter <jhunter at collab.net>
> ---------------------------------------
> The problem is that the number of methods which JDOM objects have in
> common or could have in common is close to zero. 

<snip>

> My implementation of Node has NO methods that do not make any 
> sense, for any
> subclass of Node. Document.getParent() will always return 
> null, but how can
> this be non-sensical?

No doubt you need some way to determine that you are are the beginning or
end of the line.  But Jason's point is still valid.  The more I dig into
this, the more I realize that forcing a common interface is not the best way
to do this.  The W3C Node interface had a very different reality than we
JDOMers have.  They had to assume that everything that you could do with xml
was possible to do through the org.w3c interfaces.  We don't have that
problem.  JDOM is able to not only use the native Collection apis, we can
use the overlooked feature of java called object orientation :-).  Whether
by subclassing or decorating, I can get exactly what I want.  With JDOM, we
can make it easy, well at least easier.

> deal was. At this point, anyone who vehemently believes 
> Attribute should be
> a  Node can only persuade me by sumbitting real code to show why.
> 
Here is a great  example of my point.  You may have no reason to include
attributes.  I may want that (give me a reference to an instance containing
text "foo").  If the built in version doesn't include it, I have to subclass
anyway.  I may as well subclass with the node interface I actually need.
Then, my iterator method can vary too.  I can allow the option of an
iterator based on an xpath expression or with xlink paths followed or who
knows what.

Your goUp is another example.  The base classes have getParent which returns
Element.  goUp returns NodeX.  If I wanted to extend my node interface and
use it without casting, goUp should now return my node classes but can't
because of signature problems, so now I have getParent, goUp and say goUpX.
What have I gained by having goUp?  My goUpX could have called getParent
itself.



> How about running some concrete tests on my concrete code :Þ

A possibility for the Text class.

> 
> 
> I'm surprised I have not received any feedback on my Node 
> implementation
> source code. I have a working sample of a NodeIterator and 
> NodeVisitor with
> that submission as well.

I know I appreciate your effort.  My own comments are suspect until I
actually try some of these things myself.  Plus, I think I we can do this
without modifying the core at all, except for the Text class.

> 
> Just remember, Node and Text might not affect 99% of what you 
> use JDOM for
> today, but they will allow programmers to extend JDOM from 
> its core in a
> much easier and flexible way. 

If there was enough of a common base, I would agree but....