Re: Ray Ryan, best practices and embracing asynchronicity
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 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 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 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
Re: Ray Ryan, best practices and embracing asynchronicity
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 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 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 comp
Re: Ray Ryan, best practices and embracing asynchronicity
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 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.
