Double submission is a hard problem, and transactions doesn't necessarily solve it. Sometimes you do want to allow users to press the Back button, which is not support by tokens.
The solution with the Javascript popup we introduced is not the best way. Also the new dynamic button system doesn't solve this problem, but solves the problem of internationalizing the buttons. I think one of the best solutions would be to integrate the "Please wait, processing" popup in more places, so that the users know immediately that the action has been taken into account. An example of where we do this is in the Workflow popup. It could be generalized to more places, and seems to work relatively well.
There is no plan to do this on our side though, so if it's something you need rapidly maybe you can help out ?
Regards, Serge Huber.
[EMAIL PROTECTED] wrote:
I saw that the problem we are having was already discussed in http://list.jahia.org/install_list/msg01190.html.
Our users complained that if the system was slow or did not react, they pressed the button in the engine a second time and then they get the "You have already submitted this form" alert message. Furthermore they can't even press "Cancel" anymore as they will get the same error message. So they can only close the window with the X button in the window frame. This again does not remove locks on containers or container lists and so on,....
In the referenced message Serge promised the following as reaction to the mentioned problem:
> In the next version of Jahia (4.1), we are introducing a dynamic button > generation system that will allow us for example to generate larger > buttons, easier to click on, etc...
This statement does not directly say you will provide a solution for the "double submission" problem. Will there be something, so that we could say the users, that they should wait? There is nothing we could do meanwhile?
I don't know if there is a comfortable solution for that. As you mentioned the second pressing of the button interrupts the first submission's flow between browser and server. So some people suggest to disable the buttons, but this is a bit drastic, too. First of all the users won't like it and second what if something interrupts again (maybe ESC key), then the buttons won't get enabled.
The other solution I know is the unique token in the session and as hidden field in the form, what is described in http://java.sun.com/developer/EJTechTips/2003/tt0114.html. This solution has some minor limitations, which are described there.
Would you suggest to wait or to try implementing such a token solution or is there a third way to do it?
Thanks, Benjamin Papez
