[jdom-interest] XPath bindings?

Jason Hunter 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 [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.
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

More information about the jdom-interest mailing list