Ray Ryan, best practices and embracing asynchronicity
22 views
Skip to first unread message
brendan
Apr 29, 2010, 12:56:07 PM4/29/10
to Google Web Toolkit
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
kozura
May 1, 2010, 11:23:07 AM5/1/10
to Google Web Toolkit
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
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
Sripathi Krishnan
May 1, 2010, 2:14:51 PM5/1/10
to google-we...@googlegroups.com
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
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
brendan
May 5, 2010, 9:24:25 AM5/5/10
to Google Web Toolkit
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:
> the browser needs* (DTO) and *what the business needs* (domain objects).
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .
> > .
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
> 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.
>
> the browser needs* (DTO) and *what the business needs* (domain objects).
> > .
> > > For more options, visit this group athttp://
> > groups.google.com/group/google-web-toolkit?hl=en.
>
> > 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-we...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > 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-we...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Reply all
Reply to author
Forward
0 new messages