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]