-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 13 posts ] 
Author Message
 Post subject: Should we have more built-in annotations?
PostPosted: Mon Jan 12, 2009 6:03 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
Hi all,
The EG is wondering if we should add more built-in constraints in the spec. The rational for built-in constraints is that they can be interpreted by non java frameworks via composing constraints and the metadata query API.

We are wondering if adding a string comparison constraint makes sense:
- @Like(value="%test%" case=INSENSITIVE)
Questions: which locale for INSENSITIVE?
=> this can be matched by DDL and JavaScripts

- @Pattern(regexp="")
Questions: which locale for INSENSITIVE?
=> extracting something from a Regexp usable by DDL (and to a certain extend JS) is hard. This might end up being an unusable back box.



Also some people are asking for @Email
While it makes sense and while I expect BV providers to provide such a constraint, should it be standardized?
My main concern is that the email RFC is quite lose. For examples, emails wo domain are valid: "emmanuel", "emmanuel@hibernate.org" are valid emails
In most cases, the former is not very interesting for applications.

What do you think?

_________________
Emmanuel


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Tue Jan 20, 2009 1:54 pm 
Newbie

Joined: Fri Jul 27, 2007 10:03 am
Posts: 1
Maybe you should ask if is necessary to define all this annotation in JSR 303? For example a kind of @Null or @NotNull annotation is too generic, from my point of view both of them belong to SDK. Now it seems that the same annotations are also defined in JSR 305 (http://jcp.org/en/jsr/detail?id=305). Is there some who coordinates it over various JSRs?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 27, 2009 4:27 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
no I discussed to Bill and the @NotNull of 305 is not the @NotNull of 303. Semantically different.

_________________
Emmanuel


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Wed Jan 28, 2009 8:51 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
- @Pattern(regexp="")
Questions: which locale for INSENSITIVE?
=> extracting something from a Regexp usable by DDL (and to a certain extend JS) is hard. This might end up being an unusable back box.


Regexpes are mostly standardised on either Perl or POSIX, we could make this an annotation parameter.

emmanuel wrote:
Also some people are asking for @Email
While it makes sense and while I expect BV providers to provide such a constraint, should it be standardized?
My main concern is that the email RFC is quite lose. For examples, emails wo domain are valid: "emmanuel", "emmanuel@hibernate.org" are valid emails
In most cases, the former is not very interesting for applications.


Make this a parameter: allowLocal or however it's called in the RFC. AFAIR there are only local or non-local addresses.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 09, 2009 2:15 pm 
Newbie

Joined: Fri May 26, 2006 6:07 am
Posts: 5
i think it's better to have more annotation including those that are likely to have different definition/specification such as @Email, @CountryCode (just for example), and let the implementation to decide how to implement the default, and provide option to customize the rules. It's better than depend on vendor specific annotation or use regex patterhn.


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Mon Jun 15, 2009 9:46 am 
Newbie

Joined: Thu May 28, 2009 12:28 pm
Posts: 11
I think that's a good idea.


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Wed Jun 17, 2009 1:29 pm 
Newbie

Joined: Wed Jul 25, 2007 6:33 pm
Posts: 9
Personally, I like the idea of creating annotations that describe the constraint in terms of what the data is, rather than apply generic annotations, such as regular expressions or simple patterns. So maybe 303 could avoid including a pattern type.

In terms of what you could include, I deal a lot with phone numbers and phone number validation and would like to see a validator for them.

But as you know there are hundreds of ways for phone number validation to work. For example, in some countries, certain area codes have different numbers of digits. You might want to validate to this level. And when you're building an application for a specific Locale, you don't want to ask for the country code each time, use some sort of default country of the user or installation.

None of this could really be done through DDL, but I think Javascript could potentially support an equal level of validation as a Java implementation.

When validation is important, though what ultimately is required is a specific data type e.g. com.example.PhoneNumber instead of java.lang.String. For e-mail, you use javax.mail.Address. I still haven't figured out how 303 cooperates well with user types.


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Thu Jul 23, 2009 10:11 am 
Regular
Regular

Joined: Thu Oct 13, 2005 4:19 am
Posts: 98
You should have more, if and only if, they are well defined:
- @Email
- SEPA (the new european standard to pay): @IBAN & @BIC

I don't think a éTelephone is a good idea because it is not well defined

_________________
http://www.ohloh.net/accounts/ge0ffrey


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Mon Sep 21, 2009 8:22 am 
Newbie

Joined: Thu Aug 27, 2009 8:21 am
Posts: 13
Hi Guys,

Thanks for all the good work on all this stuff. I'm about to introduce it to a big project I'm working on and reaction so far seems quite positive.

Given @Pattern you don't really need @Email or @Telephone or other similar validations because finding a regex implementing the standard is fairly easy.

I would like to see something like @Unique for collections. Perhaps this could take a comparitor as an argument and default to calling equals() if one isn't provided. @NotEmpty for strings and collections would be convenient, or perhaps this should be called @Required and have a wider scope than @NotNull.

And, although it could get really messy, a way of relating one field to another would be really nice. This might look something like this:

@LessThan("fieldB")
private int fieldA;

@Name("fieldB")
private int fieldB;

The problem here is that you can't do this in a nice way because there is no facility in java for attribute or method references. One solution, as shown here, is to provide an arbitary name for an attribute so that it can be referenced elsewhere -- this would survive refactoring (in Idea refactoring the attribute, fieldB, would also refactor the string references to it, but I don't know if this is true for eclipse).

