I've had the same problem some months ago.
I was developping a big application for a telco enterprise and most of
the application forms requiered loading several fields at the same
time during initialization.
For example, the "create a route between servers" form requieres to
load several drop-down lists: equipments, cards, business units,
market, ...

I don't want the user can work with the window until all the lists and
controls are loaded.
And I don't want to merge all services (getEquipments, getCards, ...)
in only one big service specific for this form.
It's easier to reuse code having atomic services.

I create a synchronizer class. During initialization I called
individual services (all calls are procesed in paralel and the total
time is slowest service time, not the sum).
I stored each asyncallback in the synchonizer, and finally create a
modal "loading" window. This modal window blocks the user but the
browser and the javascript engine aren't freezed.
When all the asyncalls are asnswered (succesfully or not), the
synchonizer close the modal "loading" window and the user can work the
full loaded form.

Hope it helps,

On Mar 12, 11:39 am, alex <alex.dobjans...@gmail.com> wrote:
> Why do you need sync`ed method calls?
> I think that you actually need a way to find out when a RPC call has
> returned (either one of onSuccess / onFailed).
>
> One way to go with this is to have a simple event system where events
> are thrown when changes are made - these changes can be UI
> modifications, RPC calls that arrived at client code, etc.
>
> Class Event { String eventName, ..... }
> Interface EventHandler { public void handleEvent (Event
> event); ...... }
> Class EventDispatcher { here I have declared static members /
> functions to register and dispatch incoming events }
>
> Now all classes that need events would implement EventHandler.
> Registering is done via constructor (or some other means).
>
> We have implemented this system in a relatively large application and
> it works like charm :)
> Personally I have also used this paradigm for 2 personal projects, one
> of them had no server-side and all reads were done with RequestBuilder
> - everything went great
>
> Of course, you can extend the system - what I am planning to do for
> the library we are working on right now - to "freeze" the client code
> until all conditions are satisfied.
>
> Hope this helps,
> Alex.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to