Yeah, that would work, and it would be typesafe, but it is still going
to be quite inefficient. Every time you call 'selectNodes()' or one of
it's siblings, the object being passed in has to be tested against each
of the registered Navigators, who in turn may perform up to 7
'instanceof's (depending on the object model) in order to determine
whether the object is supported. With the 4 currently supported models,
that means a worst case of 28 'instanceof' calls per call to
selectNodes() (sorry, can't calculate the mean - stats was never my
strong point). While it's not that expensive a call these days (I think)
and they happen all the time, it will add up pretty quickly if you get
into situations where you are looping through many XML docs (eg an XML
search engine or database), or performing multiple XPath queries on a
single doc, or both.
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. So you need to have knowledge of what OM you're
using anyway to make any use of the results. The use-cases where you
will want OM independence are going to be incredibly small, if not
non-existant (quick, someone prove me wrong :) ). I suppose you could
use the Navigator to perform some simple tasks, but there is currently
no support in that interface for modifying the contents of a Node, so it
will be read-only.
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.
David
On Wed, 2002-03-20 at 22:49, bob mcwhirter wrote:
> > Thirdly, and perhaps most critically, using reflection is not that
> > simple, and it means there are concrete (or at least masking-tape) links
> > between the core engine and the standard XML object models. To use
> > reflection, something will either have to map each specific Object in
> > the XML object model (eg. org.jdom.Document, org.jdom.Element, etc...)
> > to it's appropriate Navigator, or use the short-cut of mapping to the
> > package name rather than the specific classes (eg "org.jdom",
> > "org.w3.dom", etc). The former method is tedious, the latter dangerous
> > (it will allow inserting of other objects such as
> > "org.jdom.JDOMException"), and both are more inefficient.
>
> We could always take a page from JDBC.
>
> To 'register' your Navigator.
>
> Class.forName( "org.cheese.CheeseNavigator" );
>
> And, XPath.java could defer to each Navigator to test if the
> context is of its type.
>
> Basically:
>
> public class CheeseNavigator
> {
> static
> {
> NavigatorRegistrar.register( new CheeseNavigator );
> }
>
> public boolean isMyObjectModel(Object context)
> {
> if ( isElement( context ) || isAttribute( context ) .... )
> {
> return true;
> }
> }
> }
>
> isMyObjectModel(...) can be based entirely on the isFoo(..) methods
> and could probably just be implemented in DefaultNavigator. So,
> all each custom navigator would need is the static {} block.
>
> Users would either do the Class.forName(..) call, or we could go
> search out a jaxen.properties file (or both).
>
> -bob
>
>
> _______________________________________________
> Jaxen-interest mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jaxen-interest
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
