> I've recently rediscovered Jaxen and I love it!
Cool! Though, Ter probably wouldn't want to hear that. Jaxen
replaced an ANTLR-based parser with a hand-rolled one a while
ago, when we transitioned from werken.xpath to SAXPath/Jaxen.
> I'd propose that the base class itself be made generic. IOW,
>
> * combine JaXPah and BaseXPath
Yah. Right now, the division is pure to make testing certain
things easier, and implementation-agnostic.
> * rename BaseXPath to XPath (yes, another object named XPath, sigh)
Oh fnord. Too many XPaths. But, if we unify, it will be less of
an issue.
> * make it introspect on the parameter to figure out what type of
> Navigator to instantiate.
Yes, that was considered, and I still think its a Good Idea.
> Then a user could just do
>
> new XPath(expr).selectNodes(doc)
>
> where dom is either a DOM Document, or a JDOM document, or the
> equivalent from dom4j or the other one...
Definitely friendlier.
> As a bonus, you could make the base XPath store the navigator in an
> instance variable; this would remove one of the things I think is
> weird about the API -- its use of inheritance instead of simple
> delegation to support multiple Navigator types.
That was done for ease-of-use for the end-user. I figured that
it'd be easier if folks didn't have to work with a generic one
and install their own Navigator each time. Introspection
would resolve that problem, as you noted.
> Anyway, not a huge deal, just thought I'd share my sense of design
> aesthetics. I look at the code and see too many wrappers.
Other examples of too many wrapper?
> I like both these suggestions and I'd be willing to spend a little time
> refactoring to make it happen.
Hokie dokie. Let me get a little more of a handle on the documentation,
then I'll give you CVS commit privs, and let you rock'n'roll on these
changes. You're a jGuru, so I trust you. ;)
-bob
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
