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 19:17:26 GMT
Pier Fumagalli wrote:

> On 27 Sep 2004, at 19:15, Vadim Gritsenko wrote:
>> Don' wonder; properties were missing.
> Cheeridos!


> Now, an annotated dump on the source tells me that you added the 
> following FIXME comment:
> 36336      unico     public Serializable getKey() {
>  47017 vgritsenko         // FIXME: In case of including "cocoon://" or 
> other dynamic sources
>  47017 vgritsenko         // key has to be dynamic.
>  47017 vgritsenko         return "I";
>  36336      unico     }
> Care to explain the problem? I need to have this working (somehow) and 
> have some time on my hands to spare and dedicate to the cause of 
> caching! :-P

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"/>

Example request and responses:

   Requesting /internal?a=one gives:

   Requesting /internal?a=two gives:

Now, let's aggregate this pipeline into another pipeline, 'external', 
using Include transformer and input document like this:
       <i:include src="cocoon://internal"/>

Requesting 'external' pipeline *should* give following result:

   Requesting /external?a=one should give:

   Requesting /external?a=two should give:

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:


(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:



View raw message