Hi All,
I have implemented a solution that I like to handle a
TimeConsumingRequest(TCR).
I have build a Thread that performs the TCR. This thread also provides
methods to retrieve the status of the process and the result bean of the
process.
//Returns true while the TCR is processing false when done
public boolean isProcessing();
//Returns true when processing is completed
public boolean isComplete()
//When the TCR is done I need the result information to display
public Result getResult();
My action builds the thread and launches it. I then bind the thread to
the session and I forward my user to the result page. Requests that come
in to my action that contain invalid tokens are just directed to the
result.jsp. This way my user is not stuck on their input form while
waiting for the result which is sure to cause a second submit and is not
user friendly.
My result.jsp checks to see if the thread is still processing if so it
displays a "please wait prompt" and sets the pages header to refresh in
Xsec else it gets the Thread.Result and displays to the user. This
solution involves a scriplet that performs response.setHeader("Refresh",
"10"). I dislike scriplets so I am building a custom tag to handle my
TCR. It will look like this:
<!-- What to display while the transaction is processing
name: name of the Thread bound to the session
property: method that returns a boolean
value indicating state
pollingInterval: The refresh interval set in the
pages header max: Max number of polls.
If isProcessing returns true tag sets
response.setHeader("Refresh", "10"); and a counter in the
session for the max count to avoid endless polling.
-->
<tcr:isProcessing name="transactionWorker"
property="isProcessing" pollingInterval="10" max="3">
Please wait, your request is being processed.
</tcr:isProcessing>
<!-- What to display when the trasaction is complete -->
<tcr:isComplete name="transactionWorker" property="isComplete">
<bean:write name="transactionWorker"
property="result.authCode" scope="session"/>....
</tcr:isComplete>
What do you all think about this?
Greg
-----Original Message-----
From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 9:58 AM
To: Struts Users Mailing List
Subject: RE: Application Flow with Transaction Tokens?
I just checked the book. His approach is to just throw a servlet
exception
when a sensitive form is resubmitted. I believe what Greg wants is a
way to
display the results just as if the second submition did not occur.
> -----Original Message-----
> From: DUBCHAK, JOHN (SBCSI) [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 3:54 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Application Flow with Transaction Tokens?
>
>
> David Geary presented something similar to this in his Advanced
JavaServer
> Pages book. It was implemented on top of his custom Model-2
> implementation
> but in truth could be easily adapted for use within your own
environment.
>
> I don't have the book here with me at work, otherwise I would provide
> greater detail and a page reference.
>
> HTH,
> John
>
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 2: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]
