[jdom-interest] XPath bindings?

[philip.nelson at omniresources.com]

> >It would provide you with the first one.  Not unlike 
> Element.getChild(...)
> >which provides only the first child with the matching name.
> >
> 
> There's no need for this. If somebody knows they only want 
> the first node in the  list, then they can append 
> [position()=1] or even just [1] to the end of the XPath 
> expression to get it. There's no need for a convenience 
> method to get the first node in a list here. It's completely 
> superfluous.

Not completely.  It would seem kind of silly to have an xpath statement with
[position()=1] and then have to retrieve it from a list anyway.

Element theNode = (Element)(selectNodes("/some/xpath[position()=1]").get(1))

compared to 

Element theNode = (Element) selectSingleNode("/some/xpath[position()=1]")

Notice also that the first statement could just as easily have had an xpath
that returned multiple nodes and then missed it because of selecting the
first one from the list.

This is also similar to sql statements where you use top or rowcount to when
you are only interested in a single element.

> 
> I'm more concerned, however, about programmers who aren't 
> completely comfortable with XPath. If somebody doesn't know 
> they want the first node in the list, but they do know they 
> want only a single node, they're likely to pick 
> getSingleNode() without giving it a lot of thought. They're 
> likely to be surprised by nulls that are returned when the 
> method doesn't return even a single node. They're likely to 
> miss data because they got a single node when what they 
> really needed was a list. I'm afraid this is going to lead to 
> misuse and misunderstanding of XPath. 

As pointed out, this is completely consistent within the JDOM api.
getChild("name") returns the first matching one or null if there is no
match.  getChildren returns a List, whether or not there was a match.  I
really can't remember anyone posting questions about this, so I have to
think that people "get" it.

I think that by wrapping Jaxen and SAXPath exceptions in JDOMException, we
would be consistent again by following the pattern we use in the builders to
isoloate SAX and DOM exceptions.  We can be completely isolated from Jaxen
but still take advantage of a very useful and often requested feature.

And, it will be easy to integrate.  Cool...  I do worry that the use of the
word "Node" will open a certain smelly can of worms.