> 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
