TJ,Greatly appreciate the insights. I am going to try a chained asynchronous loop today! Many thanks, :Mark
http://holtsblog.blogspot.com/2009/02/forcing-repaint-dom-in-ie6-and-ie7.html On Mon, Feb 9, 2009 at 5:48 AM, T.J. Crowder <t...@crowdersoftware.com> wrote: > > Hi, > > Apologies, copy-and-paste error, that first pseudo-code block should > not have the call to loopIteration in the onException handler. > Corrected pseudo-code for the synchronous loop: > > list.each(function(elm) { > new Ajax.Request(some_url + '?id=' + elm.id, { > asynchronous: false, > onSuccess: function(xport) { > elm.update(...content derived from xport response...); > }, > onFailure: function(xport) { > elm.update(ERROR_MESSAGE); > }, > onException: function(req, ex) { > elm.update(EXCEPTION_ERROR_MESSAGE); > } > }); > }); > > -- T.J. :-) > > On Feb 9, 1:44 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote: > > Hi, > > > > By marking the ajax requests synchronous, you're basically bringing UI > > updates to a screeching halt. :-) Rather than doing a synchronous > > loop, how 'bout doing a chained asynchronous loop? E.g., suppose we > > have a list (perhaps an Element array from $$) and we want to do a > > call to the server for each element, and update its contents based on > > the result. Rather than this (pseudo-code): > > > > list.each(function(elm) { > > new Ajax.Request(some_url + '?id=' + elm.id, { > > asynchronous: false, > > onSuccess: function(xport) { > > elm.update(...content derived from xport response...); > > }, > > onFailure: function(xport) { > > elm.update(ERROR_MESSAGE); > > }, > > onException: function(req, ex) { > > elm.update(EXCEPTION_ERROR_MESSAGE); > > loopIteration(list, index + 1); > > } > > }); > > }); > > > > How 'bout this pseudo-code: > > > > loopIteration(list, 0); > > function loopIteration(list, index) { > > var elm; > > if (index < list.length) { > > elm = list[index]; > > new Ajax.Request(some_url + '?id=' + elm.id, { > > onSuccess: function(xport) { > > elm.update(...content derived from xport > > response...); > > loopIteration(list, index + 1); > > }, > > onFailure: function(xport) { > > elm.update(ERROR_MESSAGE); > > loopIteration(list, index + 1); > > }, > > onException: function(req, ex) { > > elm.update(EXCEPTION_ERROR_MESSAGE); > > loopIteration(list, index + 1); > > } > > }); > > } > > } > > > > You see how the completion of each asynchronous call triggers the > > next; the loop counter and list are maintained in the execution > > contexts of the various closures. I did the chaining calls to > > loopIteration() separately in the above (rather than in onComplete) in > > case failures or exceptions should not continue the loop. If there > > are aspects of the page that should be disabled while the loop is > > running, you can handle that with a modal flag and disabling relevant > > controls during the course of the loop. > > > > There are several advantages to a chained asynchronous loop rather > > than a synchronous loop. One of the biggest is that browser can > > continue to respond to UI events while the calls are outstanding. Not > > only would that solve your painting problem, but it opens up other UI > > options, like having a Stop button (with a synchronous loop you could > > have it, but the user couldn't click it), or allowing the user to > > scroll around in the page while the loop is running, etc. With > > synchronous calls, many browsers completely lock up the UI during the > > call. > > > > HTH, > > -- > > T.J. Crowder > > tj / crowder software / com > > Independent Software Engineer, consulting services available > > > > On Feb 9, 1:02 am, Holts <holto...@gmail.com> wrote: > > > > > I have loop that makes server-side Ajax calls on each iteration, and > > > returns data. This could be 50 iterations, 500, 5000, whatever. Upon > > > each iteration, I update that particular row with a server-side > > > response (i.e. "success" or "fail"), and then update the total count > > > processed ("26 out of 432 processed"). -- I update the innerHTML of a > > > div or span, and another div showing the total number of records > > > processed (at the end of an iteration, or in the onComplete callback > > > handler of the Ajax.Request). That is all working perfectly fine... > > > in Firefox, Safari, and every other browser except IE6 and IE7. > > > > > I have tried IE hacks such as adding a class to the div, and dropping > > > a class from the div, adding and dropping child nodes from the div, > > > etc -- to attempt to force IE to repaint, I have tried waiting a small > > > interval, to no avail. If you pop up an alert("hai"); at the end of > > > the iteration, the the IE6 and IE7 DOM will repaint with the updated > > > values. (btw, how dumb is that?) > > > > > Does anybody have any tried and true ways to make IE6 or IE7 repaint a > > > particular DOM element in these cases (without obviously popping an > > > alert)? It works flawlessly in Firefox. I know IE is a steaming > > > pile, but just wondering if anyone has had any success with a hack > > > that works here. > > > > > code here:http://gist.github.com/57817 > > > > > it's grabbing all the data properly, so I won't bore you with the > > > markup... just updating the status of the processing results ...no > > > effect in IE6 or IE7... doesn't update: > > > > > E.g.: won't repaint this until the loop has finished (only in IE): > > > $('prg_processed').innerHTML = rows_processed; > > > > > > > -- http://twitter.com/holtonma http://eyeonmajors.com/feedback.htm http://golfap.com/pgatour http://holtsblog.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~----------~----~----~----~------~----~------~--~---
