I haven't needed this yet with T5 because of the use of redirects and the nature of what I've been doing, but with T4 I used a mixture of javascript to disable Submit buttons, and a synchronization token scheme (it was either posted to the users group, or on the wiki).
It's really an enhancement to validation as far as form processing goes, and for links it could reduce the number of backend checks that need to be made. Those links would not be bookmarkable, so it would need to be configurable on a by-link or by-component/page basis. I think it would be a great addition to the framework. I also wonder how it fits in with the topic of Spring WebFlow integration that has been raised as a future goal. Jonathan > -----Original Message----- > From: 9902468 [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2008 07:52 > To: [email protected] > Subject: Re: T5 double click / multiple windows on same session prevention > > > Dear list: > > I would really like to hear your take on this matter? Has this been > discussed before regarding T5? Is there alternative, better way to stop > double clicks etc? > > Should I just add Jira: "Make Tapestry ignore double clicks"? > > - 99 > > > > 9902468 wrote: > > > > Hi! > > > > In an effort to make J2EE and browsers suck less :) Tapestry should > really > > implement some mechanism to prevent double clicks and all problems > related > > to multiple windows using the same session / back button etc. > > > > I'm familiar with Struts kind approach with tokens, and I am proposing > > similar approach that should be implemented to Tapestry. > > > > The implementation involves filter that intercepts all requests, > > synchronizes them to session, and checks the tokens submitted. > > > > The used method is generic, as it is based on filter that captures > > requests and basically works as specified: > > > > - Check that the token that came with the request matches the token in > > session > > - If no token is associated -> process request as it is processed > > currently > > - If token exists but doesn't match -> Show error page / developer > > configurable action is taken > > - Start processing request. > > - If another request is submitted with the same token and session -> > > capture the response to session > > - When request processing is complete -> populate the latest response > > with the response returned if there is one in session > > - Return the response > > > > The usage of session can probably be at least partially avoided using > > Tapestry's facilities. This should also be configurable as there is > > overhead associated to this process. > > > > What needs to be altered in Tapestry? > > - The addition of the filter (In chain only if this functionality is > > enabled) > > - Perhaps some service that encapsulates some of the logic? > > - Form should be altered to include the token to the submit (If this > > functionality is enabled) > > - Action Event etc links should add the token to request url (If this > > functionality is enabled) > > - New configuration symbol with values > > (SymbolConstants.UNIQUE_REQUEST_SUPPORT): > > - off (default, everything as it is now) > > - forgiving (requests without tokens are processed the same way when > > off) > > - strict-forms (forms are required to have correct token, else as if > > token exists but doesn't match) > > - strict-links (links are required to have correct token, else as if > > token exists but doesn't match) > > - strict (forms and links are required to have correct token, else > as > > if token exists but doesn't match) > > > > I do not have enough knowledge how this can be implemented AJAX wise, > but > > I do know that this should really be corrected. > > > > I'm ready to contribute to this if I can. Please elaborate. > > > > - 99 > > > > -- > View this message in context: http://www.nabble.com/T5-double-click--- > multiple-windows-on-same-session-prevention-tp18807447p18829465.html > Sent from the Tapestry - Dev mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
