Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@mkurz
Copy link
Member

@mkurz mkurz commented May 4, 2016

Now that we finally can use as many validation groups in forms as we want (#6124), there is one thing I would consider a bug.

Right now, when you retrieve a field from a form (via myForm.field("fieldname")), we always return the field with all of its constraints, no matter if we told the form to use a specific validation group or not.
This is wrong.
If you create a form and tell it to use (a) specific validation group(s) then only the constraints should be added (to a field) which match any of the validation groups the form actually currently uses.
For example if you display all fields of a form in a view, and all fields contain the @Required constraint, but some of this constraints use a specific validation group like @Required(groups = MyGroup.class) and you create the form via formFactory.form(myForm.class, MyGroup.class) then in the view only the fields should display the required constraint ("This field is required") who's required annotation actually matches the group - because of course all other fields are actually not required for the current form submission scenario (and of course don't raise a validation error if they are empty on submission).
Right now always all constraints get added/shown.

Fortunately we can make use of the unorderedAndMatchingGroups method which does exactly what we want. (javadoc) More on it's usage can also be found in the hibernate validation docs here and the Bean Validation specification here (just grep for unorderedAndMatchingGroups)

One more thing: When no groups are used, we still need to supply the Default.class group, because that's what is getting used by default by the .validate(...) method we use here:

the group or list of groups targeted for validation (defaults to Default)

(From the javadocs [here](http://docs.jboss.org/hibernate/beanvalidation/spec/1.1/api/javax/validation/Validator.html#validate%28T, java.lang.Class...%29))

We already use the change of this PR in our own custom Play 2.5.4-SNAPSHOT build since two days and it is working like a charm.

@mkurz
Copy link
Member Author

mkurz commented May 4, 2016

Also, this should be backported to the 2.5.x branch.

@marcospereira
Copy link
Member

@mkurz, could you please add some tests here?

@mkurz mkurz added this to the 2.5.4 milestone May 6, 2016
@mkurz
Copy link
Member Author

mkurz commented May 6, 2016

Tests are coming soon. I assigned the next 2.5.x milestone. After this PR there will come another one...

@mkurz mkurz self-assigned this May 10, 2016
@mkurz mkurz force-pushed the constraintGroupFixMaster branch from 3af94a2 to 5f2d28e Compare June 1, 2016 21:52
@mkurz
Copy link
Member Author

mkurz commented Jun 1, 2016

Added tests.
Ready for review and merge.

@mkurz
Copy link
Member Author

mkurz commented Jun 1, 2016

Also it needs backport to 2.5.x

@gmethvin gmethvin merged commit 18340e4 into playframework:master Jun 2, 2016
@mkurz mkurz deleted the constraintGroupFixMaster branch June 2, 2016 07:06
@mkurz
Copy link
Member Author

mkurz commented Jun 2, 2016

2.5.x: 3a242af

@mkurz mkurz removed their assignment Jun 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants