Pier Fumagalli wrote:On 27 Sep 2004, at 21:06, Vadim Gritsenko wrote:Yep... I see your point, you're 100% right...
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 + ...).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...
Pier
smime.p7s
Description: S/MIME cryptographic signature
