gmail used to disable the back button. Now they've hacked it to do the 'correct' thing. It is apparently browser dependent, however, as the back button still sends you to the previous SITE when using gmail in Safari. In firefox, they must be trapping the back button and sending an ajax request. Surely it must be possible to trap the back button and just do nothing with it, instead. I don't know the details, though.
Sending a redirect doesn't fix the back button behaviour. It can be useful to prevent reloads executing methods that aren't idempotent, since hitting reload won't cause the form to be reposted, but it doesn't impact the back button at all. I know dojo has some framework that allows you to place the request you just sent into a stack, and have the back button send that request as an asynch request. It would still be up to you to make sure your application can handle those requests correctly. I investigated a little, but found it kind of useless without built-in support for it in various tapestry components, since you have to manually manipulate a js datastructure with values that a tapestry application isn't often aware of, such as URL and query params. Maybe I just didn't do enough reading on the topic, since it wasn't functionality that was high on my hitlist, but it felt pretty awkward on first glance. --sam On 11/29/06, Daniel Tabuenca <[EMAIL PROTECTED]> wrote:
How does Tacos do it? I see the @DirtyFormWarning won't let you click the back button if you changed the form (It will popup a warning instead). I believe they use javascript with window.onbeforeunload event. Here is a link: http://www.webreference.com/dhtml/diner/beforeunload/bunload4.html Anyone know any reason why this wouldn't work? On 11/29/06, Cyrille37 <[EMAIL PROTECTED]> wrote: > Mats Henricson a écrit : > > 2. After a logout. We don't want our users to be able to use the back > > button > > to see the > > last page, from which he clicked the "Log out" link. We know that going > > somewhere > > from that brought back page would lead the user to the login page, but > > none the less, > > it would be bad enough, especially if it is done from a public > > terminal. > Hello, > > I've made a lot of search about this subject, but I did not find a > functionnal solution. > I've try many headers about cache expriation and so on, but no solution. > For example when I click the Back button on FireFox, it show me the page > and there is no access on the server, it is only a cache version of the > page. > > If you find http headers which make impossible for the webBrowser to go > back without talking with the server I'll give you all my love ! ;-) > It's a hard subject. > > Cyrille > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
