Great thought, Thomas. I changed resolveServiceClass to take a RequestContext class as you suggest.
On 2011/03/12 10:16:35, tbroyer wrote:
A few more thoughts: - resolveServiceClass would benefit from being cached at the
ServiceLayerCache
level - I know this is only about the server-side, but I wonder how it'd
work for the
client-side: because this is only based on the requestContextMethod,
if you have
a GenericDAORequestContext interface, you'll have no way of getting a
reference
on the PersonRequestContext the method was called on. This is an issue
with
resolveDomainMethod's signature as well, but maybe we should try to
not
introduce another such method?
Resolving the client-side part of the issue would probably mean
changing the
protocol to send the non-@BaseService interface name along with the
method name,
or sending PersonContext#listAll instead of
GenericDAORequestContext#listAll;
but the Method resolved by resolveRequestContextMethod would still be
the one on
GenericDAORequestContext, with no reference back to PersonContext. There could be a resolveRequestContextInterface, but then the returned
Class<?
extends RequestContext> would have to be passed in addition to the requestContextMethod everywhere. This means adding overloads taking both the Class and Method and
deprecating the
existing methods taking only a Method (which would no longer be used,
so that
would be a breaking change, hopefully only impacting a few users).
So I'd suggest resolveServiceClass take the Class<? extends
RequestContext>
rather than the Method.
http://gwt-code-reviews.appspot.com/1384802/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
