[OT][WORKFLOW] Any best practice for back, save, continue buttons?
I'm thinking about a design where I maintain a URL stack in a session variable that stores where a user has been, so that clicking a back button (not the browser's) will take a user to the right place. It would work like this: Click a Continue button - Push a new URL onto the stack, and take the user to that page Click a Save button - Leave the stack alone, and return the user to the same page Click a Back button - Pop a URL from the stack and take the user to the URL on the top of the stack. Click a Done button - Clear the stack. This would happen when you click a link on a top nav bar or the finish button in a wizard, for example. These would be the basic types of navigation. The actual labels on the buttons or links could be whatever you want. For example, you could have a Continue button labeled Save that takes the user to another page. Has anyone tried something like this with good or bad results? Thanks, Dan -- To unsubscribe, e-mail: For additional commands, e-mail: tsdok
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Yeah, I used it in a login handler that I wrote for struts, where: If (not logged in) (push requested url on stack in session) ) login.jsp form hidden value = requestStack.first It's detailed in Java E-Commerce from Wrox publishing | -Original Message- | From: Dan Cancro [mailto:[EMAIL PROTECTED]] | Sent: Monday, September 23, 2002 8:43 PM | To: '[EMAIL PROTECTED]' | Subject: [OT][WORKFLOW] Any best practice for back, save, continue | buttons? | | I'm thinking about a design where I maintain a URL stack in a session | variable that stores where a user has been, so that clicking a back | button | (not the browser's) will take a user to the right place. It would work | like | this: | | Click a Continue button - Push a new URL onto the stack, and take the | user to that page | Click a Save button - Leave the stack alone, and return the user to | the same page | Click a Back button - Pop a URL from the stack and take the user to | the URL on the top of the stack. | Click a Done button - Clear the stack. This would happen when you | click a link on a top nav bar or the finish button in a wizard, for | example. | | These would be the basic types of navigation. The actual labels on the | buttons or links could be whatever you want. For example, you could have | a | Continue button labeled Save that takes the user to another page. | | Has anyone tried something like this with good or bad results? | | Thanks, | Dan | | -- | To unsubscribe, e-mail: mailto:struts-user- | [EMAIL PROTECTED] | For additional commands, e-mail: mailto:struts-user- | [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] tsdok -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Im using something a little more complex that is a bit similar. I store some information into a uniquely identified object in the session , this includes the ActionForm the user is currently editing a url to resume editing this, then I forward to another page where the user can edit something else (perhaps a detail record). The user can repeat this process to stack to any number of levels. When an operation is complete the user is returned to the form they were previously editing (the actionForm having been preserved in the session) to continue editing it in the state is was before they diverted. (Incidentally, using the browsers back button in such a case results in a rather bad case of server state confusion!) -Original Message- From: Jacob Hookom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 14:56 To: 'Struts Users Mailing List' Subject: RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons? Yeah, I used it in a login handler that I wrote for struts, where: If (not logged in) (push requested url on stack in session) ) login.jsp form hidden value = requestStack.first It's detailed in Java E-Commerce from Wrox publishing | -Original Message- | From: Dan Cancro [mailto:[EMAIL PROTECTED]] | Sent: Monday, September 23, 2002 8:43 PM | To: '[EMAIL PROTECTED]' | Subject: [OT][WORKFLOW] Any best practice for back, save, continue | buttons? | | I'm thinking about a design where I maintain a URL stack in a session | variable that stores where a user has been, so that clicking a back | button | (not the browser's) will take a user to the right place. It would work | like | this: | | Click a Continue button - Push a new URL onto the stack, and take the | user to that page | Click a Save button - Leave the stack alone, and return the user to | the same page | Click a Back button - Pop a URL from the stack and take the user to | the URL on the top of the stack. | Click a Done button - Clear the stack. This would happen when you | click a link on a top nav bar or the finish button in a wizard, for | example. | | These would be the basic types of navigation. The actual labels on the | buttons or links could be whatever you want. For example, you could have | a | Continue button labeled Save that takes the user to another page. | | Has anyone tried something like this with good or bad results? | | Thanks, | Dan | | -- | To unsubscribe, e-mail: mailto:struts-user- | [EMAIL PROTECTED] | For additional commands, e-mail: mailto:struts-user- | [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] tsdok -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Dan, I did something in the past related to this, before Struts was available (I think). It required new instances of an action to be created for each jump with return, which cluttered the session but enabled these actions to store state about the process. Anyway, the one thing I learned, no matter what approach I take, is that the state of where the user is - be it the page, step, next step, where you came from, etc. should be in the form as a hidden field (i.e. dealt with in request scope) whenever possible. This allows the server to always stay in sync with the user, no matter if they use the back button or open a new browser window and start a new wizard, since the previous form has its wizard state, such as its current page, in the HTML and not on the server side where it can get out of sync. Stacks on the server side are painful and never work, but lists with an index to the current location in the wizard that are always sent to the action in the request (via a hidden variable in the form) work best. HTH, James -Original Message- From: Dan Cancro [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 8:43 PM To: '[EMAIL PROTECTED]' Subject: [OT][WORKFLOW] Any best practice for back, save, continue buttons? I'm thinking about a design where I maintain a URL stack in a session variable that stores where a user has been, so that clicking a back button (not the browser's) will take a user to the right place. It would work like this: Click a Continue button - Push a new URL onto the stack, and take the user to that page Click a Save button - Leave the stack alone, and return the user to the same page Click a Back button - Pop a URL from the stack and take the user to the URL on the top of the stack. Click a Done button - Clear the stack. This would happen when you click a link on a top nav bar or the finish button in a wizard, for example. These would be the basic types of navigation. The actual labels on the buttons or links could be whatever you want. For example, you could have a Continue button labeled Save that takes the user to another page. Has anyone tried something like this with good or bad results? Thanks, Dan -- To unsubscribe, e-mail: mailto:struts-user- [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] tsdok -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT][WORKFLOW] Any best practice for back, save, continue buttons?
I'm thinking about a design where I maintain a URL stack in a session variable that stores where a user has been, so that clicking a back button (not the browser's) will take a user to the right place. It would work like this: Click a Continue button - Push a new URL onto the stack, and take the user to that page Click a Save button - Leave the stack alone, and return the user to the same page Click a Back button - Pop a URL from the stack and take the user to the URL on the top of the stack. Click a Done button - Clear the stack. This would happen when you click a link on a top nav bar or the finish button in a wizard, for example. These would be the basic types of navigation. The actual labels on the buttons or links could be whatever you want. For example, you could have a Continue button labeled Save that takes the user to another page. Has anyone tried something like this with good or bad results? Thanks, Dan -- To unsubscribe, e-mail: For additional commands, e-mail: tsdok -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Yeah, I used it in a login handler that I wrote for struts, where: If (not logged in) (push requested url on stack in session) ) login.jsp form hidden value = requestStack.first It's detailed in Java E-Commerce from Wrox publishing | -Original Message- | From: Dan Cancro [mailto:[EMAIL PROTECTED]] | Sent: Monday, September 23, 2002 8:43 PM | To: '[EMAIL PROTECTED]' | Subject: [OT][WORKFLOW] Any best practice for back, save, continue | buttons? | | I'm thinking about a design where I maintain a URL stack in a session | variable that stores where a user has been, so that clicking a back | button | (not the browser's) will take a user to the right place. It would work | like | this: | | Click a Continue button - Push a new URL onto the stack, and take the | user to that page | Click a Save button - Leave the stack alone, and return the user to | the same page | Click a Back button - Pop a URL from the stack and take the user to | the URL on the top of the stack. | Click a Done button - Clear the stack. This would happen when you | click a link on a top nav bar or the finish button in a wizard, for | example. | | These would be the basic types of navigation. The actual labels on the | buttons or links could be whatever you want. For example, you could have | a | Continue button labeled Save that takes the user to another page. | | Has anyone tried something like this with good or bad results? | | Thanks, | Dan | | -- | To unsubscribe, e-mail: mailto:struts-user- | [EMAIL PROTECTED] | For additional commands, e-mail: mailto:struts-user- | [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] tsdok -- 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]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Im using something a little more complex that is a bit similar. I store some information into a uniquely identified object in the session , this includes the ActionForm the user is currently editing a url to resume editing this, then I forward to another page where the user can edit something else (perhaps a detail record). The user can repeat this process to stack to any number of levels. When an operation is complete the user is returned to the form they were previously editing (the actionForm having been preserved in the session) to continue editing it in the state is was before they diverted. (Incidentally, using the browsers back button in such a case results in a rather bad case of server state confusion!) -Original Message- From: Jacob Hookom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 14:56 To: 'Struts Users Mailing List' Subject: RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons? Yeah, I used it in a login handler that I wrote for struts, where: If (not logged in) (push requested url on stack in session) ) login.jsp form hidden value = requestStack.first It's detailed in Java E-Commerce from Wrox publishing | -Original Message- | From: Dan Cancro [mailto:[EMAIL PROTECTED]] | Sent: Monday, September 23, 2002 8:43 PM | To: '[EMAIL PROTECTED]' | Subject: [OT][WORKFLOW] Any best practice for back, save, continue | buttons? | | I'm thinking about a design where I maintain a URL stack in a session | variable that stores where a user has been, so that clicking a back | button | (not the browser's) will take a user to the right place. It would work | like | this: | | Click a Continue button - Push a new URL onto the stack, and take the | user to that page | Click a Save button - Leave the stack alone, and return the user to | the same page | Click a Back button - Pop a URL from the stack and take the user to | the URL on the top of the stack. | Click a Done button - Clear the stack. This would happen when you | click a link on a top nav bar or the finish button in a wizard, for | example. | | These would be the basic types of navigation. The actual labels on the | buttons or links could be whatever you want. For example, you could have | a | Continue button labeled Save that takes the user to another page. | | Has anyone tried something like this with good or bad results? | | Thanks, | Dan | | -- | To unsubscribe, e-mail: mailto:struts-user- | [EMAIL PROTECTED] | For additional commands, e-mail: mailto:struts-user- | [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] tsdok -- 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]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Dan, I did something in the past related to this, before Struts was available (I think). It required new instances of an action to be created for each jump with return, which cluttered the session but enabled these actions to store state about the process. Anyway, the one thing I learned, no matter what approach I take, is that the state of where the user is - be it the page, step, next step, where you came from, etc. should be in the form as a hidden field (i.e. dealt with in request scope) whenever possible. This allows the server to always stay in sync with the user, no matter if they use the back button or open a new browser window and start a new wizard, since the previous form has its wizard state, such as its current page, in the HTML and not on the server side where it can get out of sync. Stacks on the server side are painful and never work, but lists with an index to the current location in the wizard that are always sent to the action in the request (via a hidden variable in the form) work best. HTH, James -Original Message- From: Dan Cancro [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 8:43 PM To: '[EMAIL PROTECTED]' Subject: [OT][WORKFLOW] Any best practice for back, save, continue buttons? I'm thinking about a design where I maintain a URL stack in a session variable that stores where a user has been, so that clicking a back button (not the browser's) will take a user to the right place. It would work like this: Click a Continue button - Push a new URL onto the stack, and take the user to that page Click a Save button - Leave the stack alone, and return the user to the same page Click a Back button - Pop a URL from the stack and take the user to the URL on the top of the stack. Click a Done button - Clear the stack. This would happen when you click a link on a top nav bar or the finish button in a wizard, for example. These would be the basic types of navigation. The actual labels on the buttons or links could be whatever you want. For example, you could have a Continue button labeled Save that takes the user to another page. Has anyone tried something like this with good or bad results? Thanks, Dan -- To unsubscribe, e-mail: mailto:struts-user- [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] tsdok -- 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]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Yeah, I used it in a login handler that I wrote for struts, where: If (not logged in) (push requested url on stack in session) ) login.jsp form hidden value = requestStack.first It's detailed in Java E-Commerce from Wrox publishing | -Original Message- | From: Dan Cancro [mailto:[EMAIL PROTECTED]] | Sent: Monday, September 23, 2002 8:43 PM | To: '[EMAIL PROTECTED]' | Subject: [OT][WORKFLOW] Any best practice for back, save, continue | buttons? | | I'm thinking about a design where I maintain a URL stack in a session | variable that stores where a user has been, so that clicking a back | button | (not the browser's) will take a user to the right place. It would work | like | this: | | Click a Continue button - Push a new URL onto the stack, and take the | user to that page | Click a Save button - Leave the stack alone, and return the user to | the same page | Click a Back button - Pop a URL from the stack and take the user to | the URL on the top of the stack. | Click a Done button - Clear the stack. This would happen when you | click a link on a top nav bar or the finish button in a wizard, for | example. | | These would be the basic types of navigation. The actual labels on the | buttons or links could be whatever you want. For example, you could have | a | Continue button labeled Save that takes the user to another page. | | Has anyone tried something like this with good or bad results? | | Thanks, | Dan | | -- | To unsubscribe, e-mail: mailto:struts-user- | [EMAIL PROTECTED] | For additional commands, e-mail: mailto:struts-user- | [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Im using something a little more complex that is a bit similar. I store some information into a uniquely identified object in the session , this includes the ActionForm the user is currently editing a url to resume editing this, then I forward to another page where the user can edit something else (perhaps a detail record). The user can repeat this process to stack to any number of levels. When an operation is complete the user is returned to the form they were previously editing (the actionForm having been preserved in the session) to continue editing it in the state is was before they diverted. (Incidentally, using the browsers back button in such a case results in a rather bad case of server state confusion!) -Original Message- From: Jacob Hookom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 14:56 To: 'Struts Users Mailing List' Subject: RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons? Yeah, I used it in a login handler that I wrote for struts, where: If (not logged in) (push requested url on stack in session) ) login.jsp form hidden value = requestStack.first It's detailed in Java E-Commerce from Wrox publishing | -Original Message- | From: Dan Cancro [mailto:[EMAIL PROTECTED]] | Sent: Monday, September 23, 2002 8:43 PM | To: '[EMAIL PROTECTED]' | Subject: [OT][WORKFLOW] Any best practice for back, save, continue | buttons? | | I'm thinking about a design where I maintain a URL stack in a session | variable that stores where a user has been, so that clicking a back | button | (not the browser's) will take a user to the right place. It would work | like | this: | | Click a Continue button - Push a new URL onto the stack, and take the | user to that page | Click a Save button - Leave the stack alone, and return the user to | the same page | Click a Back button - Pop a URL from the stack and take the user to | the URL on the top of the stack. | Click a Done button - Clear the stack. This would happen when you | click a link on a top nav bar or the finish button in a wizard, for | example. | | These would be the basic types of navigation. The actual labels on the | buttons or links could be whatever you want. For example, you could have | a | Continue button labeled Save that takes the user to another page. | | Has anyone tried something like this with good or bad results? | | Thanks, | Dan | | -- | To unsubscribe, e-mail: mailto:struts-user- | [EMAIL PROTECTED] | For additional commands, e-mail: mailto:struts-user- | [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]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
Dan, I did something in the past related to this, before Struts was available (I think). It required new instances of an action to be created for each jump with return, which cluttered the session but enabled these actions to store state about the process. Anyway, the one thing I learned, no matter what approach I take, is that the state of where the user is - be it the page, step, next step, where you came from, etc. should be in the form as a hidden field (i.e. dealt with in request scope) whenever possible. This allows the server to always stay in sync with the user, no matter if they use the back button or open a new browser window and start a new wizard, since the previous form has its wizard state, such as its current page, in the HTML and not on the server side where it can get out of sync. Stacks on the server side are painful and never work, but lists with an index to the current location in the wizard that are always sent to the action in the request (via a hidden variable in the form) work best. HTH, James -Original Message- From: Dan Cancro [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 8:43 PM To: '[EMAIL PROTECTED]' Subject: [OT][WORKFLOW] Any best practice for back, save, continue buttons? I'm thinking about a design where I maintain a URL stack in a session variable that stores where a user has been, so that clicking a back button (not the browser's) will take a user to the right place. It would work like this: Click a Continue button - Push a new URL onto the stack, and take the user to that page Click a Save button - Leave the stack alone, and return the user to the same page Click a Back button - Pop a URL from the stack and take the user to the URL on the top of the stack. Click a Done button - Clear the stack. This would happen when you click a link on a top nav bar or the finish button in a wizard, for example. These would be the basic types of navigation. The actual labels on the buttons or links could be whatever you want. For example, you could have a Continue button labeled Save that takes the user to another page. Has anyone tried something like this with good or bad results? Thanks, Dan -- To unsubscribe, e-mail: mailto:struts-user- [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]
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]
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]
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] afterPage.js Description: Binary data beforePage.js Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
RE: [OT][WORKFLOW] Any best practice for back, save, continue buttons?
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]
[OT][WORKFLOW] Any best practice for back, save, continue buttons?
I'm thinking about a design where I maintain a URL stack in a session variable that stores where a user has been, so that clicking a back button (not the browser's) will take a user to the right place. It would work like this: Click a Continue button - Push a new URL onto the stack, and take the user to that page Click a Save button - Leave the stack alone, and return the user to the same page Click a Back button - Pop a URL from the stack and take the user to the URL on the top of the stack. Click a Done button - Clear the stack. This would happen when you click a link on a top nav bar or the finish button in a wizard, for example. These would be the basic types of navigation. The actual labels on the buttons or links could be whatever you want. For example, you could have a Continue button labeled Save that takes the user to another page. Has anyone tried something like this with good or bad results? Thanks, Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
