Or is the only way to prevent the double-submit problem to use the
REDIRECT_TO_RENDER or REDIRECT_TO_BUFFER options (and therefore require
sticky load balancing)?
No, you can do whatever you like. Note that redirect-to-render should
work in a clustered environment as well, but would
ONE_PASS_RENDER is being used].
In both cases, if we subclass Form and hold state to track whether the form
has already been submitted once before, we can handle the problem the way
Igor suggested previously. Is that correct?
--
View this message in context:
http://www.nabble.com/double-form-submission
Sure. Use custom solutions, like the one Igor suggested.
I think I understand -- we can use exactly the same solution to the form
re-submit problem in the case of [a back-button navigation followed by a
form re-post] to solve the double-submit problem in the case of [a page
refresh after a
something wicket should
prevent. Because that could be valid for that application, a user
submit something then sees it made a mistake, presses back, corrects
it and submit again..
--
View this message in context:
http://www.nabble.com/double-form-submission-handling---tf4829048.html#a13850026
this message in context:
http://www.nabble.com/double-form-submission-handling---tf4829048.html#a13850026
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
prevent. Because that could be valid for that application, a user
submit something then sees it made a mistake, presses back, corrects
it and submit again..
--
View this message in context:
http://www.nabble.com/double-form-submission-handling---tf4829048.html#a13851026
Sent from
in this case?
Or is the only way to prevent the double-submit problem to use the
REDIRECT_TO_RENDER or REDIRECT_TO_BUFFER options (and therefore require
sticky load balancing)?
--
View this message in context:
http://www.nabble.com/double-form-submission-handling---tf4829048.html#a13851209
Sent from
Lets say that we wanted to do sophisticated clustering, so we use the
ONE_PASS_RENDER option. However, we still want to avoid the double-submit
problem. Is it possible? Is there a way the application can prevent it from
happening in this case?
Sure. Use custom solutions, like the one Igor
Yet another question...
Does wicket handles double form submission in anyway ? like if the user
clicks the back button where the previous page was a result of a form
submission, which could result in double form submission..OR otherwise
refreshes that page..
Yes, Wicket by default uses the
But a user can click the back button to go to the previous page with
the form and submit it again, but that isn't something wicket should
prevent. Because that could be valid for that application, a user
submit something then sees it made a mistake, presses back, corrects
it and submit again..
On Nov 18, 2007 2:55 AM, mfs [EMAIL PROTECTED] wrote:
Yeah that scenario still makes sense where the user goes to the form page
itself, but i was refering to the scenario where the user goes to the page
(with the back button) which got shown after form submission, as in that
case the browser
]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/double-form-submission-handling---tf4829048.html#a13818039
Sent from the Wicket - User mailing list archive at Nabble.com
this message in context:
http://www.nabble.com/double-form-submission-handling---tf4829048.html#a13816084
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
13 matches
Mail list logo
