Re: Preventing multiple form submission within Tapestry

[Ralph Johnston <ta...@rjohnston.net>]

We're trying to prevent redirecting to a page that we don't want the user to go to.  
Granted, they might learn after they get the exception page a couple of times and 
stop doing multiple submissions, that just isn't a very user friendly way of handling 
this issue.

What we need to do is find a way to stave off or queue up other page 
renders (and ignore them) that might follow the initial call of one of the listener 
methods we're trying to prevent multiple submissions of.  The synchronization 
solution seems to be the best bet but will this prevent a rerender of the page if other 
multiple submissions, which would we would return from, occur?  Flow synchronizer 
looks to be really good but I like stated, redirecting to an exception page generally is 
bad user friendly design.

Thanks!

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Preventing multiple form submission within Tapestry

[Richard Kirby <rb...@capdm.com>]

Ralph Johnston wrote:

>We're trying to prevent redirecting to a page that we don't want the user to go to.  
>Granted, they might learn after they get the exception page a couple of times and 
>stop doing multiple submissions, that just isn't a very user friendly way of handling 
>this issue.
>
>What we need to do is find a way to stave off or queue up other page 
>renders (and ignore them) that might follow the initial call of one of the listener 
>methods we're trying to prevent multiple submissions of.  The synchronization 
>solution seems to be the best bet but will this prevent a rerender of the page if other 
>multiple submissions, which would we would return from, occur?  Flow synchronizer 
>looks to be really good but I like stated, redirecting to an exception page generally is 
>bad user friendly design.
>
>Thanks!
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>  
>
Hi,

You appear to have a little confusion as to how the web works. If the 
user clicks submit a second time, before the first submit has returned, 
the browser will close its end of the connection to the server for the 
1st submit, and open a new connection. However the server will not know 
this and will merrily carry on processing the first submit request, and 
also start on the second submit request. When the server finally 
finishes processing the first submit request, it will try to write the 
result (the real result that you want) back down a closed connection, 
and therefore loses it. The second request when finished will be the 
actual result returned back to the browser, since its connection is the 
one that is open. Note that the second request could theoretically 
finish before the first request!

So, what you could do to protect against this accidental double submit, 
is separate the processing of the request from the returning of the 
resulting page. Then by using the unique token in the form pattern, you 
can detect a double submit. A rough flow would be:

1. Page with form is requested. Generate a unique token hidden on the form.
2. Form listener request comes in with unique token.
3. Form Listener, synchronizing on some shared object, such as your 
Visit object, immediately checks to see if the unique token has already 
been processed.
    If so, it looks up the result (waiting for the result - using a 
semaphore perhaps) of that processing and renders the response.
    If not, it notes that the unique token is being processed, and then 
starts processing (such as adding the data from the form into the database).
    When the processing has finished, it notes that the unique token has 
finished, and stores any required result. It then renders the response.

On a multiple submit scenario - all the submits will send the same 
unique token. The very first one will cause the form processing to 
happen, and all the rest will wait until the processing has finished 
before attempting to send back the resulting response. Only the last 
submit will actually send a response that the browser will see, since 
all the previous connections will be closed by the browser!

Hope this helps

Richard




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org