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]