Don't ask me...I don't know how it works.
(yes...eventually taking you back to the context root :-)) -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 12:28 PM To: Struts Users Mailing List Subject: RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons? Thanks for that. Give one or two paragraph summary can or not? <ten-second-assesment> It stores a 'magic' number and each time the page is entered if you have the wrong magic number if will forward you, until eventually you reach the page your supposed to be on? </ten-second-assesment> -----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 00:10 To: 'Struts Users Mailing List' Subject: RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons? you might find a work-around using hidden fields, but I've attached the two classes that make it work. Hope it helps. -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 10:05 AM To: Struts Users Mailing List Subject: RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons? Would your solution work without the cookies (ie: just the JS)? (Im trying to avoid cookies if I can, though if I cant I wont be too worried). Any chance you could share your technique? -----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 20:04 To: 'Struts Users Mailing List' Subject: RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons? Ahhh yes, the bane of web app developers! I solved this problem with JavaScript and cookies - no browser back operations allowed! And spare me the "what if JavaScript is turned off" noise - it just doesn't happen in the REAL world. Mark -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 3:02 AM (Incidentally, using the browsers back button in such a case results in a rather bad case of server state confusion!) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>