* @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).
* @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@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@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@gmail.com> wrote:
>>>
>>> Nice form!!
>>> I'm sharing it in adopt JSR program email list.
>>>
>>>
>>> On 15 Sep 2016 03:46, "Gunnar Morling" <gunnar@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@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@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@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@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@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@gmail.com>:
>>>>>>>>>>
>>>>>>>>>> +1 to including them.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Michael
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 22, 2016 at 2:37 PM, Marco Molteni <moltenma@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@lists.jboss.org
>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> beanvalidation-dev mailing list
>>>>>>>>>> beanvalidation-dev@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@lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> beanvalidation-dev mailing list
>>>>>>>> beanvalidation-dev@lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>