Hi,
thanks for the reply and the suggestion.
However I'm not sure it'll work (or else I'm misunderstanding what you're
suggesting). As you said yourself, 'when the user hits back wicket will pull
the old page instance from the pagemap and rerender it'. In my limited
testing it seemed that when handling 'back' button Wicket would restore both
model state *and* page instance variables state to whatever it was when that
page was actually rendered. This means that any flag set after that page
(e.g. when handling the first post) will be null and void. Thus nothing will
prevent user from re-submitting that page again.
To be fair, I only tested without that header you're suggesting -- but I'm
unsure as to what that header would change, it should be roughly equivalent
to hitting F5 on the old page and it doesn't seem to change anything in how
Wicket handles back button.
Now on that tangent I really would love to know what kind of thingamajig
Wicket does to restore both model and instance variable state -- only
serialization comes to mind to be honest... Is it what really is happening?
Another thing is that I would love to avoid sticking 'double submit
prevention' code into each and every form. Considering the stuff Wicket
already does with back button support I assume there ought to be a
centralized place to detect that user has, in fact, used the back button, so
at least some form of generalized 'back button prevention' ought to be
possible. I'm just totally unsure as to where to look.
McIlwee, Craig wrote:
>
> As long as you prevent the browser from caching the page with the form
> (just the page itself, caching the resources is fine) then when the user
> hits back wicket will pull the old page instance from the pagemap and
> rerender it. That page instance is the same one that was used the first
> time, so its state will still be the same. Just set some flag when the
> user submits, and also check that flag when processing the form like this:
>
> onSubmit(...) {
> if (!submitted) {
> submitted = true;
> // do some stuff....
> } else {
> // redirect to another page
> }
> }
>
> Wicket does set some cache headers, but to disable it in FF we had to set
> 1 extra header. If you check the setHeaders method in WebPage you'll see
> that they set 3 headers I think and then there is one other header (must
> revalidate?) that they have commented out. That commented header did the
> trick for us. As for the redirect, you might be able to pull the 'last
> valid page' as you call it from the page map, not sure though.
>
> Craig
>
--
View this message in context:
http://old.nabble.com/What-happens-after-browser%27s-%27back%27-button--tp28149886p28162659.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
