On Sat, 05 Mar 2005 11:52:58 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > 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.
It's not so much a merge as a change in mind set: don't promote script access to POJO's at all; instead encourage production of XML via POJO wrappers feeding XSLT. > > 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. Hmm, I don't see this. Can you explain more what problems you run into? We build very complex graph resolution logic into XSLT. Properly used it seems much better than Java or a scripting language for graph traversal? (and I've written code in many, many languages over the years...) > > 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. Actually, the real underlying use-cases for script based EL's isn't really that clear. The best I can come up with is the conditional production of some XML/SAX fragment that is expensive to produce (so you want to avoid it if possible). Even then, I can't see a real reason why branching flow with EL works better than branching flow with conventional pipelines (and perhaps some I/O module replacement). Certainly Web services requires no POJO scripting, SAX production to a standard pipelines works just fine? (Though flow script helps). > > 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? Well, that's the thing; we already have this. You don't really have to add anything to Cocoon to make it happen... A POJOSource/Generator pair that took any random POJO and used introspection to generate a SAX stream might be fun, but I can't see the need; getting SAX out of any POJO isn't really hard. Having a said that, there are things that Cocoon could use to make this easier for the average user. We've got a solution that works for us. Unfortunately, our institution has a problem contributing directly to open source projects. Basically, we're non-profit and one of the ways we get funding is by licensing our innovations back to interested parties. As a result I've not had any luck getting permission to contribute directly back to any Open Source project. The best I can do is random code fragments in the mailing list and ideas... > > 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. I can't really see a good way to use the existing code base either, but I threw the idea out since there might be others who have more experience with the Cocoon internals who might think of something. -- Peter Hunsberger
