Differences between revisions 2 and 3
Revision 2 as of 2006-07-19 21:52:19
Size: 1345
Comment:
Revision 3 as of 2009-09-20 23:12:36
Size: 1369
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
inline:whatsinyourwallet.gif {{attachment:whatsinyourwallet.gif}}
Line 24: Line 24:
inline:focuscamera.gif {{attachment:focuscamera.gif}}
Line 28: Line 28:
inline:danmcallister.gif {{attachment:danmcallister.gif}}

Work in progress!

The Back button issues are caused mainly by splitting state between client and server. If application allows to cache views, then when a user goes back in browser resource history, he sees a stale page. The state of this page does not correspond to state of the server anymore.

These are the choices to fight this problem:

  • Prohibit navigation with standard browser buttons;
  • Synchronize server to browser;
  • Synchronize browser to server;
  • Throw error and start with well-known "clean" point.

If server state has not been committed yet, it is possible to synchronize server to browser. This technique is used in now popular continuations approach. On the other hand, if server state has been committed, like after paying for the goods bought online, it is not possible to rollback server anymore and continuations technique falls flat.

On the other hand, synchronizing view with server is always possible.

Hall Of Shame

Web applications that do not support browser navigation properly, try to restrict users from using standard browser buttons. You do not want to build an application that does something like this:

whatsinyourwallet.gif

or this:

focuscamera.gif

or this:

danmcallister.gif

More Information

See also: BrowserBackAndSecurity

StrutsBackButton (last edited 2009-09-20 23:12:36 by localhost)