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]

Reply via email to