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]

Reply via email to