[
Lists Home |
Date Index |
Thread Index
]
Hi, Bill --
> I've been through a ton of DOM-in-Java programming in the last 12
> months. You learn early on to use XPaths where possible to keep the
> code flexible and clean. But one of the annoying about using XPath in
> Java is that it's all library specific. The last thing I want to have
> to do is go through all my code and replace Xalan stuff with Jaxen
> stuff or Jaxen stuff with DOML3 stuff.
It is possible, as you observe, to put the Xalan, Saxon, or Jaxen stuff
behind a clean interface and the Java type system. (There is also
JXPath.)
> So here's a proposed api:
> [SNIP]
> List match( Node target, String xpath, Map namespaces );
You'll also need to allow for variables to be set and for extension
functions to be configured. I haven't looked at the Jaxen API in a
while, but I recall it being minimal and general. Perhaps a first pass
would be to take the Jaxen APIs and then pull out a set of general
interfaces?
It is also useful to allow the first argument to be a Collection
instead of a Node only.
What about support for keys and ids?
> I don't ever seem to need the extra step of preparing an xpath object
> and applying it later to a Node. I also figure managing any expression
> caching and so on is a fun thing to do for the implementor but gorp
> for the user.
[G]ood [o]ld [r]aisins and [p]eanuts?
I'm on the other side of the fence, as are other people who use XPath
expressions for routing logic and similar repeated execution. Things
like keys and ids suggest that you want initialization and caching on a
per-document level.
Just some thoughts.
-- Paul
|
