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] > >
