Doing this well depends on some form of centralized data retrieve dispatch/caching. You make calls to this centralized service to get the objects by id that you are interested in. It either finds them in cache and can return them immediately, or adds them to a queue of objects to retrieve. After all requests have been made (ie on DeferredCommand), a single request is sent to retrieve all objects of all types needed.
As for updating on return, there's lots of ways. You could use an event bus to indicate all the objects where data is now available. This could even be a single event instead of one for each object, and the event handlers can ask if their objects of interest are now available, avoiding multiple updates. Alternatively, you can use the current async callback mechanism, but with a way to consolidate - all requests by Person X get resolved to a single callback. Either of these require a bit of work to set up a robust centralized service, but once done all the code around using it for well cached fast object retrieval becomes pretty easy and automatic, nicely async, and retrieves the minimum of data. I've found it's well worth the effort. And likely some of these libraries out there have these mechanisms built in. jk On Apr 29, 10:56 am, brendan <brendan.law...@gmail.com> wrote: > Another question beginning with the sentence "I watched Ray Ryan's > talk": > > Firstly, great talk. Full of really useful ideas. But I have a > dilemma. > > 1) On one hand, I want to follow the advice that says "go with the > asynch flow". I'm happy to do that. > > 2) On the other hand, I also want to follow the advice that object > graphs should be avoided and domain objects should really just contain > ids of their related objects. In the case of lists, this is to avoid > sending too much useless info over the wire. And for AppEngine users > working with JDO, this is unavoidable in any case, for objects in an > 'unowned' relationship with the top level object. > > The combination of these two pieces of advice leads me to a situation > where I could really do with some advice on what is considered best > practice. Imagine I have a domain object - call it Person - which has > multiple related 'unowned' objects, e.g. Group, Company etc. I want to > list a bunch of Persons on my GWT front end, but the display for each > row requires data from the related objects (e.g. group name, company > name). Following advice 2 above (or perhaps constrained by JDO), my > User object has only the ids of the related Group and Company objects, > and so after retrieving the list of Users from the server side, the > User List Presenter must make a separate RPC call for each Group and > Company object for each User. Let's pretend that because of smart > caching this wasn't particularly expensive (arguable). I'm still left > with the problem that following advice 1 about each call is asynch. I > can't display a User row until I hear back from the two Group and > Company calls. To achieve this delayed display, I have to 'recombine' > the two asynch calls using some kind of local flags, and only when > both callbacks have been triggered is it safe to display the row. > > Besides the ugliness and complexity of code like that, there is also > the possibility that the order of my list will be changed due to the > unpredictability of the callback sequence. > > There are a number of workarounds I can think of, but I'd really like > some advice based on experience, if somebody is willing to share. The > solution I would tend towards would be to build a graph on the > serverside and to hell with advice 2. > > Any takers? > > -- > 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-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- 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-tool...@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.
