Not 100% sure, but you could implement a NoDoubleSubmitForm with a couple of tweaks:
<form ...> <input type="hidden" wicket:id="submitNr" /> .... </form> class NoDoubleSubmitForm { private int submitNr; NoDoubleSubmitForm(String id, IModel model) { super(id, model); add(new HiddenField("submitNr", new Model(submitNr)).add(new AbstractValidator() { boolean validate() { return submitNr == input; } ); } public void onSubmit() { submitNr++; } } It needs some refining, but this should prevent a double submit from happening (the validation fails for the second submit). Martijn On 3/10/08, 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] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]