Pass a list of changes applied to an object graph and validate the object graph had the change been applied.
This is useful for presentation layers like JSF for cross field validations for example.
There are several possibilities to implement that:
1. pass in a Map<String,Object> with the list of changed properties
2. pass in a set of more typesafe changedset but essentially the same as 1.
3. pass a proxy of the object and apply changes to the proxy. One of the benefits of this approach is that it is transparent to the validator API. The drawback is that the object must be proxyable
More info from Alex
Client side validation already implemented in coming RichFaces 4.0 release, that's not a subject for bean validation. From the JSF side, the cool feature would be object validation that doesn't touch model itself. Currently, we can only validate a single bean attribute aganist new value, that doesn't allow. In richfaces, I do make a 'clone' of target object, update it with new values and perform validation on the cloned object. Would be nice to have something like: validator.validateObject(Object model,Map<String,Object> newValues, Class ...profile) that does a similar work.
Must have. Not being able to use class-level constraints with JSF is an issue I think many people are missing.
I need this too
BTW a nicer option 2 can look like
What do you mean exactly by a proxy-based solution, something like CGLib or Java dynamic proxies?
If yes, I think that would be to restrictive, for example a lot of our model/bean classes are final and don't implement a particular interface.
BTW, our use case would be a rich client scenario where validation happens on the buffered values of a presentation model.
I think my personal preference would be option 2. (although my first thought about such a solution resulted in something like option 1.)
Please consider this for 2.0. Thanks!
Yes, the proxy approach would impose some requirements towards validated beans, e.g. having a default constructor, being non-final and such. It could be made pluggable, though, allowing to provide custom strategies specific to your bean types.
That being said I'm more leaning towards a de-typed approach (a bit like 2). But this will need more exploration and I don't think we can do it in the time remaining for 2.0. We can explore it in the reference implementation, though, so it can be added in a future revision. If you feel adventurous, you may give it a try and create a PoC within Hibernate Validator?