Thanks for your response. It was helpful since it brought up some other instances that I hadn't really thought of, such as allowing a double submit for certain actions.
> > Here is the flow we have for this application. > > > > 1. User searches for a profile > > 2. List of matching profiles is displayed > > 3. User clicks the EDIT link for the profile they want to update > > 4. Profile is displayed with a TOKEN embedded in a hidden form field > > 5. User hits Submit to update changes (possibly hitting it twice). > > 6. If isValidToken == TRUE, call resetToken(request) and > > the Action will Forward to: > > a) A confim page using redirect on SUCCESS > > b) Back to the form page with error msgs on FAILURE > > > > So where do I go if isValidToken != TRUE? > > Personally I wouldn't want to check for double submit if the action is > going to do an "Update" similar to your case (Profile Update) for the > simple reason that the form could have been changed between two > submits (If the Update is taking 5 secs, let's say (for whatever > reason), the user has enough time to change his profile and do another > submit before the previous submit is completed. In this case, it's > better to save the latest changes by the user) The truth is, the section that's really causing us problems is our enrollment section (adding a user). The problem is really a transactional issue. User fills out a form, submits it, which is then supposed to take that info, create a profile for our website and and then submit that info to a 3rd party which will create a linked account on their side. The problem is caused when the user submit twice. If we send the same request to our 3rd party, their web service throws an exception. We have now idea what the result of the first request was. So in your opinion, in a case like this, is it best to just take them to an error page? If so, do you take them to a blank error page or take them back to the form they filled out with the error on top? > > Here's what I'd > > like to do. I'd like to basically store in the session the Token, the > > requested ActionMapping and the UID of the object being handled (in > > this case a profile_ID). Then if the isValidToken returns false, look > > in the session for the last *successful* token that matched the > > ActionMapping and profile_ID for this request and send them to the > > same result page. Does that make sense? > > I wouldn't want to store the "ActionMapping" in the session because I > get the same "ActionMapping" to the execute method. Well one pitfall I > think will potentially happen is this [ User successfully updates a > profile with profile id : 150 (no double submit) and you show him a > success page saying "profile with profile id 150 is successfully > updated" > > Next thing the user does, being in the same session, is that he tries > to update profile with profile id 151 (but clicking multiple times). > Now your application will show the user "profile with profile id 150 > is successfully updated" instead of showing "profile with profile id > 151 is successfully updated" (Also with the potential of ignoring the > user's latest changes) Why wouldn't the message be updated to show 151? Wouldn't the first request on the double click have over written the 150? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
