Bean Validation (JSR-303) support

Hi,

I am working on a strategy for my current project to integrate my Java and Flex domain model in an efficient manner.

I was wondering whether there is a feature planned or if somebody implemented a solution that would provide support for using Bean Validation (JSR-303) annotations on the server-side and in your Flex client. I guess this technically boils down to 3 scenarios (any combination of those possible):

1) Pure bean validation support on the Flex client (aka Hibernate Validator as an ActionScript implementation) - It looks like GraniteDS has something that goes into the direction: http://www.graniteds.org/confluence/...+%28JSR-303%29

2) Model objects are validated on the server-side: How to pass back those validation errors in a "best-practice" way. (Which also integrates with Flex' validation support (?))

3) Generating Flex ActionScript model objects from the Java domain model that also generate the bean validation support. E.g. I am using the DTO2FX Eclipse plugin from the Clear Toolkit project (http://sourceforge.net/projects/cleartoolkit) (but that one does not support generating Bean Validation code.

Thus, how have you handled validation in your Flex/BlazeDS/Spring applications? Did you even bother dealing with JSR-303 Bean Validation or just manually duplicated the logic?

Is this something, where Spring Flex or Spring ActionScript could provide better support in the future?

The "Spring Roo Flex Add-on" seems to already support some of this:
https://jira.springsource.org/browse/ROOFLEX-12

Can this be used outside of Roo?

Cheers,

Gunnar

I've only briefly looked at the Granite support, but I have to say it does look like a decent solution. It seems it could be simply integrated into any of the currently popular MVP style approaches, alongside Spring ActionScript, Swiz, etc. I don't buy into a lot of what Granite does (i.e., all of their additional client-side APIs for doing remoting, etc.), but certain parts of the project like this have proven to be usable as independent utilities.

As for validating on the server-side, one of the major benefits of a framework like Flex is that you can often apply the majority of your validation on the client, thus saving latency-inducing round-trips to the server, and I would strive to do that as much as possible for the best user experience. I've seen various approaches for the cases where you do need to validate on the server. One that makes sense to me is to actually throw an exception in the case of a validation error so that you can process it in your client-side error handler rather than having to do type checking and branching in the result handler.

With Spring BlazeDS's ExceptionTranslator and MessageInterceptor, you can get fairly clever about this. You could for example invoke the bean validation generically in a MessageInterceptor, thus keeping the validation code out of your services, then if necessary use the ExceptionTranslator to ensure the error that gets thrown back to the client contains the necessary information (you could of course skip that step altogether and just throw a MessageException from the MessageInterceptor in the first place).

As for upcoming enhancements, the Roo addon has definitely been (and will continue to be) our focus for how to elegantly handle this. That support does indeed require the use of Roo. One thing to look forward to is that the Roo team is focusing a lot on improving the extensibility model for addons, so if the way we do it currently doesn't fit your needs, you should hopefully in the future be able to customize to your liking via extensions.