cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: FIXME in IncludeTransformer [Was: Re: Adding Files to Subversion]
Date Tue, 28 Sep 2004 08:37:13 GMT
On 27 Sep 2004, at 23:49, Vadim Gritsenko wrote:
> 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 all.

The only problem with it is the encoding of the URL, which I shall do 
in XSLT, somehow...

Parameters that might contain "weird" characters like "&" or "=" could 
be troublesome, while if explicitly included in elements, it would make 
our life easier...


View raw message