On Thu, 2002-03-21 at 00:37, bob mcwhirter wrote:
> On 21 Mar 2002, David Peterson wrote:
>
> > Yeah, that would work, and it would be typesafe, but it is still going
> > to be quite inefficient.
>
> I agree 100%.
>
> I think we can have it both ways...
>
> public class XPath
> {
> public Navigator getNavigator(Object context)
> {
> // for each navigator, call isMyObjectModel( context )
> // doing the seek-the-right one.
> }
> }
>
> public class Dom4jXPath
> {
> public Navigator getNavigator(Object context)
> {
> return Dom4jNavigator.getInstance();
> }
> }
>
> This way, if you truly don't know at compile-time what your object-model
> is, then you get the benefit of the engine figuring it out for you.
>
> Else, if you want to do a compile-time bind, using a sub-class of XPath
> (Dom4jXPath, or org.jaxen.dom4j.XPath, whichever) to avoid the run-time
> instanceof checks.
I would suggest making org.jaxen.XPath abstract, and putting the
reflection-based implementation in a sub package
(org.jaxen.generic.GenericXPath ?) or at least a subclass
(org.jaxen.GenericXPath). It saves a bunch of code being loaded that may
not ever be used, as well as making org.jaxen.XPath more of a type than
a concrete object. The advantage of having it in a sub-package is that
you could then make it a separate module, ala 'jaxen-jdom.jar',
'jaxen-dom.jar', etc, for people who want to minimise their library
sizes. Not a big deal, though...
Oh, a quick PS on naming also - my personal preference would be for
OM-specific extensions to be named org.jaxen.dom4j.Dom4jXPath rather
than org.jaxen.dom4j.XPath for two main reasons. Firstly, if you have
included org.jaxen.dom4j.* as well as org.jaxen.XPath, you don't get
naming conflicts. Also, it is self-documenting, which is always a good
thing IMHO.
> > If Jaxen goes down the reflection path, then something along the lines
> > of your suggestion is probably the best option, but I don't really see
> > the value myself. With JDBC, the system is valuable because it allows
> > you to pretend that completely different DB systems all work in pretty
> > much the same way - no native interfaces required. When you execute a
> > JDBC query, you always get back a Recordset. But with Jaxen, the results
> > you get back from a query are completely different objects depending on
> > what OM you are using.
>
> I mostly agree. The exception would be where you never touch the object-model,
> because you're using something like an XSL engine that is object-model
> independent.
>
> XSLT transformer = new XSLT();
>
> transformer.transform( sourceDoc, styleDoc );
>
> Here, the engine could be completely universal, possibly.
>
> I'm not going to write it, so it's really not a valid use-case.
Yeah, I could see that. XML applications, or standards build on XML that
wish to be model-independent. For most things, though, I think the
Navigator interface would have to be made a bit more full-featured
though, anyway. In the case of XSLT, however, TrAX (Sun's standard Java
XSLT interfaces) already supports SAX, which is really the
lowest-common-denominator for parsers anyway. Although I note that JDOM
has a JDOMSource and JDOMResult object if you want it - I'm sure similar
constructs could be made for most object models.
> You're right that eventually you end up casting to a particular
> object-model in the common case.
>
> > Anyway, I'll go along with whatever the consensus is, but I'm yet to be
> > convinced of the value of a reflection-based system.
>
> I think that if we do reflection, we also need to be able to keep
> what we have, too. Reflection might make it easier for first-timers
> to start using the system. But we'll need a big-arse FAQ of
> "Why does selectNodes(...) take so darn long?"
Yep :)
David out...
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
