As far as I remember, everything should work :) There are two things you should consider when writing your coplets:
The cocoon portal provides all required functionality for forms (POST and GET) and flow including the caching. For this you should use the html event link transformer. Examples are the calculator and the application coplet in the cocoon portal demo. [http://cocoon.apache.org/2.1/developing/portal/forms.html] The final step, converting the events to links should not be done in the pipelines of your coplet but in the main pipeline rendering your portal. So on each request the events are transformed into new links and although the content of the coplet is cached, the links still work. The current portal demo works exactly this way. The portal currently does not really "disable" the back button, the user can still click on it. But in this case, the page is reloaded and the user gets a fresh view of the portal. Please note also that the html event link transformer has a serious bug in 2.1.5 which is fixed in the current head of CVS. HTH Carsten > -----Original Message----- > From: Christian Mayrhuber [mailto:[EMAIL PROTECTED] > Sent: Monday, July 05, 2004 4:20 PM > To: [EMAIL PROTECTED] > Subject: Re: CachingURICoplet and cl:links caching too > aggressively - possible fix? > > 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 > >
