cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Evans <jon.ev...@misgl.com>
Subject Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Date Fri, 02 Apr 2004 16:18:05 GMT
Hi Carsten,

On 2 Apr 2004, at 15:07, Carsten Ziegeler wrote:

> The action-counter in the portal was thought to be the solution to get 
> this
>  fixed in a nice way. But actually this solution is too error prone and
> causes too many problems. I just updated the CVS with a better 
> solution.
> When the user now clicks the back button a new request is send to the
>  server, and the user sees exactly the same state as the page before. 
> So,
>  the user never gets into a broken state which is imho very important 
> for
>  web applications.

Just tried it out with my site.

Even without the action counter, it seems that a cached cl:link will 
still only work once.  e.g. a page is generated with my 
CachingURICoplet on it, the coplet has a link for page 2 which works.  
If I click another tab then clickto go back to the first page, the page 
links in my coplet don't work any more.  I'm assuming that the portal 
generates all the cocoon-portal-event=n numbers starting at 1 each 
time, and the number that my coplet got is no longer valid.

Yes, just verified it.  The links get numbered off from 1 as they are 
processed, the second time the page loads my coplet comes from the 
cache, so its links don't get processed.  Some other coplet gets the 
event numbers that were already cached by my coplet, so the links in my 
coplet end up firing the same event as the unrelated links in the other 
coplet.

So back to my earlier plan, I think it would be better if there was a 
transformer in the pipeline of each coplet which just made sure that 
coplet="copletid" was added to each cl:link tag, then run the whole 
page through the portal-coplet transformer before it is served to the 
browser.

Jon


Mime
View raw message