Thanks for comment David, I have not time yet to do the implementation but that's typically the kind of thing I want to do... later...
Jacques De : "David E Jones" <[EMAIL PROTECTED]> > > > Jacques Le Roux wrote: > > Hi, > > > > I remember having seen discussion and even implementation of a mechanism > > (javascript function submitFormDisableSubmits in rev. > > 525629) to avoid double posting. > > Looking in Nabble I found only this thread > > http://www.nabble.com/Dev---Double-posting-in-service-and-entity-ECAs-tf1196643.html > > which is not really related. > > I read also in > > http://www.opensourcestrategies.com/ofbiz/ofbiz_webapp_cookbook.txt that we > > should use > > <response type="request-redirect" ... > > But the explanation is not clear to me. Also I find this solution a bit > > tricky, I think this should be always done without having to > > worry about. > > > > So I wonder why OFBiz is not using the Synchronizer token pattern as > > described in "Core J2EE Patterns" from > > http://docs.ofbiz.org/display/OFBIZ/OFBiz+Related+Books ? The book gives an > > example of how it's done in Strut for instance. > > Note that all of the solutions to this are a bit tricky and none of them are > perfect. The request-redirect isn't a perfect solution but helps because the first round-trip is faster and hopefully the browser will clear the page, but the main benefit is that if the user goes back unless they use a history or go back twice real quick then they won't get back to the form. > > The "synchronizer token", really more of a singleton type of thing, is meant > more to prevent multiple submits. These can be really annoying though if not implemented correctly, and there always seem to be little quirks with them (in spite of a basic implementation being fairly simple). The client side JavaScript can be annoying too if a packet is dropped in the request or something causes the page to not load. > > Anyway, I think the main reason for no per-form singleton key being in place > is that it just hasn't been implemented yet to automatically happen. Generating a key and putting it in the session in a Set of valid keys (the Set is necessary instead of a single value because they might have multiple windows/tabs open in the app or other various scenarios that make it annoying without the Set) and then removing it once the form is submitted and returning an error if the key for the form isn't there isn't all that hard. If the form widget and a service event handler are used we can do it automatically in those places (for FTL forms and custom event handlers it would have to be manually checked). > > -David
