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 information? > > 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
