On Monday, April 23, 2012 2:57:09 PM UTC+2, Tiago wrote: > > Hello Thomas, > > On Monday, April 23, 2012 11:49:54 AM UTC+2, Thomas Broyer wrote: >> >> In RequestFactory's design, onFailure is really an exception, and should >> never happen: errors should be conveyed as special return values. That >> doesn't quite change your issue here, as the proxy wouldn't be reusable >> either: that's because, again, RF has been designed with the idea that >> things shouldn't go wrong. For instance, unique constraint violations are >> not natural for (most / non-technical) users. Moreover, those kind of >> conditions should probably be detected as ConstraintVIolations so the user >> can "fix the proxy" and "resubmit his request". >> > > Could you help me a bit more by pointing to an example of what do you mean > by "detected as ConstraintViolation"? > I have a situation where the user must attribute a reference value to an > entity, and this value must be unique. I can only know if it's unique after > my service is called and either I attempt an insert and treat the > exception, or if I make a previous select before the insert (very low risk > of concurrence issues for my case, I think I could safely ignore such > risk). In either case, the request is already gone and the service has > already been called. From what I understood by reading the previous thread > I linked to, it is already too late to reuse the proxy. >
You can use a custom JSR303 validator that does the select and the check; so that in case of a unique constraint violation, a ConstraintViolation would be sent back to the client (and in this case, the proxy is unfrozen so it can be "fixed" before firing the RequestContext again). > By the way, I was not using onFailure as you say it should be used. I was > using it for general business failures. We've even implemented a generic > Receiver to deal with that. Not challenging what you say, but it really > doesn't look like RF was built with the idea that errors should be treated > in the return value... the return value most of the time is a proxy (or > Collection of proxies) to an entity used in the back-end. Entities are not > supposed to have request-specific error data. Basically, to operate like > that, I would need different DTOs for every request, and proxy these DTOs, > which would contain the needed entities plus error information. Is that how > RF is supposed to be used? > When your service method has "error paths", yes; but the main idea is that there should as few as possible. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/CBDzv45Cy4AJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
