My idea was to implement DOM with a kind of proxy that would translate generic node navigation into bean calls through introspection. For example, calling Node.getChildNodes() would inspect the undelying bean, create a NodeList, cache it, and return it. It could be read-write, but for transformation I would only need to read beans.
I searched on the net for something that does it, and only found it as a "Low priority" task in the betwixt project.
betwixt was started by james strachan. that feature is one of james' itches (rather than mine - i'm more a SAX man) and isn't really essential to a full release. that's why it's a low priority. james has been busy (for quite some time) with new cool stuff like jelly. adding a thin DOM wrapper shouldn't be too difficult and i'll certainly help if someone wanted to volunteer to lead the effort :)
http://domify.sourceforge.net
This is exactly what you describe. It is actively used in production systems for XSL views by Maverick webapps (XSL becomes equivalent to JSP) , which was its original purpose. We split it out into its own project, however, because this tool obviously has many other uses.
It is somewhat-maintained; I have a few patches that I have been slacking on
applying, but otherwise the codebase hasn't changed much in a while. It
pretty much meets the needs of its userbase. If you would like to "take
over" the project I would be more than happy to give you the keys and help
out here and there.
Another similar project is JXV (the author wrote it before he found out about Domify): http://jxv.sourceforge.net. We experimented building a Maverick plugin for this but we discovered a fair number of bugs in JXV.
Personally, I have an active desire to see all of these tools converge
(domify, jxv, betwixt). How we do that or with what codebase I don't care.
I'm willing to contribute some effort and knowledge, but I don't have the
time to spearhead the process.
<random-disconnected-thoughts>
convergence would be good. would take effort, though. betwixt is immature but flexible and has a wider scope whereas domify seems to be stable and mature with quite a tight scope. would probably be easier to retrofit domify compatibility to betwixt than vice versa.
the core of betwixt are flexible and extensible xml-bean mapping rules. maybe jeff could tell me how domify handles this. if the mapping rules are not compatible then it might be possible to factor betwixt so that the rules are pluggable.
james wanted to do XSLT with java beans - so you can do live transformations of bean graphs. now that's really cool. i think that's where DOM comes into the big betwixt picture. you can do XSLT on SAX events (which betwixt produces ok) but the output is xml. with a DOM wrapper you could use XSLT to manipulate the beans directly.
progress on betwixt has been slow. refactoring to make to code more accessible to other coders is a priority (it takes a long time to understand the code at the moment and this means that the work has to be done by existing committers who don't have a whole lot of time/energy) but it's tough to work out the best way to do this.
i'd like to know what james thinks about this.
</random-disconnected-thoughts>
- robert
--------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
