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
