>From the point of view of RF, these are just an exception thrown by the
service method, like any other.
If you want to communicate failure to your client with specific
information, then you have to make your service method return a response
object containing the status (success/failure) and the details about the
failure. onFailure is about *exceptional cases*, i.e. things that should
*not* happen.
If it were me, I'd remove bean validation from RF entirely. It was useful
when and meaningful when RF had optimistic locking (back in its really
early days in the first GWT 2.1 milestones), but currently it's just
confusing: because you send a diff, validation could fail not because you
failed on the client-side, but because someone else modified a field that
you didn't touch, and now conflicts with a field you modified on the
client; now how do you fix that?
Keep RF automatic validation only for field-level syntactic / range
validation, not for anything else; and for "business rules" inside service
methods, they're just errors like any other, so treat them as such (see
above)
On Tuesday, May 21, 2013 4:13:52 PM UTC+2, Alex opn wrote:
>
> Thanks for your answer!
>
> Well...propably I'm abusing bean validation (?), but in my case that
> doesn't help (actually I'm already doing it like this with different
> groups).
>
> I'll try to explain my problem:
>
> Basically I've got two validation groups which both should be run on the
> server-side: Client and Server
>
> Client: These validators should be run when an object enters the server
> from the client (in the ServiceLayerDecorator)
> Server: These validators should be run before persist / update etc happens
> (in my DAOs)
>
> The reason why I separated it like this is that there are some class level
> constraints which may be violated when an object enters the server that
> should get corrected in the service method afterwards, but for safety be
> checked again before updating the database.
>
> So far that works good and was pretty easy to implement:
>
> ServiceLayerDecorator:
>
> @Override
> public <T> Set<ConstraintViolation<T>> validate(T domainObject) {
> return validator.validate(domainObject, Client.class);
> }
>
> But ViolationExceptions occuring later are, as Michael already explained
> pretty well, reported as ServerFailures, not as ConstraintViolations ->
> non-resusable RequestContext, no error messages shown etc :-/
>
> I already tried to copy/paste SimpleRequestProcessor &
> RequestFactoryServlet (into com.google... package structure) to change it
> to my needs. I have to admit though that I couldn't figure out how to catch
> all exceptions and not handle ConstraintViolationExceptions as server
> failures. I would already be happy with that although it feels a bit hacky
> :)!
>
> Am Dienstag, 21. Mai 2013 14:58:32 UTC+2 schrieb Jens:
>>
>> By default, GWT calls validator.validate(domain) in
>> ReflectiveServiceLayer.validate(), but you probably want
>>
>> if(domain.getId() == null) {
>> return validator.validate(domain, CreateGroup.class);
>> }
>> return validator.validate(domain, Server/DefaultGroup.class);
>>
>> You can do this by providing a custom ServiceLayerDecorator to
>> RequestFactoryServlet and implement ServiceLayerDecorator.validate(T
>> domain) accordingly.
>>
>> -- J.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
