that prevents that "do you want to post the form again?" dialog that happens when you use the back button to go back to a page that had a form you submitted.
-igor On Mon, Mar 17, 2008 at 9:00 PM, Matthew Young <[EMAIL PROTECTED]> wrote: > Does this stuff here prevent double submit? > > > http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/settings/IRequestCycleSettings.html > > "...so that not only form submits are shielded from the double submit > problem..." > > > > On Mon, Mar 10, 2008 at 6:56 AM, Joel Hill <[EMAIL PROTECTED]> wrote: > > > I'm trying to prevent the double submit problem, where the user clicks the > > submit button more than once causing a double post. > > > > I tried implementing the soluion suggested here: > > > http://www.nabble.com/Re%3A-double-form-submission-handling---p13850262.html > > > > The problem is if there's a validation error and the user gets sent back > > to the same page (without a call to setResponsePage), the page still > > registers as submitted, so when the user fixes the form and submits, it's > > stuck in the resubmit state (which in my case sends the user to an error > > page). I even have one page where I don't call setResponsePage on a > > successful submit, because it just returns to that same page after a submit > > because there's a lot of overhead in constructing the page the first time. > > I don't want the submit to take a long time. > > > > I tried resetting the submitted boolean during the submit process, but no > > matter where I could find to put that code, it always seems to get executed > > before the 2nd submit get processed by wicket. > > > > I'd prefer not to implment a javascript solution (e.g. disabling the > > submit button after the first click), becuase I think the soultion linked > > above lends itself better to reusability across any form. So is there any > > way to differentiate between a double submit situation, and simply not > > calling setResponsePage? Or is there anywhere in wicket I can reset the > > submitted flag AFTER the double submit has begun to process (I'd prefer not > > to implement an artificial timer to reset the flag after a hard-coded > number > > of seconds). Some point in the request cycle that occurs after the old > page > > is unloaded? > > > > Now that I think about it, maybe some ajax that fires on the onunload > > event would be appropriate here. I'll try that while I wait to see of > > anyone has any better suggestions. > > > > Thanks. > > > > Joel > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
