I know it is, but the idea to have direct support is that constraint
violations must be translated properly in order to make it back to the
UI, I'm talking mainly about the editor framework here. Currently, a
first pass is done to validate, any constraints are translated and
then the service metho
>
> If I would have to choose, I would definitely go for "invocation to
> return both validation errors and a result object".
ContraintViolationExcpetion, is serializable, but it does not return the the
"root" object. see
http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/
On Fri, Nov 5, 2010 at 11:35 AM, BobV wrote:
> Just to be explicit, this is just the first in a series of patches to
> graduate RequestFactory from toy status into something that's usable
> with real systems.
understood.
>
> http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1
>
Just to be explicit, this is just the first in a series of patches to
graduate RequestFactory from toy status into something that's usable
with real systems.
http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1
On Fri, Nov 5, 2010 at 11:21 AM, Patrick Julien wrote:
> I think thi
I think this is still missing one core feature that makes it unusable.
The problem is still validators. ConstraintViolation cannot be
returned or thrown from our methods which means only the default group
validation can be used.
e.g., let's say we have a UserAccount. Depending if the user has a
Reviewers: rjrjr,
Description:
Overhaul the RequestFactory server code.
Make RequestFactory usable from non-GWT code.
http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1
Move AutoBeans to a top-level package and add AutoBeanCodex.
Add explicit support for Collections and Maps t
