There's one other caveat: some operations might take a very, very, long
time to complete and in such a case we want to give the user the option
of navigating to another part of the site (minimising the "waiting"
page to a small panel on the page, which will display "completed" when
the operation finishes). This opens another can of worms, especially if
we allow the user to close the browser and come back for their results
later. Basically, the output (with view state, form post data, etc)
from the pages needs to be stored in some kind of cache on the server,
probably keyed by user id. So, back to the beginning question ... is
there any way to divert the page's output to a memory-backed stream
rather than returning it back to the client over the network?
Chris Fulstow wrote:
> Jono
>
> You could definitely achieve some thing like this using AJAX, check out
> the ASP.NET AJAX Framework, in particular the UpdateProgress control.
>
> http://atlas.asp.net/
> http://atlas.asp.net/docs/Server/Mic...s/default.aspx
>
> Jono wrote:
> > Thanks Chris, but that appears to be a way of delaying the page's
> > rendering until multiple asynchronous operations complete, rather than
> > returning some interim HTML to the client to let them know that the
> > server's busy working on their request.
> >
> > I've heard a lot about AJAX recently and I wonder if this isn't a
> > technology that might help in this situation.
> >
> > Regards,
> >
> > Jono
> >
> > Chris Fulstow wrote:
> > > Check out the MSDN Magazine article about building asynchronous pages:
> > > http://msdn.microsoft.com/msdnmag/is...10/WickedCode/
> > >
> > > Jono wrote:
> > > > Hi Everyone,
> > > >
> > > > As it says in the title, I'm looking for a way to display a page while
> > > > long running operations are performed on the server. Ideally, I'd like
> > > > some way to push the current request onto some stack, where it would
> > > > continue to be processed asynchronously (most importantly preserving
> > > > things like view state, form post data, etc). In the interim, while the
> > > > main request is processed, a friendly page will be displayed to the
> > > > user. That "waiting" page would periodically poll to see if the main
> > > > request is ready, eventually popping the stack and displaying the
> > > > results of the long running operation.
> > > >
> > > > I've tried it briefly with Response.Redirect(...) to the waiting page
> > > > and then back to the main page, when it's done, but I lose all the post
> > > > back data. I also tried Server.Transfer(...) but saw the same effects.
> > > >
> > > > One thing that crossed my mind - which is probably not possible, but
> > > > that's why I'm asking you here - was to do some kind of fork with the
> > > > output stream so that the response of the main page was written into a
> > > > database row (or some other persistence mechanism) while a waiting page
> > > > was returned to the user. That waiting page would periodically check
> > > > the status of the main request, and if it was complete it would return
> > > > the results back to the client.
> > > >
> > > > If anyone's got any bright ideas, and would like to share them, I'd
> > > > really appreciate it.
> > > >
> > > > Thanks,
> > > >
> > > > Jono
Similar Threads
