I don't know about addPause, but I think that DeferredCommand is primarily for cases where you need to do something with the DOM before it's actually available. For example, you can put a setFocus call in a DeferredCommand block before the element that's receiving focus has been added to the DOM (assuming that the element will be added to the DOM before the JavaScript thread yields). The code will go on a queue of tasks to perform as soon as the JavaScript thread finishes what it's already doing. I bet the javadocs describe this better.
-Brian On Jul 16, 2:33 pm, alan <[email protected]> wrote: > I'm trying to understand when an RPC call should use a > DeferredCommand, when is should include an addPause and when an RPC > call should not use a DeferredCommand. > > I'm working on a case when I've got a widget that needs to load a > dozen or so ListBoxes. Because of the service layer each one is a > different RPC call, so when this widget is loaded a dozen RPC calls > will occur at once. Since this widget doesn't need to be fully loaded > instantaneously slowing down the rate of calls and even making them > serial would be fine. > > So, I put all of the calls to load this widget into a DeferredCommand > and also added a addPause to each. My observation on FireBug is the > call are all still nearly fired off simultaneously although not as > quickly. It wasn't quite what I expected. > > I've got other calls that happen as part of a user pressing a button, > or on a timer that currently are not using the DeferredCommand, but > I'm wondering if they should. > > Any comments on guidelines for using DeferredCommand and addPause are > appreciated. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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/google-web-toolkit?hl=en.
