cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: FIXME in IncludeTransformer [Was: Re: Adding Files to Subversion]
Date Mon, 27 Sep 2004 19:35:34 GMT
On 27 Sep 2004, at 20:17, Vadim Gritsenko wrote:
> Pier Fumagalli wrote:
>
> Sure. Problem is the following. Consider you have a pipeline 
> 'internal' which generates different responses depending on the value 
> of request parameter 'a':
>
>   <map:match pattern="internal">
>     <map:generate src="{request-param:a}.xml"/>
>     <map:serialize type="xml"/>
>   </map:match>
>
> Example request and responses:
>
>   Requesting /internal?a=one gives:
>     <one/>
>
>   Requesting /internal?a=two gives:
>     <two/>
>
>
> Now, let's aggregate this pipeline into another pipeline, 'external', 
> using Include transformer and input document like this:
>     <doc>
>       <i:include src="cocoon://internal"/>
>     </doc>
>
> Requesting 'external' pipeline *should* give following result:
>
>   Requesting /external?a=one should give:
>     <doc>
>      <one/>
>     </doc>
>
>   Requesting /external?a=two should give:
>     <doc>
>      <two/>
>     </doc>
>
>
> But, this does not happen. Response on the first request to the 
> 'external' pipeline will get cached, and all following requests will 
> get same cached response *regardless* of request parameter. This 
> happens because pipeline keys for "/external?a=one" and 
> "/external?a=two" do not differ, they are the same:
>
>   PK_G-file-doc.xml_T-I_S-xml
>
> (that's how pipeline key would look like if 'external' consists of 
> file generator / include transformer / xml serializer). This problem 
> can be solved by adding keys of included sources to the pipeline key - 
> same way as validity is assembled. In this example, key of the 
> 'internal' SitemapSource will be added, which is composed out of 
> source's system ID (cocoon://internal), and hash of the pipeline key 
> (which is different for /internal?a=one and /internal?a=two because it 
> contains name of the file to generate response from - one.xml or 
> two.xml). Resulting key then will be something like:
>
>   PK_G-file-doc.xml_T-I-cocoon://internal?pipelinehash=1234567890_S-xml

Have you seen my earlier commit of the "ResourceParameterGenerator" 
today? 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!

	Pier


Mime
View raw message