Sri - you make a lot of sense in all of this. I had trapped myself into a certain way of thinking, and this was the right way out. Thanks for taking the time. Very well argued.
On May 1, 7:14 pm, Sripathi Krishnan <sripathikrish...@gmail.com> wrote: > When you show a list of Persons on the browser, do you also show the last > traded price of the Company that the Person works for? Obviously not. Then > why would you want to send the entire Company object with the Person object? > > The browser just needs a few simple properties of a Person - personal > details, company name, group name - and that's it. It doesn't care about the > Group object or the Company object; it just needs certain values from them. > But in your back-end java code, you need to be normalized. You really want > to think of Companies and Groups as separate entities. And you really want > to store the last traded price for every Company to perform some > calculation. > > Point I am trying to make is that there is a clear distinction between *what > the browser needs* (DTO) and *what the business needs* (domain objects). > When you send JDO objects across the wire, you are sending your domain > model. Its not what the browser wants, and that is a problem. Soon, you will > have a presentational information in your domain model, and you will have > restricted information being sent to the browser, and it will be a big mess. > > So, take a step back, and separate Domain objects from Presentation objects > (or DTOs). Make your RPCs revolve around a particular view, and send all > necessary information for that view in one RPC call. Note that now your > Person would include company name and company id, but not the entire company > object. Now, when the user clicks the company in the view, you make a RPC > call to get company information (because you have company id). That's it. > Works nicely, without having to make multiple calls. > > --Sri > > On 1 May 2010 20:53, kozura <koz...@gmail.com> wrote: > > > > > > > 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-toolkit@googlegroups.com > > . > > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > > cr...@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<google-web-toolkit%2Bunsubs > > cr...@googlegroups.com> > > . > > For more options, visit this group at > >http://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 > 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.
