Hi Neil,

Are you using XMLHttpRequest to receive the response, (rather than an iframe, 
say, which is popular with Comet type apps)? If you're using Prototype's Ajax 
classes, then the answer is 'yes', btw :)

Basically, the notification mechanism (onReadyStateChange) for XHR is kind of 
broken by Comet, but you can still query the readyState and see the 
incremental data coming in if you start to poll the XHR with a timeout once 
it's hit the interactive state. As I remember, Firefox tends to call 
onInteractive for every chunk of content coming in, whereas IE calls it once 
and then goes quiet until onComplete (by which time the show's over as far as 
Comet is concerned).

Anyway, the solution would look something like this:

var listener=null;
var request=new Ajax.Request(
  myURL,
  { onInteractive: function(xhr){
        if (!listener){
          listener=new PeriodicalExecuter(
            function(){
               doSomethingWithResponse(xhr);
            }, 
            1 /* check for changes to response text every 1 second*/
          );
        }
    }
  }
)

and doSomethingWithResponse() would then be able to read xhr.responseText, and 
figure out if it has changed since last time round. You need to fire off the  
periodical executer at the point at which the response is interactive, as 
trying to read the responseText before then can trigger a native error.

The code above is a bit rough, pulled out of a larger example with confusing 
extra twiddles in it, but it should give you an idea...

HTH

Dave

On Monday 19 February 2007 10:18, Neil Ravo (Manhatten Project) wrote:
> OK,  An update.  The flush does indeed work and return information to
> the page as it is delivered to the calling page but the problem we
> have is this...in Firefox...it looks sweet and works exactly as we
> would expect (the return action updates as it gets the info from the
> page) but in IE the information only seems to come back when it the
> requested page is complete on the calling side?!  it is really
> wierd.
>
> Any ideas?
>
> Neil
>
>
>
>
>
>
>
> On 16 Feb, 10:01, "Neil Ravo (Manhatten Project)"
>
> <[EMAIL PROTECTED]> wrote:
> > Interesting,  basically as a background - I am calling a ColdFusion
> > page which behind the scenes runs a fairly intensive process.  What we
> > have done to alleviate this is to give the client periodic updates
> > from the running request via the tag <cfflush> when each step is
> > complete, so in the browser window it will simply say "Step 1" then a
> > delay while the process runs then state "Step 1.....Complete".
> >
> > The cfflush tag is described here..http://livedocs.adobe.com/
> > coldfusion/7/htmldocs/wwhelp/wwhimpl/common/html/wwhelp.htm?
> > context=ColdFusion_Documentation&file=00000255.htm
> >
> > What I was thinking of doing it calling the necessary page for load
> > the returning the contents of the file after each cfflush in order for
> > the client to know what is going on visually.
> >
> > Possible in this case?  I realise I would need to roll my own but I am
> > more interested in, is this possible at all?!
> >
> > Thanks
> >
> > On 15 Feb, 15:21, Dave Crane <[EMAIL PROTECTED]> wrote:
> > >  As an alternative to polling the client, as Ryan describes, you could
> > >  consider piggy-backing the status updates on the back of other ajax
> > >  responses. Which way you go depends entirely on the nature of your
> > > app, in particular:
> > >
> > > 1. how frequently it generates ajax traffic anyway
> > > 2. how long the server-side process is going to take
> > >
> > > If the server-side process takes, say, 20 seconds, polling is a good
> > > choice. If it'll take half an hour, piggy-backing is not going to
> > > hammer your server anything like as much.
> > >
> > > The X-JSON header in Prototype, combined with Ajax.Responders, makes an
> > > excellent infrastructure for the piggy-backing approach.
> > >
> > > Dave
> > >
> > > On Thursday 15 February 2007 18:03, Ryan Gahl wrote:
> > > > Short of using comet (google for "cometd" for an explanation), this
> > > > is a manual type of thing...
> > > >
> > > > 1. Initial request goes to server, server responds "starting step 1"
> > > > 2. Client gets message, immediately sends another request to server,
> > > > server responds "still in step 1, dude, chill out..."
> > > > 3. Client gets message, repeats calls until server says "alright
> > > > already, I'm done, here's your damn data"
> > > >
> > > > and you show nice message for each cycle... you can also implement a
> > > > progress bar if you want. But the bottom line is, with standard AJAX,
> > > > you need to program it yourself.
> > > >
> > > > On 2/15/07, Neil Ravo (Manhatten Project) <[EMAIL PROTECTED]> 
wrote:
> > > > > Hi,
> > > > >
> > > > > More a pure Ajax question that SAU, but is there a way you can
> > > > > increment status messages back to the client when calling a long
> > > > > running request? i.e. if I have a request which calls a remote
> > > > > page, which in turn sends back a message after each function has
> > > > > completed can you incrementally tell the client that "function 1
> > > > > has finished" (while the system has moved on to step 2), "function
> > > > > 2 has finished" etc.  I know I can send back simple messages on a
> > > > > page complete via standard Ajax status calls but I was wondering if
> > > > > it was possible using headers or some other mechanism to
> > > > > incrementally tell the client what is going on.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Neil
> > >
> > > -------------------------------------------------------
> > >
> > > --
> > > ----------------------
> > > Author
> > > Ajax in Actionhttp://manning.com/crane
> > > Ajax in Practicehttp://manning.com/crane2
> > > Prototype & Scriptaculous Quicklyhttp://manning.com/crane3
>
> >
>
> --
> This email has been verified as Virus free
> Virus Protection and more available at http://www.plus.net

-- 
----------------------
Author
Ajax in Action http://manning.com/crane
Ajax in Practice http://manning.com/crane2
Prototype & Scriptaculous Quickly http://manning.com/crane3

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to