[bv-dev] BV 2.0 - Add constraints?

Gunnar Morling gunnar at hibernate.org
Wed Oct 19 06:09:21 EDT 2016 

Hi all,

The survey has closed and we got some very interesting results from it (240
answers):

* 97.9% wish for @NotEmpty
* 87.9% wish for @NotBlank
* 72.9% wish for @Positive/@Negative

What's interesting is what people put into the free text form (see below
for the full list):

* @Email is mentioned several times. As said in my blog post I'm very
skeptical about supporting it, as a) requirements around e-mail validation
are very different for different scenarios) and b) specs/RFCs around e-mail
are not necessarily consistent. Hence I'm concerned about entering a mine
field of everlasting bug reports around it.

But Emmanuel made an interesting proposal that may work: Add the @Email
constraint itself but leave the specific interpretation to BV providers.
That'd make code using it portable in terms of compilation, but runtime
behavior may differ of course. Feedback on this idea is welcome.

* Another interesting one is support for Unicode surrogate pairs (it's
mentioned several times, though I'm not sure whether that was not one and
the same person, given I've *never* heard about requests for it before).
The issue is that there are characters with a code unit greater than what
can be stored in two bytes. These are represented by "surrogate pairs",
causing for instance "𠮷".length() to return 2 and not 1 as one may expect.
Hence values given in @Size need to take that into account. I feel people
are best off with a custom validator addressing this case, but I'd be
curious to hear what others think. We may explore support in the RI.

One more theme is cross-field / simpler class-level validation support. I
hope we may address this in the course of BVAL-214.

The others seem too specific IMO or already are addressed (e.g. @EachSize).

Cheers,

--Gunnar

=====
* @Email
* @Email
* Email, URL, credit card, upper /lowercase, only numbers
* I believe @Email should also be added.
* @URL to detect if a URL is syntactically correct, e.g. for registration
purposes when a homepage should be entered.
* Email
* @EqualToField, the ability to reverse a constraint
@SomeConstraint(invert=true)
* @email would be nice for sure! @phonenumber(country=), @url, @uri
* @Digits
* I think @Email should be added. Especially because it is difficult to do
correctly if you do it manually in your project.
* 1 - for numeric field may be add @range annotation. For example; for age
field used as @range(0,100) 2 - for string field can be use @contains
annotation.
* For email another annotation can be created @BasicEmail / @SimpleEmail or
similar that could validate the most common scenarios (you can check on
github too what validations are more common) this could help 80% of the
cases and the name of the annotation is expressive enough to suggest that
should be used under certain rules. Please, although the definition of
email is too broad you can still provide something minimal and useful,
right now people is using Apache libraries (you can check that on github)
or worse dumb custom implementations.
* Something that lets me validate all items in a collection
* @Range
* Validator invoquer
* custom constraints should be possible via meta annotation
* Email should be added with default but a user can pass expression for
other validation like domain etc...
* @ValidateIf(otherProperty = "name", fulfills = [@Constraints]),
@Is("value). Most interesting validation is somewhat conditional. Often
this is just conditional on another property on the same object, either
being a value to present etc...
* @Email definitely should be added
* Validator that allows to express cross field validation expressions with
EL. Here is a SpEL (Spring Expression Language) based example:
https://github.com/jirutka/validator-spring
* I think @Email is valuable. It could have a default pattern with a
pattern attribute that could be overwritten from a set pf other pre-defined
patterns
* ISBN, Letter Case (upper,lower,camel)
* Add all that are present in proposal article. It will help to reduce
library-dependency-coupling ;) I would add as much as I can. New features
are always welcomed.
* Email, URL (w/o query string)
* Conditional validation with expression support, e.g. @NotNull if other
property is valid/has specific value. Example: when you enter an address,
the state (Alabama, Alaska, ...) has only to be entered if the country is
USA.
* @Contains("text") <- checks whether string constains given text
* @Percentage @Lookup
* @ByteMin, @ByteMax which takes charset. And I believe @Size **should take
care of surrogate pair**.
* Rather than @Positive and @Negative, @WithinRange would be more
generically useful for both and other use cases
* please consider surrogate pair to @Size
* Please consider surrogate pair to @Size.
* I hope to support surrogate pair character on @Size constraint. Some
Japanese character will be constituted by a surrogate pair. (e.g. "𠮷")
"𠮷".length() will be returned two length, However i will expect to
validate as one length. Thanks.
* Email, ISBN, Unique
* @Email, @Url, @Between for dates
* GreaterThan/LessThan instead of Positiv/Negativ
* Positive negative have a very straightforward regexp include stuff with
hard regex for example IpAddress( ipv4 or ipv6 ) @WebUrl @Image? ;)
@ValidXML and etc I am not saying add this, I am saying add validator that
you believe half of the developers will make wrong
* @Email, @PostalCode, @PhoneNumber
* Past and Future support for Java DateTime API
* Please support Surrogate Pair in @Size.
* I want you to add a surrogate pair support in @Size annotation
* Class level validation capability. Something like
http://showcase.omnifaces.org/validators/validateBean
* Regex. Can be used for all sorts of user-defined string constraints.
Including the email address sample that you wrote can't easily be
standardized, but many other cases possible.
* @Email, @Range, @URL
* @Email(value = RFC822Standard.class) with various extendable standards,
@Password with various settings, @JSONSchemaCompliant(value =
"schema.json", reader = ClasspathReader.class),
@XSDCompliant(value="schema.xsd",
reader = ClasspathReader.class)
* You should make @Size treat Unicode 'surrogate pair' specification.
* length validation with surrogate pair support
* How about allowing "simple" named groups so that we don't have to specify
the FQN in JSF?
* Surrogate Pair Support
* @EachSize, @EachPattern - using on collection, validate that every
element in collection has size between min max/is valid with specific
pattern

