Ability to validate an object and a list of changes

Description

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.

Environment

None

Activity

Show:
Gunnar Morling
September 26, 2011, 11:02 PM

Must have. Not being able to use class-level constraints with JSF is an issue I think many people are missing.

Dyego Souza do Carmo
September 13, 2012, 10:28 PM

I need this too

Emmanuel Bernard
January 27, 2016, 3:31 PM

BTW a nicer option 2 can look like

Holger Brands
April 17, 2017, 11:16 AM

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!

Gunnar Morling
April 21, 2017, 8:20 AM

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?

Assignee

Gunnar Morling

Reporter

Emmanuel Bernard

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Fix versions

Priority

Major
Configure