Javascript solution is a good catch all - but I wasn't confident or happy just with relying on front end tricks. What' I've done, is very simple. I re-wrote the Form component. In the form component, there is a persistent Hashtable property that stores a user's session id and page name (this gets around page recorder errors). Before the listener is 'triggered', we:
* lock * execute listener * in a finally block, we unlock. This not only works in blocking multiple submits, but it also prevents the user from visiting the submitting page in the event of a looooooooooooooooong transaction (as is in our case). This new Form component must implement PageRenderListener and implement pageBeginRender to check the locked condition. The same goes for prepareForRender. Finally, for sanity - we check the lock condition before locking. This may not be necessary, but it works for me! Also - what does the lock check do? It throws a well known exception that you can handled by overriding BaseEngine's 'activateException'. Hope this helps! On 9/8/05, Velarde, Domonic R. - WMD <[EMAIL PROTECTED]> wrote: > > I have a similar situation. Though I am opting to go for the simpler > solution and use JavaScript to disable the submit button after the user > presses it. Can any one show what the JavaScript looks like? I found > many reference to how but when attempting it does not work. The page > hangs. > Here is sample code of what I have been trying: > > <input type="submit" jwcid="@Submit" value="message:button-proceed" > listener="ognl:listeners.submit" onClick="this.disabled=true;"/> > > It will grey out the button, which is what I want, but then it hangs > does and does not go to the next page. > > Any help much appreciated. > > -----Original Message----- > From: Patrick Casey [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 30, 2005 6:15 PM > To: 'Tapestry users' > Subject: RE: Preventing multiple form submission within Tapestry > > > This ought to work: > > Step 1: Synchronize your servlet.doService() on the HttpSession > so > that two user requests will never run in parallel. > Step 2: Add a hidden, monotonically increasing (like a static > incrementer) hidden value to the form in question. > Step 3: Add a LinkedHashMap to your Visit object called > "LastFiveSubmits". Set its removeOldest() to remove if the map size > 5. > Step 4: When you get a "submit" request, check and see if you're > already handled a submit for this form in, say, the last 5 interactions. > If > not, handle the submit, and stuff it's submission ID into the > linkedhashmap > (from step 3). > > That should do the trick. > > Of course, using javascript to disable the submit button is much > easier, but if you can't, you can't. > > --- Pat > > > > -----Original Message----- > > From: Ralph Johnston [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 30, 2005 5:06 PM > > To: Tapestry users > > Subject: Preventing multiple form submission within Tapestry > > > > Hi, we're working on a project in which we need to submit a form which > > then creates > > a record in a database on successful submission. The problem we have > is > > that if > > someone clicks on the submit button more than once, it creates > duplicate > > records of > > the record that the person is trying to submit. > > > > We've searched the mailing list archives (as best we can) with no > luck. > > We know > > there is a way to prevent this using Javascript. However, not all the > > people using our > > form are guaranteed to have Javascript enabled. Therefore, we need a > way > > of > > disabling the button or creating a semaphore of sorts to prevent > multiple > > submissions > > that either create the new record or alter it in a drastic way. Some > > ideas we have > > are... > > > > 1) Send back something that will disable the button's submit ability > to > > submit the form > > again. For example, somehow killing TCP connection to that form until > the > > submit is > > done. > > > > 2) Hanging when the submission occurs, like display a white page until > > it's done so > > that the user doesn't click something else and terminate the > submission. > > > > 3) Letting the user do whatever he/she wants with the web page > > particularly by > > disabling all the other submit buttons but when the original submit > > listener finishes > > what it's doing, it redirects like we want it to do to the appropriate > > page no matter > > what page the user is on. > > > > Any other ideas or even solutions would be appreciated. Thank you. > > > > Ralph Johnston / Phil Whaley > > The Pathfinder Group, Ltd. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
