It's not really a matter of this being GWTs way. I believe this is the only thing browsers support since they do not have multiple threads, at least so that the UI doesn't lock up. And by UI lockup, I don't mean the page is unresponsive - I mean the whole browser used to freeze if a page was in a Javascript loop (actually still does on Firefox).
New browsers have multi-threading, but I believe that multi-threaded Javascript constructs are still a ways away. On Wed, Mar 11, 2009 at 6:58 AM, eggsy <[email protected]> wrote: > > I agree with all the previous posts that Asynchronous is the best way > and that is why GWT only implements this. > > When I started with GWT I was asking a similar question and was > correctly advised to think in terms of Async not Sync the more > development you do with GWT you'll realise this. > > However at the time we did come up with a basic transactional pattern > that performs the methods synchronously: > > http://www.axonbirch.com/blog/2007/10/26/notification-end-of-rpc-call/ > > But as before I would advise that you simply look at this and try > *not* to implement your methods synchronously if possible. > > Eggsy > > On Mar 11, 10:13 am, ping2ravi <[email protected]> wrote: > > I totally agree with you guys that Asynchronous is good, but i would > > love to see mix up of synchrnous and asynchronous in GWT(my personal > > view), where i can make an asynchronous call to one function which > > internally can make synchronous calls and it will solve the problem of > > UI hanging.(In case GWT peope can read it , please implement such > > things), i am sure programmers will enjoy some synchronous calls too > > such as avoiding inner classes or writing new classes for callbacks > > for each call(again personal view). But yes User satisfaction has more > > priority. > > And guys i am really thankfull to all of you for giving suggestions > > > > i guess i will implement some kind of chains as Matias Costa suggested > > and once all chain object get result back will call our UpdateUi > > function as suggested by Ian. > > > > Ravi. > > > > On Mar 11, 9:46 am, al0 <[email protected]> wrote: > > > > > "How much extra code is too much?" - single line of (unnecessary) > > > extra code is way too much. > > > > > On Mar 10, 6:01 pm, mikedshaffer <[email protected]> wrote: > > > > > > Lothar's original suggestion > > > > > > "Do the UI-update in a method called updateUI where you check if all > > > > necessary data (e.g. above lists) are present and call this method > > > > in every onSuccess-method of the different AsyncCallback-classes. " > > > > > > is the way to go. > > > > > > How much extra code is too much? You have 5 async RPC calls each > with > > > > onsuccess handlers that increment a class level field and then call a > > > > "redoUI" type of function. That function continues only when the > > > > increment is 5. Done. We're talking a small amount of code here > > > > really. And that's all good form and the way to do a good AJAX UI. > > > > You can add all sorts of good UI user interaction this way, like wait > > > > cursors to let the user know something is going on. If you > > > > synchronize things, you'll lock up your users browser, and in > general, > > > > tick them off, like Jason articulates. Plus you'll have gnarly > > > > looking code that fights the very asynchronous nature of the way > > > > things work. > > > > > > My thoughts... > > > > > > Later, > > > > > > Shaffer > > > > > > On Mar 10, 10:47 am, Jason Essington <[email protected]> > > > > wrote: > > > > > > > Actually from a user's point of view, hanging the UI is NEVER > > > > > acceptable even if it is for less than a second. > > > > > > > In the case of waiting for a couple of seconds, depending on the > > > > > browser and version, you cannot change tabs, cannot close the > browser > > > > > or anything. This is a VERY NAUGHTY thing to do intentionally. > > > > > > > In the case of a network failure this frozen state lasts > indefinitely, > > > > > and that sort of thing really pisses off your users. particularly > if > > > > > the only way they an figure out how to exit your web app is to > reboot > > > > > their computer! > > > > > > > Learn to divide up your application into the things that need to > > > > > happen before the RPC is sent, and the things that happen after. > place > > > > > those things in their own methods, then call the "after" methods > from > > > > > your Callback. Your users will thank you for it later. > > > > > > > -jason > > > > > > > On Mar 10, 2009, at 10:28 AM, ping2ravi wrote: > > > > > > > > Do you see any problem in having synchronous calls.? except that > it > > > > > > may hang the UI for a second and that is acceptable.- Hide quoted > text - > > > > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
