Reviewers: bobv, rjrjr,
Message:
I initially thought about skipping validation of the
ProxyFor/ProxyForName/Service/ServiceName if the class is annotated
(i.e. don't "poison" the RFIV, or fail in the RequestFactoryGenerator,
if the ProxyFor/etc. annotation is absent), and allowing the annotation
at the class level as a shortcut to annotating each and every method;
but I don't think it's necessary: it's a very advanced feature, so you
have to "pay a bit" for using it (and for the ProxyFor/etc. annotations,
I simply do no longer think it's a good idea to bypass the check; my
initial use case was using a naming convention "outside" the
contexts/proxies, see
http://code.google.com/p/google-web-toolkit/issues/detail?id=5761 )
We're doing two kind of things where this feature would help:
1. we need to wrap our domain objects before passing them to the
service's domain method, which means the argument types don't match what
RFIV expects (i.e. Wrapper<Domain> instead of Domain); the use case is:
we have "embedded" objects that we need to expose as EntityProxy-s; the
domain object has no reference to its owner entity, so we have to use a
"wrapper" object to pair the entity and the embedded objects (and the
path from the entity to the embedded so the "synthesized" ID has enough
information to let us implement Locator#find.
2. we add "synthetic" property methods to our proxies that don't match
any method in the domain object. The use case is described at
https://groups.google.com/d/topic/google-web-toolkit-contributors/G-O4tFXD3U4/discussion
. I forgot to mention another usage of those "synthetic", lazy-load,
methods: when the "reference" is in a sub-object and we use an RFED;
without them, we would have to retrieve the referenced entities before
we edit() or display() the "parent" object, and give the mapping between
the IDs (that we have in our domain objects) and the objects previously
retrieved (remember, via a second HTTP request!). When you have a
complex graph with several such references scatter all over, it can
become very complex; much more than those "synthetic methods".
Don't hesitate to ask if you want more info, or even source code.
We're currently bypassing the whole ResolverServiceLayer to skip the
RequestFactoryInterfaceValidator (but then resolveClientType is a bit
difficult to implement). With this patch, we would annotate our
"synthetic" property methods or otherwise "rewritten" (signature-wise)
service methods and fully benefit from the ResolverServiceLayer.
Description:
Introduces SkipInterfaceValidation annotation (I'm not too found of the
name, it could be named @Synthetic for example).
When a service method or property method in a context/proxy is
annotated, the RequestFactoryInterfaceValidator (RFIV) won't be
"poisonned" if it cannot find a compatible method in the domain object.
This patch also fixes tests, that can fail for bad reasons (Domain
mapped as EntityProxy but missing getId/getVersion/findDomain, and
that's not what's being tested) and remove the "proxyFor" property in
EntityProxyModel because it's not used anywhere.
Please review this at http://gwt-code-reviews.appspot.com/1338807/show
Affected files:
M
user/src/com/google/gwt/requestfactory/rebind/model/EntityProxyModel.java
M
user/src/com/google/gwt/requestfactory/server/RequestFactoryInterfaceValidator.java
A
user/src/com/google/gwt/requestfactory/shared/SkipInterfaceValidation.java
M
user/test/com/google/gwt/requestfactory/server/RequestFactoryInterfaceValidatorTest.java
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
