cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [RT] A Unified Environment Model?
Date Mon, 07 Mar 2005 20:17:39 GMT
On Mon, 07 Mar 2005 20:56:42 +0100, Daniel Fagerstrom
<> wrote:
> Peter Hunsberger wrote:
> >On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
> ><> 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...


> >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... :-)


> >
> >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...


Peter Hunsberger

View raw message