cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: CachingURICoplet and cl:links caching too aggressively - possible fix?
Date Fri, 02 Apr 2004 12:21:10 GMT
Hi Jon,

you're suggested solution would work. But this would require that
you always use your new transformer in every place and be careful
when generating links.

In general, if you're using the CachingURICoplet you shouldn't
use the action-counter at all.

I think more and more while the action counter was a good idea,
it's better to disable the action-counter and replace it by a
component that forces the browser to reload the page when 
the back button is used.

> -----Original Message-----
> From: Jon Evans [] 
> Sent: Friday, April 02, 2004 1:58 PM
> To: Apache Cocoon
> Subject: CachingURICoplet and cl:links caching too 
> aggressively - possible fix?
> Hi,
> 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"
>           value="{@id}">
>    <xsl:value-of select="@id" />
> </cl:link>
> 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 page.
> Thougths?
> Jon

View raw message