We did do the javascript thing on a non-struts project. The only reason it
was not so bad was because the js code was put put in one menu include that
contained
the links and that was that.
On our current struts project we use tokens in all our important actions
to take care of page re loads and so on. In most cases, the we can return
from the method and go to the calling page with a errors message.
In addition, we had to synchronize our Session Facade methods.
It seems between these two things, the user is prevented from doing any
damage.
my 0.02 cents.
"Jerome Jacobsen" <[EMAIL PROTECTED]> on 02/18/2003 03:08:01
PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject: RE: Application Flow with Transaction Tokens?
I posted an idea on how to handle this a while back.
http://marc.theaimsgroup.com/?l=struts-user&m=104404655411300&w=2
Like I said in that post, I've never tried it.
If you can restrict clients to have Javascript enabled then I think John's
solution is the easiest. Since I have the luxury of enforcing Javascript
to
be enabled John's solution is what I've been using.
> -----Original Message-----
> From: John Espey [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 3:50 PM
> To: Struts Users Mailing List
> Subject: RE: Application Flow with Transaction Tokens?
>
>
> Nobody will like this solution, but I've had to resort to it (as
> recommended
> by a coworker). Create a page scope javascript variable, and increment
it
> when the user clicks the button, if it's equal to one , return true,
> otherwise false. I am fully aware of the shortcomings of javascript (for
> all the smarties out there who want to shoot it down ;-), but I'm just
not
> smart enough to come up with a better way to force the user to wait until
> processing is done after clicking a button....
>
> > -----Original Message-----
> > From: Ted Husted [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, February 18, 2003 3:45 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Application Flow with Transaction Tokens?
> >
> >
> > Greg Hess writes:
> > > I would like to ignore the fact that the double submit happened and
> > > just display the proper receipt. Should I forward the user to a
> > > "transaction already processed page" they will loose their proper
> > > receipt and never visually receive the receipt as I also send it
> > > by e-mail.
> >
> > I don't really have any practical advice, but I did want to mention
that
> > I've always wondered about the best way to resolve this sort of thing.
> > So far my own double-submit cases have not involved a long-running
> > process, and have been easy to resolve with an message page. If you
come
> > up with a solution for the long-processing scenario that you like, be
> > sure to let us know. I'd like to see a how-to regarding this in
> > documentation area. It's definately a thorny problem.
> >
> > -Ted.
> >
> >
> > --
> > Ted Husted,
> > Struts in Action <http://husted.com/struts/book.html>
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
>
---------------------------------------------------------------------
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]
