RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-26 Thread James Higginbotham 

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?

2002-09-26 Thread Andrew Hill 

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

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?

2002-09-26 Thread Jacob Hookom 

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

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]>

[OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-26 Thread Dan Cancro 

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:   
For additional commands, e-mail:

RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-26 Thread James Higginbotham 

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]>

RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-26 Thread Andrew Hill 

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

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?

2002-09-26 Thread Jacob Hookom 

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

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]>

[OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-26 Thread Dan Cancro 

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?

2002-09-24 Thread Galbreath, Mark 

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?


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?


-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]>

RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-24 Thread Andrew Hill 

Thanks for that.

Give one or two paragraph summary can or not?


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?


-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?

2002-09-24 Thread Galbreath, Mark 

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?

2002-09-24 Thread Andrew Hill 

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?

2002-09-24 Thread Galbreath, Mark 

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:   
For additional commands, e-mail:

RE: [OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-24 Thread James Higginbotham 

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?

2002-09-23 Thread Andrew Hill 

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

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?

2002-09-23 Thread Jacob Hookom 

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

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]>

[OT][WORKFLOW] Any best practice for "back", "save", "continue" buttons?

2002-09-23 Thread Dan Cancro 

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: