Peter Hunsberger wrote: <snip/>
This is more of a RT than anything concrete for or against the ideas given so far.
As I follow this discussion it keeps striking me that we're more-or-less reinventing resolvers and sources at a slightly lower level. At one level, people need:
protocol://x/y/z
to resolve to some XML/SAX stream fragment. Now we want
module.x.y.z
to resolve to something that isn't always XML but can be used to create a SAX stream or can be traversed with some kind of expression language.
Sources are designed for giving access to streams (and due to eficciency reasons SAX streams) and the "object accessors" are intended to give access to script friendly POJOs. The streams and SAX streams are consumed by parsers or event handling code, while the POJOs are accessed by ELs and scripting languages that typically use reflection mechanisms. That is quite a large difference.
Even if there are similarities at a more abstract level I don't see what we would gain by trying to merge the concepts at the implementation level.
So on one hand, we've got source resolvers and xpath and on the other hand we've got factories (hidden or not) resolving to object modules and some expression languages.
I can't help but have the feeling that if XSLT was easy we wouldn't be having this discussion at all. Stefano once proposed an alternate XSLT syntax, but I think the issues of understanding a declarative language wouldn't go away.
XSLT is my number one tool for building Cocoon based webapps, so what you suggests certainly doesn't apply to me. IMO the main reason that we are not using XSLT for accessing object graphs is that current XSLT implementation not are particullary well suited for solving that task. XSLT as language could certainly be used for it, but the current implementations are specialized for being efficient for SAX inputs. And rather hard to use for anything else.
Personally, I wonder if any of what is being discussed is really necessary;
It should be clear be clear from this thread what use cases we have in mind. If you have better suggestions on how we can achieve them, please go ahead and tell us.
I'd love to see the Cocoon community put a stake in the ground and build a good set of XSLT authoring tools and XSLT function and document support capabilities and say "the way to data manipulation and transformation with Cocoon is XSLT!"
So would I. But my itch is not strong enough for actually make it happen, is yours?
Given that doesn't seem likely to happen,
You can make it happen if you want to.
I guess the only thing I can suggest here is that everyone should take a step back and make sure the existing Cocoon machinery for source resolving and xpath traversal isn't re-usable in some way before inventing anything new...
AFAIK there is no existing xpath traversal machinery in Cocoon that we could reuse. Part of the proposal is about having such a reusable EL mechanism based on the pluggable ELs from template, and about making the "script environment" more reusable.
/Daniel
