I just thought I'd run this idea past the list to see what people thought.
Introducing XPathFactory ================== Right now using the Jaxen API things are as follows XPath xpath = new FooXPath( "/x/y/z" ); // maybe set a VariableContext // maybe add some namespace prefix <-> URI mappings via a NamespaceContext // maybe tinker with the function context List answer = xpath.selectNodes( something ); Typically folks are going to be evaluating lots of XPath expressions which will typically have the same VariableContext, FunctionContext and frequently share a similar NamespaceContext too. So rather than having reams of code to set these 3 contexts up I thought this might be a good use case for the Factory pattern. XPathFactory factory = new MyFooXPathFactory(); // configure the factory once to set variable, namespace & functions // then share it across XPath invocations then whenever we wish to perform an XPath evaluation its XPath xpath = factory.createXPath( "/x/y/z" ); List answer = xpath.selectNodes( document ); XPath xpath2 = factory.createXPath( "/a/b/c" ); List answer = xpath2.selectNodes( document ); Another neat thing about the above change is that the code now becomes totally polymorphic, it doesn't matter what the object model is, the code is identical. i.e. there's no DOMXPath / Dom4jXPath / JDOMXPath in the code. The only line of code that is model specific is the one line of code that actually instantiates the XPathFactory. This would also allow us to easily switch in or out the 'GenericXPath' concept if we wish by just using a different XPathFactory implementation.. I think it should be possible to quite easily implement a GenericXPath implementation that is pretty fast; caching the Navigator instances required keyed on the node implementation class - so deducing the Navigator to use for an object could be as fast as a HashMap lookup. Though in a DOM or dom4j or JDOM component, doing this lookup for every XPath is kinda unnecessary - so I think we should support both specific and generic XPath objects The XPathFactory mechanism could allow us to make a CachingXPathFactory facade which adds pooling and / or caching of XPath expressions (across all XPath implementations) which could really boost performance in cases where common XPath expressions are parsed many times. How useful is it? =========== I guess developers can build their own factories anyways or maybe use the Abstract Factory Method pattern in their own code. So I'm not totally convinced we need to add this to the Jaxen API but it could well encourage a cleaner use of XPath. Also having a common caching mechanism that can be shared across models seems like it might be a good idea. Model specific factories ================ For dom4j users all this is a fairly mute point anyways, there is an existing factory of XPath objects in the dom4j API. Document doc = ...; List anwer = doc.selectNodes( "/foo/bar" ); or XPath xpath = doc.createXPath( "/a/b" ); List answer = xpath.selectNodes( doc ); The magic all happens in dom4j's DocumentFactory so thats a central place where folks can set up their variable, namespace and function contexts. So maybe EXML / JDOM users could do similar things, have their own kind of XPathFactory. DOM 3 has a kind of XPath factory API already which could technically be adapted on top of Jaxen though I'm not sure if its worth it; its the use of Java 2 Collections that makes using Jaxen nice and simple.. What are others thoughts on this? Is the XPathFactory interface worth the effort? JDOM folks seem to like using the new operator ;-) so might well be against it. If so I'm happy to punt on it for now, its mostly for DOM / EXML / JDOM users anyways but do you think it would be useful? James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
