cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Evans <>
Subject CachingURICoplet and cl:links caching too aggressively - possible fix?
Date Fri, 02 Apr 2004 11:57:47 GMT

I have a few CachingURICoplets which use cl:links to set various 
values.  The most common is a paging bar to page through data, similar 
to the Goooooooogle links at the bottom of the google results page.  
Each does something like:

<cl:link class="page" path="attributes/page"
   <xsl:value-of select="@id" />

That's an extract from one of my xslts, transforming <block> elements 
created by the filter transformer.

The problem is that once they are generated and cached, they only work 
once.  This is because they get transformed to a link that looks like 
portal?cocoon-portal-action=1&cocoon-portal-event=0 and the 
cocoon-portal-action number only works for the page it's generated on.

Now could someone please check my understanding of the way this works.  
The link as it is stated above works because when the CopletTransformer 
runs in the pipeline of the specific coplet, it knows the ID of the 
coplet so it can set up the events properly.

How about a change: we (I :-)) create a new transformer which runs in 
the coplet pipeline instead of the CopletTransformer.  It looks for 
cl:link elements which omit the coplet="CopletID" parameter, and adds 
the attribute, with the current coplet ID as the value.  At that point, 
the output xml of that particular coplet is saved in the cache with the 
cl:link tags still in place and unconverted.

Then we can run the CopletTransformer once in the final page pipeline, 
and it will convert all of the cl:link tags for all coplets in the 



View raw message