> I also share your appreciation of XPath (particularly being founder dom4j
> and cofounder of Jaxen ;-) though parsing a document via dom4j or JDOM then
> performing XPath expressions on it to figure out which Java Bean objects to
> construct may be a little too much for what digester is intended to b. I
> guess it all depends on the complexity of the mapping from XML to beans. If
> its fairly simple, then digester rocks as is. If its very complex then XPath
> comes into its own.
>
> James
>
Maybe you are right. And All I say is only speculation - don't have
real practice just combine the technologies I see together. On the
other hand it is becoming more and more commonplace to deploy really
big systems from not too simple xml file containing interrelated
elements (think of a heavy-weight ejb-jar). So sooner or later
we will need the knoledge of (J)DOM(4J), I think. And it'll be
their job t oremain small memory footprint/event based etc.
Can't be used SAXPath simply to parse XPAth expressions in the current
digester framework? And: wouldn't be worth to initialize digester
with a pluggable parser (so you could use what you need)? Just
speculating.
Incze
