Re: Handling Violations controlled by groups or Violations not found by default validation

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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
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.