Hi, I do not see a specific relationship between RPC and deferred command.
You could you deferred command to have a easy trigger after "all done". For example: Assume you are using method chaining / fluent interfaces or similar techniques. With a deferred command you could solve the finishing problem. The first call to a method chaining command is also scheduling the finishing method. Stefan Bachert http://gwtworld.de On 16 Jul., 20:33, 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.