Using something like this we could provide validation for one field in reference to another, which is, I think, quite a common requirement.

Bryan


Top
 Profile  
 
 Post subject: Luhn algorithm
PostPosted: Mon Dec 14, 2009 4:51 am 
Beginner
Beginner

Joined: Mon Dec 14, 2009 12:26 am
Posts: 23
Anything easily implemented using a regexp should probably be left to that purpose. Libraries can easily provide patterns, or their own additional annotations, and making them a part of the standard when there's no clear benefit seems questionable.

One thing I *do* think is so common that it should be included is a check verifying that the integer argument passes a Luhn algorithm test. It's not amenible to regexp-based implementation. A Luhn algorithm check when combined with a length test can verify a CCN as at least potentially valid, but the Luhn algorith is used for all sorts of other things, including all sorts of business registration numbers in various countries. It's not tough to implement and requires little code, but it's something that a one-liner @Luhn annotation would be very handy for. See: http://en.wikipedia.org/wiki/Luhn_algorithm. People are sure to ask for CCN validation, and this lets it be done with code that's also useful for all sorts of other things.

Another that would be useful would be an annotation to check a string against the Luhn algorithm after conversion to long by stripping all non-digit chars (by default) or an argument-specified list of "ignored" chars if one is given. Eg: @LuhnString(ignore="-_ ") .

(Any implementation should avoid string chopping in its implementation. It's easily properly implemented using purely arithmetic operations, though most examples show the string-chopping method. I'll post a simple method shortly.)

By contrast, @Email in particular seems unwise, IMO. There are just too many different addressing rules, and they're sure to continue changing over time. Let people choose how strict they want to be and what set of rules they wish to obey by using an appropriate regexp with pattern validation.

I'd like to see an annotations library that suppliements the standard with a more flexible, but non-standardized, set of commonly used annotations such as various strictness levels of email validation, credit card number validation, ISBNs, Australian Company Number, Australian Business Number, etc etc. Something that can be built and included class file by class file in a modular manner, so apps aren't burdened with shipping huge chunks of unnecessary code as would be the case if all these were part of the JSR.

I've been pretty happy with what Hibernate Validator (as JSR303) provides as shipped. The only validator classes I've had to add are ones for ABNs and ACNs (as the app is mostly for Australian use) and some Luhn-algorithm based checks for some app-specific values where I use the Luhn algorithm to detect typos and miscommunication of ID numbers.


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Mon Dec 14, 2009 4:57 am 
Beginner
Beginner

Joined: Mon Dec 14, 2009 12:26 am
Posts: 23
This isn't beautiful, but it's better than string splitting implementations. Feel free to take it and make of it what you will.

Code:
/**
* Verify Luhn Algorithm check digits
*
* @author Craig Ringer <ringerc@gmail.com>
*/
public class LuhnAlgorithm {

