Got mistake to fix. Instead this: > Michael Jouravlev wrote: > You can go with a more elaborate path to avoid problems with Back > button and implicit resubmits on page refresh. In this case you accept > an initial request, no matter GET or POST. Then you redirect to a > particular action processing the request. It changes the application > state and saves it in the session. Then you redirect to the same front > action.
must read: You can go with a more elaborate path to avoid problems with Back button and implicit resubmits on page refresh. In this case you accept an initial request, no matter GET or POST. Then you *forward* to a particular action processing the request. It changes the application state and saves it in the session. Then you *redirect* to the same front action. On 12/5/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Or the fourth option is to use framesets. Of course if you do this, with > any of these approaches, you'll be causing your users pain in that there > will be no way they can bookmark pages and the browser's Refresh option > will become useless (since it would just reload the front page, not the > page the user was currently on)... The remark about refresh is not true. Check any of my samples, for example, this one: http://superinterface.com/strutsdialog/crudactionlite.do Open in a new window, click on buttons, see how application reacts. Then notice is Back button enabled ;-) And, of course, you can refresh any view at any time. Why it should stop working? The state is kept on the server. You can leave the site and then type its address in the address bar and there you are again, in the same state on the same page. Michael. -- Struts Dialogs: code-behind for Struts http://struts.sourceforge.net/strutsdialogs/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
