On Mon, 07 Mar 2005 20:56:42 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > Peter Hunsberger wrote: > > >On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom > ><[EMAIL PROTECTED]> wrote: > > > > > >>Peter Hunsberger wrote: > >> > <snip/> > > >That's not a use case, that's a technical usage example (at best). > >We've already got unified access to environment data like the request > >object. For example, the RequestGenerator... > > > You can use the RequestGenerator for accessing request data in a > pipeline, but you can't use it (in an efficient way) for accessing > request data in the sitemap, or in flowscripts, or in templates (for > those who don't like XSLT).
Umm, that's what I meant by putting a stake in the ground: if they don't like XSLT too bad.... I'm somewhat surprised that I haven't seen more push back or out right flames. Maybe everybody else is just used to ignoring me... <snip>more or less common ground</snip> > > > In most webapps it is the backend rather than the Cocoon web gui that is > the limiting factor. But in some applications Cocoon prestanda counts as > well, so it seem reasonable that we care about it. Yes, I agree on both counts. The back end is where we have our major performance concerns. You've got to watch what you do in Cocoon, but if you're careful it's not a problem. What can I say: caching, caching and more caching. Stefano's comment that caching is rarely done right in Cocoon seems relevant: you want to solve a big Cocoon problem? Make caching work in some intuitive out of the box fashion for everything... <snip/> > >AFAIK Saxon doesn't create a DOM model in a pure SAX XSLT pipeline ??? > > > It creates a DOM like internal model. But that wasn't what I discussed, > the main thing is that Xalan and Saxon, AFAIK don't are particullary > efficient when you have DOM input. Just avoid DOM input... :-) <snip/> > > > >I'd still like to see some real use cases .... > > > 1. Making it easier to learn Cocoon for new users by providing *one* OM > that is used everywhere, instead of having one style from input modules, > another in flowscript, still another through the > RequestTemplateGenerator, still another in XSP and so on. Ok, use XSLT. (period). Problem one solved.... > > 2. Making it easier to maintain and develop Cocoon by providing a common > mechanism, tools, APIs for something that is used in many places within > Cocoon and hasn't been standardized yet. Ok, use XSLT. (period). Problem two solved.... > You are not going to be able to do something new that wasn't possible > before. Less facetiously: I think standard object models are good. Yet another templating language? That's when I think pushing XSLT more might start to make sense... <snip/> -- Peter Hunsberger
