cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] A Unified Environment Model?
Date Mon, 07 Mar 2005 20:55:58 GMT
Peter Hunsberger wrote:

>On Mon, 07 Mar 2005 20:56:42 +0100, Daniel Fagerstrom
><danielf@nada.kth.se> wrote:
>  
>
>>Peter Hunsberger wrote:
>>
>>    
>>
>>>On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
>>><danielf@nada.kth.se> 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



Mime
View raw message