On Thu, 2002-03-21 at 09:25, James Strachan wrote:
> ----- Original Message -----
> From: "bob mcwhirter" <[EMAIL PROTECTED]>
>
> Though I do like the idea of a generic XPath object too. The use case is
> JSTL (the JSP Standard Tag Library) which has a bunch of XPath related tags
> which are based on XPath. It would be really cool to have a flexible XPath
> implementation that could autodetect whether a JSP user was working with
> DOM, dom4j, EXML, JDOM et al - provided the performance overhead is pretty
> minimal.
That's a good example. I knew there was some reason this came up before
:) There are still going to be issues with actually using the results of
the XPath once it is returned, though. Though from memory, with the
JSTL, the result would just be used as a JavaBean, using other tags (eg
<jx:getProperty ...> etc).
> So we could have
>
> org.jaxen.BaseXPath
> org.jaxen.dom.XPath
> org.jaxen.dom4j.XPath
> org.jaxen.jdom.XPath
> etc.
>
> Then when folks are working with one model in their code they can use the
> import to denote which XPath object they use.
>
> Then if folks wanna be generic the can use (say)
>
> org.jaxen.generic.XPath
>
>
> BTW I find DOMXPath, Dom4jXPath, JDOMXPath idea all very ugly class names -
> I far prefer to use package names to namespace these things. The use of the
> name XPath for all different model-centric object is similar to most XML
> models naving an Element and Document type - they don't call them
> JDOMElement or DOMDocument etc.
My personal preference would be:
org.jaxen.XPath (abstract superclass)
org.jaxen.dom.DOMXPath
org.jaxen.dom4j.Dom4jXPath
etc...
or perhaps even
org.jaxen.XPath (interface)
org.jaxen.BaseXPath (abstract superclass)
org.jaxen.dom.DOMXPath
etc...
Then Jaxen could be used as follows:
import org.jaxen.*;
import org.jaxen.jdom.*;
//...
XPath xpath = new JDOMXPath("//foo/bar");
List nodes = xpath.selectNodes();
This follows the pattern established by the Collections API, where the
variable type is the interface (List, Map, Set), but the implementation
is concrete (ArrayList, LinkedList, etc). You could do the same thing
using BaseXPath, of course, but it just feels wrong...
I'll agree that the names don't render to be terribly attractive, but my
personal philosophy of design is that the top of the hierarchy should be
named for what it is - an XPath - and implementation-specific subclasses
should be descriptive. You wouldn't design an object hierarchy for
animals like the following:
org.nature.BaseAnimal;
org.nature.dog.Animal;
org.nature.cat.Animal;
org.nature.hippo.Animal;
That's just bizarre.
Each of the OM-specific implementations share most of their code - a
single method is overridden - so it makes sense that the superclass that
has all the methods that get used declared should be the primary
interface used on a daily basis. I wouldn't feel comfortable doing that
if its name was BaseXPath.
But maybe that's just me.
David
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
