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]