2016-09-16 7:47 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>
> Hi,
>
> Ah, I guess this was a bit unclear: the staging.beanvalidation.org URL
points the staging/testing instance of the website, useful if we want to
discuss or review posts before publishing them. I meant to wait for your
opinions before pushing the button and announcing it :)
>
> But as the news is out now, I've merged it to production:
http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/
>
> Please only share this link on social media etc. (and generally avoid
sharing links to staging).
>
> Thanks,
>
> --Gunnar
>
>
> 2016-09-16 1:21 GMT+02:00 Otávio Gonçalves de Santana <
otaviopolianasantana at gmail.com>:
>>
>> I sent to adopt JSR email list and share it on social media.
>> https://twitter.com/otaviojava/status/776549007799701504
>>
>>
>> On 15 Sep 2016 12:00, "Otávio Gonçalves de Santana" <
otaviopolianasantana at gmail.com> wrote:
>>>
>>> Nice form!!
>>> I'm sharing it in adopt JSR program email list.
>>>
>>>
>>> On 15 Sep 2016 03:46, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've created a survey using Google Forms on our blog (staging atm.):
http://staging.beanvalidation.org/news/2016/09/15/which-constraints-to-add/
>>>>
>>>> Feedback welcome. Unless I hear back otherwise, I'll push it to the
production site tomorrow and then let's announce it on Twitter to get some
answers. I'd leave it open for two weeks (allowing people to reply after J1
which is next week), which should be plenty of time.
>>>>
>>>> One question I have is should we allow anonymous voting or require
logging in via Google. The latter prevents double votes, but it raises the
level for participation and don't think people feel motivated to vote
several times on this topic really.
>>>>
>>>> Andy thoughts?
>>>>
>>>> Thanks,
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>> 2016-09-14 12:02 GMT+02:00 Marco Molteni <moltenma at gmail.com>:
>>>>>
>>>>> I agree about @Length. It was listed only because of the frequency.
I'd limit the addition to @NotBlank and @NotEmpty.
>>>>>
>>>>> On Wed, Sep 14, 2016 at 11:52 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>>>>>>
>>>>>> Btw. I don't see a strong reason for @Length, as we have @Size in
the spec for it already.
>>>>>>
>>>>>> I think it's commonly used in older applications which migrated from
HV 3.x (proprietary API) to HV 4.x (BV RI) and kept using the legacy
constraint instead of using the spec'-ed @Size.
>>>>>>
>>>>>> 2016-09-14 11:48 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I like the idea of collecting some more feedback from the community.
>>>>>>>
>>>>>>> A blog post may be an option, though I reckon feedback will be
sparse based on previous experiences. I'd rather do a survey as it's more
actionable for people. Either on Twitter (though that seems a bit limited)
or using Google Forms [1], which is my preference.
>>>>>>>
>>>>>>> I'll prepare something and share it with you soon. If the survey
looks good, we can promote it on Twitter and during the Hackergarten at J1
(of course talking to people in person there will be a great chance to
learn about their wishes, too).
>>>>>>>
>>>>>>> It'd be nice if we got some insight from that.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> --Gunnar
>>>>>>>
>>>>>>> [1] https://docs.google.com/forms/
>>>>>>>
>>>>>>>
>>>>>>> 2016-09-09 11:34 GMT+02:00 Marco Molteni <moltenma at gmail.com>:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> which is the best / common way to get a representative feedback
according to your experience?
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> On Thu, Sep 8, 2016 at 7:44 AM, Christian Kaltepoth <
christian at kaltepoth.de> wrote:
>>>>>>>>>
>>>>>>>>> I also think that adding the most popular 3rd party constraints
directly to the spec is a good thing. Especially @NotBlank and @NotEmpty.
>>>>>>>>>
>>>>>>>>> However, I also agree that it would be nice to gather more
feedback from the community to learn which constraints people would like to
see in the spec.
>>>>>>>>>
>>>>>>>>> 2016-09-06 20:50 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
>>>>>>>>>>
>>>>>>>>>> +1 to including them.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Michael
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 22, 2016 at 2:37 PM, Marco Molteni <
moltenma at gmail.com> wrote:
>>>>>>>>>> > Hi all,
>>>>>>>>>> >
>>>>>>>>>> > It would be possible to add some built-in constraints to the V
2.0?
>>>>>>>>>> >
>>>>>>>>>> > @NotBlank, @NotEmpty, @Length are used very often in projects,
they are
>>>>>>>>>> > already present in Hibernate Validator and their
implementation is well
>>>>>>>>>> > defined.
>>>>>>>>>> >
>>>>>>>>>> > What do you think?
>>>>>>>>>> >
>>>>>>>>>> > Here a list of the most used constraint for GitHub's projects
(the numbers
>>>>>>>>>> > change at every request but you get the idea. HV = Hibernate
Validator, BV =
>>>>>>>>>> > Bean Validation):
>>>>>>>>>> >
>>>>>>>>>> > 189'143 - BV - NotNull
>>>>>>>>>> >  56'902 - BV - Size
>>>>>>>>>> >  39'551 - HV - NotEmpty <-
>>>>>>>>>> >  20'687 - HV - NotBlank <-
>>>>>>>>>> >  17'735 - BV - Pattern
>>>>>>>>>> >  16'763 - HV - Email
>>>>>>>>>> >  16'033 - BV - Min
>>>>>>>>>> >  12'769 - HV - Length <-
>>>>>>>>>> >   7'806 - BV - Digits
>>>>>>>>>> >   4'982 - BV - Max
>>>>>>>>>> >   4'971 - BV - Past
>>>>>>>>>> >   3'598 - BV - DecimalMin
>>>>>>>>>> >   2'753 - BV - AssertTrue
>>>>>>>>>> >   2'379 - BV - DecimalMax
>>>>>>>>>> >   2'308 - BV - Future
>>>>>>>>>> >   1'999 - HV - Range
>>>>>>>>>> >   1'497 - HV - URL
>>>>>>>>>> > < 1'000 other constraints
>>>>>>>>>> >
>>>>>>>>>> > Thanks
>>>>>>>>>> >
>>>>>>>>>> > Cheers
>>>>>>>>>> >
>>>>>>>>>> > Marco
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > beanvalidation-dev mailing list
>>>>>>>>>> > beanvalidation-dev at lists.jboss.org
>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> beanvalidation-dev mailing list
>>>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christian Kaltepoth
>>>>>>>>> Blog: http://blog.kaltepoth.de/
>>>>>>>>> Twitter: http://twitter.com/chkal
>>>>>>>>> GitHub: https://github.com/chkal
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> beanvalidation-dev mailing list
>>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> beanvalidation-dev mailing list
>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161019/f067588b/attachment-0001.html

More information about the beanvalidation-dev mailing list