cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: FIXME in IncludeTransformer [Was: Re: Adding Files to Subversion]
Date Mon, 27 Sep 2004 22:49:43 GMT
Pier Fumagalli wrote:

> On 27 Sep 2004, at 21:06, Vadim Gritsenko wrote:
>>> What about using a similar approach to generate the cache? I'll try 
>>> to set up a test environment and to give it a shot if you have 
>>> nothing against it!
>> Do you refer to the fact that it uses list of request parameters and 
>> its values as a cache key?
>> Yes, I'm against it. Request parameter in previous email was simply an 
>> example - it could be anything from the environment at large (== JVM 
>> where application is running + OS + ...).
> Yep... I see your point, you're 100% right...
>> Proper solution will be composed key similar to the composed validity 
>> in IncludeTransformer. This also can be made configurable: in simplier 
>> cases, you won't need aggregated key and can use transformer as it is 
>> now.
> I was thinking about one thing... The one thing that troubles us is the 
> "request". That introduce a degree of variability that (i don't know to 
> what degree), might be counter-productive to analyze and cache...
> What about if we were doing "subrequest"s, much like in Apache... I 
> mean, why making the "included" request inherit all the varible stuff? 
> Wouldn't it be simply easier to create a new request/response and start 
> from a clean status.
> Then we could re-create the request by something like:
> <incl:include src="proto://whatever">
>   <incl:param name="parameterName">value</incl:param>
> </incl:include>

Well, if the only thing which troubles you is request, then you can 
easily do this now with simple:

   <i:include src="cocoon://pipeline?param=value"/>

And be done with it. You won't need any changes in IncludeTransformer at 

Even better, I think you can implement a protocol which makes parameters 
of original request unavailable.

Unfortunately, this does not help with issue I'm having. In my case 
internal pipeline obtains everything it needs from environment on its 
own - this allows to create static URLs (like cocoon://user/country) 
which can be included into the CMSed content and these static URLs will 
generate appropriate (customized / personalized) content depending on 
current environment (session / cookies / virtual host / etc).

Same issue, IIUC, will also appear in block scenario, when interface to 
the skin block is fixed as set of block:skin:// URIs, and skin 
implementation can return personalized skin based on user preferences or 

So, how about doing it right the first time? ;-)


View raw message