Peter Hunsberger wrote:
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.
Program language wars are boring, you have to provoke in a less obvious
way if you want 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...
It far from solving everything, but puting cache awarness in the OM as I
sugested in the end of
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110984408327534&w=2
would simplify some cases at least.
<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...
Sure, a number of people me included, have suggested that XSLT based
templating would be much better. We are just waiting for someone who
thinks that it would be so good, that he/she finds it worthwhile to
spend *own* work on it ;)
/Daniel
