On 2 Apr 2004, at 15:07, Carsten Ziegeler wrote:
This is the question to answer :) For portals (or any other application
where
the user can change the state), the back button is "evil". The user
minimizes
a coplet and then maximizes the coplet again. The state of the coplet is
managed on the server. Now the user clicks "back", he sees the coplet
minimized
and assumes that it is minimized now, but of course the server doesn't
know anything about it. And this is true for every state change. (Assume
an order form that the user sends twice because of using the back button
etc.)
That's why I always try to "disable" the back button so the user can never reach a broken state.
I understand now - yes, it makes sense to stop the back button from working.
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.
I've verified (with the Mozilla "Live HTTP Headers" module) that the three headers you added are being sent to the browser:
HTTP/1.x 200 OK Date: Fri, 02 Apr 2004 15:43:04 GMT Server: Jetty/4.2.14 (Mac OS X/10.3.3 ppc java/1.4.2_03) X-Cocoon-Version: 2.1.5-dev Transfer-Encoding: chunked Expires: Thu, 01 Jan 2000 00:00:00 GMT <== HERE Content-Type: text/html Cache-Control: no-cache <== HERE Pragma: no-cache <== HERE
However in Mozilla, Firefox, Safari and IE 5.2 (all Mac OS X) the back button still works - the browser displays the previous page and then is out of sync with the server state.
Does it work for you?
Cheers,
Jon
