What happens after browser's 'back' button?

[Sergey Olefir <so...@gmail.com>]

Hi,

our first Wicket-based application is about to go into testing and I'm
feeling rather uncomfortable about the fact that I don't really
understand what happens when user uses browser's back button and then
submits some 'outdated' form. Can someone elaborate please on what
exactly happens when Wicket receives submit from the 'old' page?

On a more specific note, I will most probably need to block user from
submitting the same form more than once. E.g.:

- If I wanted to prevent user from using back button at all, how would
I determine that the incoming submit is from the 'old' page?

- If I determined that Wicket received submit from the 'old' page, how
would I send user back to the last 'valid' page they were on?

- If I wanted to detect that user submits the same form twice (without
necessarily blocking the back button in all cases), how would I go
about it? I suppose I could store something in Session to track which
forms were already submitted?

P.S. Sorry for kind of 'reposting' my previous question, but I'm
running out of time on this project and really would love to
understand how to properly handle browser's 'back' button...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: What happens after browser's 'back' button?

[Sergey Olefir <so...@gmail.com>]

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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: What happens after browser's 'back' button?

[Sergey Olefir <so...@gmail.com>]

Any suggestions as to where I should start looking (source code or otherwise)
to understand how Wicket actually handles back button?
-- 
View this message in context: http://old.nabble.com/What-happens-after-browser%27s-%27back%27-button--tp28149886p28179655.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org