[jdom-interest] XPath bindings?
jhunter at servlets.com
Tue Oct 16 15:51:40 PDT 2001
I agree with Phil pretty much down the line.
+1 on proceeding.
philip.nelson at omniresources.com wrote:
> > >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  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.
> To control your jdom-interest membership:
More information about the jdom-interest