[jdom-interest] Common interfaces..

[James Strachan]

Hi Alex

From: "Rosen, Alex" <arosen at silverstream.com>
> > A few ideas for methods could be...
> >
> > * getParent()
> > * getDocument()
> > * accept(Visitor)
> > * return itself as a snippet of XML text.
> > * return the XPath 'string-value' of the node as per the XPath spec.
> > * return the XPath expression required to navigate to the node. (e.g.
> "foo/bar/@name")
> > * evaluate XPath expressions relative to the node.
>
> This is a good list - I didn't think there'd be that many.

Thanks. I learnt a lot from using JDOM, I hope maybe JDOM might find some of
the ideas in dom4j useful too.


> There are a few
> problems making this work in JDOM, though:
>
> - Currently, the XML outputting capability is in a separate class, and the
JDOM
> "nodes" don't know anything about it.

Is this a real problem? We're just talking about a helper method that makes
it easier for users.

I doubt anyone would mind coupling the org.jdom package implementation code
with a single class in org.jdom4.output. Its all core JDOM code anyway I'd
say. Would this coupling ever cause a real issue? If it does then maybe the
XMLOutputter should be moved to the org.jdom package?


> - Currently, the XPath support is in a whole separate project, and the
JDOM
> "nodes" don't know anything about it.

That doesn't meen to say you can't support the XPath concept of
'string-value' - its just a W3C specification that defines how to turn a
Node or NodeSet into a String representation.

Same goes for returning an XPath expression denoting the path to the node.
(A little like Swing's DefaultTreeModel's getPathToRoot()). Neither of these
require an XPath engine and are just helper methods for users. They do
become much more useful when you integrate XPath though.


> - Putting XPath in the interface would require that Attributes are nodes
but
> Entities and DocTypes aren't. Some people want a different list of what's
a
> node and what isn't.

I don't see why not. If an XML document is logically a tree of nodes, why
can't they implement Node interfaces?


> - What's the return type of getParent()? Is it Object, or is there a
second
> interface for something that can be either a Document or an Element?

Tricky one this. You could argue that getParent() should return a Branch
which is either an Element or a Document. (Or Object if you don't want
Element and Document to be polymorphic).

I went with getParent() being an Element and getDocument() returning the
Document. I'm not sure how useful it is saying that a root element has a
parent which is the document - it feels better to say the root element is
the element without a parent and all nodes have a document (when they are
part of an XML document, or no document if they are part of a fragment of
XML).


> - I'm not sure about the utility of the Visitor pattern - it seems overly
> complicated for what it's trying to do, especially with the pushes and
pops
> that Paul mentioned. I think there are much more straightforward ways of
> walking a tree, that are easier to understand.

Though you do end up with a lots of code like...

                if (node instanceof Element) {

                    ...
                }
                else if (node instanceof String) {

                    ...
                }
                else if (node instanceof CDATA) {

                    ...
                }
                else if (node instanceof Comment) {

                    ...
                }
                else if (node instanceof ProcessingInstruction) {

                    ...
                }
                else if (node instanceof Entity) {

                    ...
                }
                else if (node instanceof Namespace) {
                    ...
                }
                else {
                    ...
                }

which isn't terribly efficient or elegant. I actually went along with an
idea from DOM and added a

    int getNodeType()

method in dom4j's Node interface so an efficient, fast switch statement
could be used for traversal in circumstances where performance was an issue.


> - Most importantly, JDOM's use of Strings throws a wrench into any node
> interface plan.

Yes thats true. This could be the design decision that makes a Node
interface not quite fit with JDOM. I thought long and hard about this issue
also. I concluded that to use Strings internally and use lazy contruction to
create Text objects was fine, as it is to use lazy construction to avoid
creating unnecessary List objects.