Return-Path: Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-users@xml.apache.org Delivered-To: moderator for cocoon-users@xml.apache.org Received: (qmail 23822 invoked from network); 23 Feb 2001 20:40:07 -0000 Received: from luna.soncom.com (root@207.195.208.7) by h31.sny.collab.net with SMTP; 23 Feb 2001 20:40:07 -0000 Received: from packbell.soncom.com (pop1-91.soncom.com [207.195.209.91]) by luna.soncom.com (8.11.0/8.11.0) with ESMTP id f1NKe4b13765 for ; Fri, 23 Feb 2001 14:40:05 -0600 (CST) Message-Id: <5.0.2.1.0.20010223140038.00a46af0@mail.soncom.com> X-Sender: bparker@mail.soncom.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 23 Feb 2001 14:40:33 -0600 To: cocoon-users@xml.apache.org From: Brian Parker Subject: Re: Waiting page for a long PDF rendering process In-Reply-To: <20010223002051.A762@dt0b3n83.maine.rr.com> References: <015b01c09cfc$b4e5e1f0$36847aa5@wcomnet.com> <20010222125851.A2503@plan9ws1.uct.usm.maine.edu> <015b01c09cfc$b4e5e1f0$36847aa5@wcomnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N I recently saw another solution to this problem in the Dec, 2000 issue of "Java-Pro" magazine which uses Javascript. What you do is have a "status" page be returned when the user hits submit. In the status page''s "onLoad()" event you invoke your long running transaction. The solutions also involves using Javascript's setTimer() function with the onLoad() event. I can't remember any more details. At 12:20 AM 2/23/01 -0500, you wrote: >It's my understanding that some browsers will not automatically >redirect. This is just the reason most people include a >message something to the effect of "You are being redirected, >if id doesn't work click here" > >Worse comes to worse people will need to click the url to go to the next >page as opposed to being sent there automatically. > >If you discover any other *good* options please send me a link, but >unfortunately I think this is the only available method, except >perhaps an applet. > >-matt > >On Thu, Feb 22, 2001 at 12:24:34PM -0600, Dafang Zhang wrote: > > Hi, Matt, > > > > Thanks for your quick response, and not _redirecting_ to other url :) > > > > I have a little concern about what the spec warned: > > > > http://www.w3.org/TR/html4/struct/global.html#idx-meta_data-2 > > > > "... Authors should not use this technique to forward users to different > > pages, as this makes the page inaccessible to some users. ..." > > > > What page would be inaccessible to "some users"? The redirected one, or > > itself? What kind error messages "some users" would get? I tried hard to > > find any other supporting docs without success. > > > > Thanks. > > Dafang > > > > > -----Original Message----- > > > From: Matthew Cordes [mailto:mcordes@plan9ws1.uct.usm.maine.edu]On > > > Behalf Of Matthew Cordes > > > Sent: Thursday, February 22, 2001 11:59 AM > > > To: cocoon-users@xml.apache.org; dafang.zhang@wcom.com > > > Subject: Re: Waiting page for a long PDF rendering process > > > > > > > > > Hi, > > > > > > As far as I am aware the sendRedirect method does little more > > > than generate a webpage just like yours with http-equiv and all > > > and returns it to the user. > > > > > > If your method works, why change it? Sure, perhaps it won't work > > > with lynx, but opera, ie, netscape all respond to this refresh tag. > > > > > > -matt > > > > > > On Thu, Feb 22, 2001 at 11:47:55AM -0600, Dafang Zhang wrote: > > > > Hi, Cocoon users, > > > > > > > > Say, I'm redenring a PDF document on demand. The redenring > > > process take a > > > > long time for a large document. I would like to display a > > > waiting page, so > > > > that those impatient users won't click on that redenring > > > button again and > > > > again (this will drive the FOP work as many times as user > > > clicked, before > > > > the PDF actually showes up on screen), and also, the user > > > will know that the > > > > system is handling the request. > > > > > > > > Currently, I'm using something like this, and it works like a charm: > > > > > > > > > > > > > > > > > > > > > > > >

Your > > > request is being > > > > processed, please wait...

> > > > > > > > > > > > > > > > I know it's not recommented by the HTML spec, I haven't got > > > the side-effect > > > > so far though: > > > > > > > > "Note. Some user agents support the use of META to refresh > > > the current page > > > > after a specified number of seconds, with the option of > > > replacing it by a > > > > different URI. Authors should not use this technique to > > > forward users to > > > > different pages, as this makes the page inaccessible to > > > some users. Instead, > > > > automatic page forwarding should be done using server-side > > > redirects." > > > > > > > > But, when I try to use server side response.sendRedirect in > > > a XSP page or a > > > > servlet, the waiting message before the call to > > > response.sendRedirect won't > > > > be displayed. I understand why it is not working: the > > > response object > > > > redirect the request to another URL on the server side and > > > anything in this > > > > newly constructed waiting page won't be sent to client side. > > > > > > > > Does anyone have a good solution for this? > > > > > > > > Thanks! > > > > Dafang Zhang > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > Please check that your question has not already been answered in the > > > > FAQ before posting. > > > > > > > > To unsubscribe, e-mail: > > > > For additional commands, e-mail: > > > > > > > > > > > > > --------------------------------------------------------------------- > > Please check that your question has not already been answered in the > > FAQ before posting. > > > > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > >--------------------------------------------------------------------- >Please check that your question has not already been answered in the >FAQ before posting. > >To unsubscribe, e-mail: >For additional commands, e-mail: