Thanks for that Martin - I understand. Thanks also for the alternate approaches.
I think we might experiment with the AjaxChannel#ACTIVE approach as an alternative although we do have the veil approach ready to ship. Cheers. -----Original Message----- From: Martin Grigorov [mailto:[email protected]] Sent: Monday, 24 November 2014 7:08 PM To: [email protected] Subject: Re: Question on Double Submit and rendering strategy Hi, What you observe is correct ! Wicket support for Redirect after Post <http://en.wikipedia.org/wiki/Post/Redirect/Get> is to prevent double submit of a form if the user reloads the page (Ctrl+R or F5) or if the user navigates back. In these cases usually the browser would ask you whether you want to re-send the form data. With the REDIRECT_TO_XYZ strategies this is avoided. As you have found out this doesn't cover the cases when the user clicks several times on a submit button/link. The only support for this in Wicket is to use AjaxChannel#ACTIVE for Ajax submit buttons/links. Using an active channel will prevent any following Ajax call while there is an active one with the same channel name. But this solution doesn't provide visual feedback for the user. It just silently ignores the click event. Other ways to prevent multiple submits are not so generic and that's why they are not provided by Wicket itself. These include: - Disable the button/link somehow Wicket 6.x replaces <a> with <span><em> by default but this is not acceptable by some applications. Wicket-Bootstrap <https://github.com/l0rdn1kk0n/wicket-bootstrap> for example follows Bootstrap recommendations for making the button/link look and act as disabled - Show a veil Some apps prefer to veil only the button. Others the whole screen. Others some area, e.g. just the form. The UI used as a veil also differs for most applications... That's why Wicket doesn't provide a generic solution here. Any feedback about this and other topics in Wicket are very welcome ! On Mon, Nov 24, 2014 at 1:36 AM, Hesketh, Mark <[email protected]> wrote: > Hi > > Please give more details what you try to avoid exactly by making > changes in this area. > [MH] Hello again, > [MH] Well, I'm trying to avoid Double Submit through repeatedly button > clicking (or submitting a form). We're currently [MH] porting all our > web applications to Wicket. We have had to include a veil function > around the Next button [MH] to block subsequent clicks explicitly as > Wicket's Double Submit prevention (we are using the default > RENDER_TO_BUFFER render strategy) [MH] is allowing repeated requests > through. I've stepped through > WebPageRenderer::respond() and noticed that there's a call [MH] to > getAndRemoveBufferedResponse() and stopped looking since I could see > that responses were being discarded. I just assumed that I am > misunderstanding [MH] the full intent of the Double Submit treatment > in Wicket. Hope that makes sense. I'm not wanting to *change* Wicket > here, I'm chasing clarification only given what [MH] what I've stepped > through and hear that from the maintainers directly. I guess I'm > confused about what happens when there's more than one duplicate > request when [MH] clearly the implementation is discarding (by design) > the buffered response to an identical earlier request. > [MH] > [MH] Many thanks > > > Hello, > > > > I just wanted to know what the impact of removing the buffered > > response (referring to javadoc below for REDIRECT_TO_BUFFER) for a > > request is if there's presumably a bunch of other duplicate requests > > following it on solving the Double Submit problem. > > ( > > http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/s > > et > > tings/IRequestCycleSettings.html > > ) > > > > I'm puzzled about throwing a response away when I would have thought > > it's buffered and reused to service the (duplicate) requests following? > > > > Many thanks > > > > cheers. > > -m. > > > > > > -------------------------------------------------------------------- > > -- > > - This email, and any attachments, may be confidential and also > > privileged. > > If you are not the intended recipient, please notify the sender and > > delete all copies of this transmission along with any attachments > > immediately. You should not copy or use it for any purpose, nor > > disclose its contents to any other person. > > -------------------------------------------------------------------- > > -- > > - > > > ---------------------------------------------------------------------- > - This email, and any attachments, may be confidential and also > privileged. > If you are not the intended recipient, please notify the sender and > delete all copies of this transmission along with any attachments > immediately. You should not copy or use it for any purpose, nor > disclose its contents to any other person. > ---------------------------------------------------------------------- > - > ----------------------------------------------------------------------- This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. ----------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
