cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Mayrhuber <>
Subject Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Date Mon, 05 Jul 2004 14:20:03 GMT
On Friday 02 April 2004 18:18, Jon Evans wrote:
> 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.
Anything new on this?
I've gotten the exactly same behaviour of broken page links after a
tab switch when using the CachingURICoplet.
I'm using cocoon-2.1.5 without the action-counter but with the 
no-client-caching EventAspect and with the CachingURICoplet.
The only way around broken site links is to rewrite them to use the bookmark 
feature, but that stops working as soon a form with a post request is used in 
a coplet.

Currently the events are generated like:
// Create a new jxpath event 
JXPathEvent event = new CopletJXPathEvent(cid, jxPath, link);
String uri = linkService.getLinkURI(event);

Would it help to generate two events, one jxpath event and one with the layout 

> 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

Btw. firefox-0.8 and IE6 still do not disable the back button.
Mozilla Live Headers outputs:

HTTP/1.x 200 OK 
X-Cocoon-Version: 2.1.5 
Cache-Control: no-cache, no-store, no-store 
Pragma: no-cache 
Expires: Thu, 01 Jan 2000 00:00:00 GMT 
Content-Type: text/html 
Transfer-Encoding: chunked 
Date: Mon, 05 Jul 2004 13:10:17 GMT 
Server: Apache-Coyote/1.1 

I guess the only option to be safe is to use
client side JavaScript.

Please, CC me directly because I'm only subscribed to dev-digest, or expect a 
delay of my response.

lg, Chris

View raw message