Hi Frank,
thanks for your advice. I'm doing something similar. The polling is done
by the user and not with a script. But this has the disadvantage, that the
user does not directly get information at then end of the process but
after the end of a polling cycle or after he manually asked again.
Another solution would be (I'm using a frameset), to use buttons from the
not actually used frames. A click on one of these buttons (the original
target is changed during start of the transaction) starts a new window -
therefore the old frame, waiting for the end of the transaction, is not
disturbed. The end-frame has to reactivate the origin function of the
previously changed buttons.
Andreas
Frank W. Zammetti wrote:
> Hi Andreas,
>
> As you describe it, this isn't something you can do... well,
> *probably*... if you write to the output stream directly in the Action,
> the browser *might* render the partial response, I'm not actually sure
> (although I suspect not). Even if that did work though, it would be a
> pretty bad idea, and would also I think cause an exception if you then
> forwarded to a JSP.
>
> What you will probably want to do instead depends on how long a
> transaction your really doing... if it's something that's going to take
> a few seconds, maybe 30 or less let's say, your best bet might be to
> display a please wait message client-side before sending the request.
> For instance:
>
> <script>
> function showPleaseWait() {
> document.getElementById("entryForm").style.display = "none";
> document.getElementById("pleaseWait").style.display = "block";
> }
> </script>
> <div id="entryForm" style="display:block;">
> <form onSubmit="showPleaseWait();">
> // Some form elements here
> <form>
> </div>
> <div id="pleaseWait" style="display:none;">
> Please wait, processing...
> </div>
>
> Alternatively, you could implement a polling mechanism. Fire off your
> request, and start a thread to do the processing. Then, have the client
> continually check the status of the transaction (which is written out to
> a database maybe) via another Action. So the sequence would be
> something like:
>
> 1. User submits form
> 2. Action A is executed and starts processing thread, forwards to JSP A
> 3. JSP A returns "please wait" page, which includes script (or meta tag)
> to continually call status checking Action
> 4. Status checking Action is executed (x number of times), checks status
> of transaction (thread writes status to database for instance). If
> still running, forward to JSP A (just like the first Action). If
> complete, forward to JSP B
> 5. JSP B renders "all done" page, user can move on
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
