you should do a redirect.
Because if i do a refresh of the browser with the form url in it
i think think the browser ask me do you want to resubmit it (and i guess
that is a post again??)
johan
On 5/14/07, Lowell Kirsh [EMAIL PROTECTED] wrote:
Hi, I'm not sure I understand what you just
But I want the browser to ask that, because a re-post is dangerous.
Perhpas the dangerous logic should be in the submission page instead
of the results page.
On 5/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
you should do a redirect.
Because if i do a refresh of the browser with the form
the way it works now, with a redirect after post, is that if you press
refresh there will be no repost. if they press the back button then they can
submit the form again.
without redirect the only difference is that refreshing the page that shows
after the form has been submitted will ask the
but you don't submit again because in the browser you never
have the url of the post (at least in the default settings of wicket)
because then we always do a redirect after post
johan
On 5/12/07, Lowell Kirsh [EMAIL PROTECTED] wrote:
why would you test for post in the resulting page?
The
Hi, I'm not sure I understand what you just said. I think I do have
the url of the post in my browser. That is, now that I have set
redirect=false, when you reload the results page, it will execute the
logic (with side effects) again. But I'm thinking perhaps I'm doing
this wrong.
Basically, I
I want some of my pages to be accessed programatically. Basically,
that page may be accessed as a 'web service'. So the same page may be
arrived at in 2 ways - the result of a form submission from another
page in the same app, or the result of a direct http connection. When
accessed as a web
