[jdom-interest] XPath class

[Laurent Bihanic]

Hi,

Hallvard Tratteberg wrote:
> I've been using XPath with JDOM for a while and I certainly find it very
> convenient for navigating in a document. In my XPath wrapper I've added
> caching of xpath expressions, to reduce the cost of using strings constants
> instead of Xpath fields. The idea is to lookup an expression string and
> return a prebuilt Xpath in case of match, or else create, cache and return
> an existing one:
> 
The problem here is that the class we provide shall not force applications to 
work one way or another: Some applications needs caching, others do not.

> Caching xpath objects loses if many expressions are dynamically generated,
> e.g. to handle different predicates. This can be handled by using xpath
> variables, e.g. use makeXPath("/game/thing[@owner=$playerId") instead of
> makeXPath("/game/thing[@owner='"+playerId+"']"). This requires a function
> for setting xpath variables, before the xpath is used for selecting nodes.

I agree, adding a method setVariable() is a good idea. We can even go one step 
further and offer a method getImpl() to give access to the underlying 
implementation for expert Jaxen users.

> I like the suggestion of having a separate class in a org.jdom.xpath
> package. It may however be better to define an xpath interface or abstract
> class and put implementation specific classes in specific packages, like
> org.jdom.xpath.jaxen for Laurent's code. Jaxen itself does it this way to
> interface to dom and jdom.
> 
Or we could simply add a static method newInstance(String) that relies on a 
property to decide which (sub-)class to instanciate.
This would be lighter that requiring application to first create a factory 
instance.

Laurent