    /**
     * Given the input `l' which has a Luhn check digit,
     * return true if the Luhn checksum test passes or false
     * otherwise.
     *
     * See http://en.wikipedia.org/wiki/Luhn_algorithm
     *
     * @param l Input with check digit
     * @return true if check digit correct for input
     */
    public static boolean verify(long n) {
        if (n < 10)
            return false;
        long s = 0;
        for (long i = 0L; i < Math.ceil(Math.log10(n)); i++) {
            // Extract a digit and double it
            final long doubled = ((n / (long)Math.pow(10L,i)) % 10L) * (i % 2L + 1L);
            // Add the value of each digit of the result to the running
            // total. If the result is, eg `12', we'd add 3 : 1+2=3.
            s += doubled % 10L + doubled / 10L;
        }
        return s % 10 == 0;
    }

    /**
     * Strip the Luhn check digit from a number. Of course, this is just a
     * division by 10... but this way you can see why.
     * @param n Luhn-check-digit-containing value
     * @return Value without check digit
     */
    public static long stripCheckDigit(long n) {
        return n / 10;
    }

}



Code:
/**
* JUnit tests for LuhnAlgorithm.java
*/
public class LuhnAlgorithmTest {

    private static final long[] okLuhns = {
                      10L,
         378282246310005L,
         371449635398431L,
         378734493671000L,
        5610591081018250L,
          30569309025904L,
          38520000023237L,
        6011111111111117L,
        6011000990139424L,
        3530111333300000L,
        3530111333300000L,
        3566002020360505L,
        5555555555554444L,
        5105105105105100L,
        3530111333300000L,
        4111111111111111L,
        3530111333300000L,
        4012888888881881L,
           4222222222222L,
        2323200577663554L,
        1234567812345670L
    };

    private static final long[] badLuhns = {
        -1L, 0L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L
    };

    public LuhnAlgorithmTest() {
    }

    @BeforeClass
    public static void setUpClass() throws Exception {
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
    }

    @Before
    public void setUp() {
    }

    @After
    public void tearDown() {
    }

    /**
     * Test of verify method, of class LuhnAlgorithm.
     */
    @Test
    public void testVerify() {
        System.out.println("verify");
        for (long l : okLuhns) {
            assertTrue( LuhnAlgorithm.verify(l));
        }
        for (long l : badLuhns) {
            assertFalse( LuhnAlgorithm.verify(l) );
        }
    }

}


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Wed Jan 13, 2010 11:23 pm 
Regular
Regular

Joined: Wed Jun 30, 2004 4:02 pm
Posts: 64
I've been reviewing the HTML5 spec and they document validation strategy for Email and URL. They also note that they specifically violate prior definitions with good reason. This seems like the right spec to adhere to as web apps will be using input type="email" and type="url" binding to fields marked @Email and @URL in the validator.

http://www.whatwg.org/specs/web-apps/cu ... mail-state
"A valid e-mail address is a string that matches the ABNF production 1*( atext / "." ) "@" ldh-str 1*( "." ldh-str ) where atext is defined in RFC 5322 section 3.2.3, and ldh-str is defined in RFC 1034 section 3.5. [ABNF] [RFC5322] [RFC1034]

This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, white space characters, and quoted strings in manners unfamiliar to most users) to be of practical use here."

http://www.whatwg.org/specs/web-apps/cu ... #valid-url
"The term "URL" in this specification is used in a manner distinct from the precise technical meaning it is given in RFC 3986. Readers familiar with that RFC will find it easier to read this specification if they pretend the term "URL" as used herein is really called something else altogether. This is a willful violation of RFC 3986. [RFC3986]"


Top
 Profile  
 
 Post subject: Re: Should we have more built-in annotations?
PostPosted: Sun Mar 20, 2011 10:49 pm 
Beginner
Beginner

Joined: Wed Feb 16, 2005 1:22 am
Posts: 25
Location: Jakarta
Hello,

Im a newcomer to Bean Validation, and would be happy to see more built-in annotations ! :-)

A list of ideas that come to mind :

- The date must be today (i tried combining @Past and @Future, ended up with failure, haha)
- With numbers we got the min and max, but i think the comparison is needed also, for example, the quantity for double must be > 0, could be 0.1, 0.001. Cannot use @Min in here.
- @Email, @Url, @Number : The suggestion from one of the replies here on being able to have several implementations (or even perhaps combine it using OR), or provide own's implementation would be cool.
- Reusing available complex annotation rules that's already defined somewhere else to avoid duplication @ValidationRule(type=my.package.MyClass, attribute="myAnnotatedProperty") ?

Thank you for your all hardworks !

_________________
Greater in battle
than the man who would conquer
a thousand-thousand men,
is he who would conquer
just one —
himself.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 13 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.