constraint proposal

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

constraint proposal

Jeff Scott Brown-2
While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...

class Widget {
    
    @Constrained({[range:5..10]})
    Integer size
    
    @Constrained({[size:5..10, matches: /[A-Z].*/]})
    String name
}

@TestMixin(GrailsUnitTestMixin)
class ConstrainedAnnotationSpec extends Specification {

    void 'test a single constraint'() {
        when:
        def obj = new Widget(size: 2)
        
        then:
        !obj.validate()
        
        and:
        obj.errors.getFieldError('size').code == 'range.toosmall'
        
        when:
        obj.size = 9
        
        then:
        obj.validate()
    }
    
    void 'test multiple constraints'() {
        when:
        def obj = new Widget(name: 'short')
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'matches.invalid'
        
        when:
        obj.name = 'Long'
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'size.toosmall'
        
        when:
        obj.name = 'Short'
        
        then:
        obj.validate()
    }
}

All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with “range” is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...

What say ye?



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166  
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

Graeme Rocher-2
Don't like it personally, never wanted Grails to be an annotation
driven framework and annotations were always something I wanted to
keep simple and used sparingly (@Transactional, @AsyncDelegate etc.)

Cheers

On Fri, Mar 14, 2014 at 5:33 AM, Jeff Scott Brown <[hidden email]> wrote:

> While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...
>
> class Widget {
>
>     @Constrained({[range:5..10]})
>     Integer size
>
>     @Constrained({[size:5..10, matches: /[A-Z].*/]})
>     String name
> }
>
> @TestMixin(GrailsUnitTestMixin)
> class ConstrainedAnnotationSpec extends Specification {
>
>     void 'test a single constraint'() {
>         when:
>         def obj = new Widget(size: 2)
>
>         then:
>         !obj.validate()
>
>         and:
>         obj.errors.getFieldError('size').code == 'range.toosmall'
>
>         when:
>         obj.size = 9
>
>         then:
>         obj.validate()
>     }
>
>     void 'test multiple constraints'() {
>         when:
>         def obj = new Widget(name: 'short')
>
>         then:
>         !obj.validate()
>         obj.errors.getFieldError('name').code == 'matches.invalid'
>
>         when:
>         obj.name = 'Long'
>
>         then:
>         !obj.validate()
>         obj.errors.getFieldError('name').code == 'size.toosmall'
>
>         when:
>         obj.name = 'Short'
>
>         then:
>         obj.validate()
>     }
> }
>
> All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with "range" is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...
>
> What say ye?
>
>
>
> JSB
>
> --
> Jeff Scott Brown
> [hidden email]
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

zyro
AnnotationValidationGrailsPlugin ? :)

what would be cool imho, if there was a option to "understand" bean
validation annotations as well, e.g. mapping them somehow to grails
constraints...

zyro

-------- Original Message  --------
Subject: Re: [grails-dev] constraint proposal
From: Graeme Rocher <[hidden email]>
To: [hidden email] <[hidden email]>
Date: Fri, 14 Mar 2014 08:44:14 +0100

> Don't like it personally, never wanted Grails to be an annotation
> driven framework and annotations were always something I wanted to
> keep simple and used sparingly (@Transactional, @AsyncDelegate etc.)
>
> Cheers
>
> On Fri, Mar 14, 2014 at 5:33 AM, Jeff Scott Brown <[hidden email]> wrote:
>> While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...
>>
>> class Widget {
>>
>>      @Constrained({[range:5..10]})
>>      Integer size
>>
>>      @Constrained({[size:5..10, matches: /[A-Z].*/]})
>>      String name
>> }
>>
>> @TestMixin(GrailsUnitTestMixin)
>> class ConstrainedAnnotationSpec extends Specification {
>>
>>      void 'test a single constraint'() {
>>          when:
>>          def obj = new Widget(size: 2)
>>
>>          then:
>>          !obj.validate()
>>
>>          and:
>>          obj.errors.getFieldError('size').code == 'range.toosmall'
>>
>>          when:
>>          obj.size = 9
>>
>>          then:
>>          obj.validate()
>>      }
>>
>>      void 'test multiple constraints'() {
>>          when:
>>          def obj = new Widget(name: 'short')
>>
>>          then:
>>          !obj.validate()
>>          obj.errors.getFieldError('name').code == 'matches.invalid'
>>
>>          when:
>>          obj.name = 'Long'
>>
>>          then:
>>          !obj.validate()
>>          obj.errors.getFieldError('name').code == 'size.toosmall'
>>
>>          when:
>>          obj.name = 'Short'
>>
>>          then:
>>          obj.validate()
>>      }
>> }
>>
>> All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with "range" is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...
>>
>> What say ye?
>>
>>
>>
>> JSB
>>
>> --
>> Jeff Scott Brown
>> [hidden email]
>>
>> Autism Strikes 1 in 166
>> Find The Cause ~ Find The Cure
>> http://www.autismspeaks.org/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>      http://xircles.codehaus.org/manage_email
>>
>>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

Owen Rubel
In reply to this post by Jeff Scott Brown-2
Totally dig it. Am seeing constraints more and more as common reuseable code snippets like this.

It would be better if we had an anno map for when we had 5 or 6 annos per method to simplify the classes :)

Owen Rubel
415-971-0976
[hidden email]


On Thu, Mar 13, 2014 at 9:33 PM, Jeff Scott Brown <[hidden email]> wrote:
While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...

class Widget {
    
    @Constrained({[range:5..10]})
    Integer size
    
    @Constrained({[size:5..10, matches: /[A-Z].*/]})
    String name
}

@TestMixin(GrailsUnitTestMixin)
class ConstrainedAnnotationSpec extends Specification {

    void 'test a single constraint'() {
        when:
        def obj = new Widget(size: 2)
        
        then:
        !obj.validate()
        
        and:
        obj.errors.getFieldError('size').code == 'range.toosmall'
        
        when:
        obj.size = 9
        
        then:
        obj.validate()
    }
    
    void 'test multiple constraints'() {
        when:
        def obj = new Widget(name: 'short')
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'matches.invalid'
        
        when:
        obj.name = 'Long'
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'size.toosmall'
        
        when:
        obj.name = 'Short'
        
        then:
        obj.validate()
    }
}

All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with “range” is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...

What say ye?



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

cdeszaq
I agree with Graeme. I find annotations irritating, in general, particularly when they start to stack up. To me, they obscure the code, and never really seem to have the benefit of "decoupling" the code the way that they are supposed to. Annotations feel too much like configuration that is just embedded in the code.

On the other hand, I am all for giving more compile-time checking (and static compilability) to Grails (and groovy in general). I think, like Zyro said, adding this as a plugin makes a lot of sense.

I must confess, I've done a bit of dabbling with Scala and Play recently, and while Groovy and Grails still win, the rich type system in Scala (without the ugly syntax) and the "async by default" nature of Play would make groovy and Grails just about perfect.

- Rick



On Fri, Mar 14, 2014 at 4:01 PM, Owen Rubel <[hidden email]> wrote:
Totally dig it. Am seeing constraints more and more as common reuseable code snippets like this.

It would be better if we had an anno map for when we had 5 or 6 annos per method to simplify the classes :)

Owen Rubel
<a href="tel:415-971-0976" value="+14159710976" target="_blank">415-971-0976
[hidden email]


On Thu, Mar 13, 2014 at 9:33 PM, Jeff Scott Brown <[hidden email]> wrote:
While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...

class Widget {
    
    @Constrained({[range:5..10]})
    Integer size
    
    @Constrained({[size:5..10, matches: /[A-Z].*/]})
    String name
}

@TestMixin(GrailsUnitTestMixin)
class ConstrainedAnnotationSpec extends Specification {

    void 'test a single constraint'() {
        when:
        def obj = new Widget(size: 2)
        
        then:
        !obj.validate()
        
        and:
        obj.errors.getFieldError('size').code == 'range.toosmall'
        
        when:
        obj.size = 9
        
        then:
        obj.validate()
    }
    
    void 'test multiple constraints'() {
        when:
        def obj = new Widget(name: 'short')
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'matches.invalid'
        
        when:
        obj.name = 'Long'
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'size.toosmall'
        
        when:
        obj.name = 'Short'
        
        then:
        obj.validate()
    }
}

All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with “range” is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...

What say ye?



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

Jonathan Stott-5
The only value that I can see for annotation-based constraints is that the rules are then written next to the field rather than in a constraints block somewhere else. I'd be in favour of having annotation based constraints for the normal things and then using the constraints block for custom validations only. In my view, the annotations would then work like an extension to the type of the field, i.e. this is a String, but it's a string that is 1-255 chars long (much like how some languages have the "unsigned" keyword to constrain the type).

Jonathan


On 14 March 2014 22:10, Rick Jensen <[hidden email]> wrote:
I agree with Graeme. I find annotations irritating, in general, particularly when they start to stack up. To me, they obscure the code, and never really seem to have the benefit of "decoupling" the code the way that they are supposed to. Annotations feel too much like configuration that is just embedded in the code.

On the other hand, I am all for giving more compile-time checking (and static compilability) to Grails (and groovy in general). I think, like Zyro said, adding this as a plugin makes a lot of sense.

I must confess, I've done a bit of dabbling with Scala and Play recently, and while Groovy and Grails still win, the rich type system in Scala (without the ugly syntax) and the "async by default" nature of Play would make groovy and Grails just about perfect.

- Rick



On Fri, Mar 14, 2014 at 4:01 PM, Owen Rubel <[hidden email]> wrote:
Totally dig it. Am seeing constraints more and more as common reuseable code snippets like this.

It would be better if we had an anno map for when we had 5 or 6 annos per method to simplify the classes :)

Owen Rubel
<a href="tel:415-971-0976" value="+14159710976" target="_blank">415-971-0976
[hidden email]


On Thu, Mar 13, 2014 at 9:33 PM, Jeff Scott Brown <[hidden email]> wrote:
While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...

class Widget {
    
    @Constrained({[range:5..10]})
    Integer size
    
    @Constrained({[size:5..10, matches: /[A-Z].*/]})
    String name
}

@TestMixin(GrailsUnitTestMixin)
class ConstrainedAnnotationSpec extends Specification {

    void 'test a single constraint'() {
        when:
        def obj = new Widget(size: 2)
        
        then:
        !obj.validate()
        
        and:
        obj.errors.getFieldError('size').code == 'range.toosmall'
        
        when:
        obj.size = 9
        
        then:
        obj.validate()
    }
    
    void 'test multiple constraints'() {
        when:
        def obj = new Widget(name: 'short')
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'matches.invalid'
        
        when:
        obj.name = 'Long'
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'size.toosmall'
        
        when:
        obj.name = 'Short'
        
        then:
        obj.validate()
    }
}

All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with “range” is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...

What say ye?



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email







--
Dr Jonathan Stott
Development Team Leader

Axon Limited
"Connecting Healthcare"
2 Venture Road
University of Southampton Science Park
Southampton SO16 7NP


Tel: +44 (0)2380 11 11 99

www.axonuk.com

This message and the information contained therein is intended only for the use of the person(s) to whom it is addressed.  It may contain information that is confidential or privileged within the meaning of applicable law.  If you are not the intended recipient, please contact the sender as soon as possible and delete this message from your system; please also note that any use or disclosure of the information contained in this message (including any attachments) is strictly prohibited and may be unlawful.  This correspondence may include examples or terms based upon current assumptions with any costs shown excluding VAT and cannot be considered as a quotation, offer or commitment in any way.  Whilst reasonable precaution has been taken to minimise the risk, the contents or an attachment to this e-mail may have become corrupted during transmission or contain viruses, we cannot accept liability in this regard, and you should carry out your own virus checks.

Axon Limited is a Company registered in England and Wales number 5728502. Registered Office:
C/o Berry Smith LLP, Haywood House, Dumfries Place, Cardiff, Wales, CF10 3GA.
Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

beckje01

I will go with Graeme on this fewer annotation the better.

Jeff

On Mar 15, 2014 7:56 AM, "Jonathan Stott" <[hidden email]> wrote:
The only value that I can see for annotation-based constraints is that the rules are then written next to the field rather than in a constraints block somewhere else. I'd be in favour of having annotation based constraints for the normal things and then using the constraints block for custom validations only. In my view, the annotations would then work like an extension to the type of the field, i.e. this is a String, but it's a string that is 1-255 chars long (much like how some languages have the "unsigned" keyword to constrain the type).

Jonathan


On 14 March 2014 22:10, Rick Jensen <[hidden email]> wrote:
I agree with Graeme. I find annotations irritating, in general, particularly when they start to stack up. To me, they obscure the code, and never really seem to have the benefit of "decoupling" the code the way that they are supposed to. Annotations feel too much like configuration that is just embedded in the code.

On the other hand, I am all for giving more compile-time checking (and static compilability) to Grails (and groovy in general). I think, like Zyro said, adding this as a plugin makes a lot of sense.

I must confess, I've done a bit of dabbling with Scala and Play recently, and while Groovy and Grails still win, the rich type system in Scala (without the ugly syntax) and the "async by default" nature of Play would make groovy and Grails just about perfect.

- Rick



On Fri, Mar 14, 2014 at 4:01 PM, Owen Rubel <[hidden email]> wrote:
Totally dig it. Am seeing constraints more and more as common reuseable code snippets like this.

It would be better if we had an anno map for when we had 5 or 6 annos per method to simplify the classes :)

Owen Rubel
<a href="tel:415-971-0976" value="+14159710976" target="_blank">415-971-0976
[hidden email]


On Thu, Mar 13, 2014 at 9:33 PM, Jeff Scott Brown <[hidden email]> wrote:
While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...

class Widget {
    
    @Constrained({[range:5..10]})
    Integer size
    
    @Constrained({[size:5..10, matches: /[A-Z].*/]})
    String name
}

@TestMixin(GrailsUnitTestMixin)
class ConstrainedAnnotationSpec extends Specification {

    void 'test a single constraint'() {
        when:
        def obj = new Widget(size: 2)
        
        then:
        !obj.validate()
        
        and:
        obj.errors.getFieldError('size').code == 'range.toosmall'
        
        when:
        obj.size = 9
        
        then:
        obj.validate()
    }
    
    void 'test multiple constraints'() {
        when:
        def obj = new Widget(name: 'short')
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'matches.invalid'
        
        when:
        obj.name = 'Long'
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'size.toosmall'
        
        when:
        obj.name = 'Short'
        
        then:
        obj.validate()
    }
}

All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with “range” is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...

What say ye?



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email







--
Dr Jonathan Stott
Development Team Leader

Axon Limited
"Connecting Healthcare"
2 Venture Road
University of Southampton Science Park
Southampton SO16 7NP


Tel: +44 (0)2380 11 11 99

www.axonuk.com

This message and the information contained therein is intended only for the use of the person(s) to whom it is addressed.  It may contain information that is confidential or privileged within the meaning of applicable law.  If you are not the intended recipient, please contact the sender as soon as possible and delete this message from your system; please also note that any use or disclosure of the information contained in this message (including any attachments) is strictly prohibited and may be unlawful.  This correspondence may include examples or terms based upon current assumptions with any costs shown excluding VAT and cannot be considered as a quotation, offer or commitment in any way.  Whilst reasonable precaution has been taken to minimise the risk, the contents or an attachment to this e-mail may have become corrupted during transmission or contain viruses, we cannot accept liability in this regard, and you should carry out your own virus checks.

Axon Limited is a Company registered in England and Wales number 5728502. Registered Office:
C/o Berry Smith LLP, Haywood House, Dumfries Place, Cardiff, Wales, CF10 3GA.
Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

James Rybicki
I too agree with Graeme. Also why fix what ain't broke when there are so many other things to work on?

Jamie

Sent from my iPhone 4S

On Mar 15, 2014, at 9:59 AM, Jeff Beck <[hidden email]> wrote:

I will go with Graeme on this fewer annotation the better.

Jeff

On Mar 15, 2014 7:56 AM, "Jonathan Stott" <[hidden email]> wrote:
The only value that I can see for annotation-based constraints is that the rules are then written next to the field rather than in a constraints block somewhere else. I'd be in favour of having annotation based constraints for the normal things and then using the constraints block for custom validations only. In my view, the annotations would then work like an extension to the type of the field, i.e. this is a String, but it's a string that is 1-255 chars long (much like how some languages have the "unsigned" keyword to constrain the type).

Jonathan


On 14 March 2014 22:10, Rick Jensen <[hidden email]> wrote:
I agree with Graeme. I find annotations irritating, in general, particularly when they start to stack up. To me, they obscure the code, and never really seem to have the benefit of "decoupling" the code the way that they are supposed to. Annotations feel too much like configuration that is just embedded in the code.

On the other hand, I am all for giving more compile-time checking (and static compilability) to Grails (and groovy in general). I think, like Zyro said, adding this as a plugin makes a lot of sense.

I must confess, I've done a bit of dabbling with Scala and Play recently, and while Groovy and Grails still win, the rich type system in Scala (without the ugly syntax) and the "async by default" nature of Play would make groovy and Grails just about perfect.

- Rick



On Fri, Mar 14, 2014 at 4:01 PM, Owen Rubel <[hidden email]> wrote:
Totally dig it. Am seeing constraints more and more as common reuseable code snippets like this.

It would be better if we had an anno map for when we had 5 or 6 annos per method to simplify the classes :)

Owen Rubel
<a href="tel:415-971-0976" value="+14159710976" target="_blank">415-971-0976
[hidden email]


On Thu, Mar 13, 2014 at 9:33 PM, Jeff Scott Brown <[hidden email]> wrote:
While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...

class Widget {
    
    @Constrained({[range:5..10]})
    Integer size
    
    @Constrained({[size:5..10, matches: /[A-Z].*/]})
    String name
}

@TestMixin(GrailsUnitTestMixin)
class ConstrainedAnnotationSpec extends Specification {

    void 'test a single constraint'() {
        when:
        def obj = new Widget(size: 2)
        
        then:
        !obj.validate()
        
        and:
        obj.errors.getFieldError('size').code == 'range.toosmall'
        
        when:
        obj.size = 9
        
        then:
        obj.validate()
    }
    
    void 'test multiple constraints'() {
        when:
        def obj = new Widget(name: 'short')
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'matches.invalid'
        
        when:
        obj.name = 'Long'
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'size.toosmall'
        
        when:
        obj.name = 'Short'
        
        then:
        obj.validate()
    }
}

All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with “range” is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...

What say ye?



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email







--
Dr Jonathan Stott
Development Team Leader

Axon Limited
"Connecting Healthcare"
2 Venture Road
University of Southampton Science Park
Southampton SO16 7NP


Tel: +44 (0)2380 11 11 99

www.axonuk.com

This message and the information contained therein is intended only for the use of the person(s) to whom it is addressed.  It may contain information that is confidential or privileged within the meaning of applicable law.  If you are not the intended recipient, please contact the sender as soon as possible and delete this message from your system; please also note that any use or disclosure of the information contained in this message (including any attachments) is strictly prohibited and may be unlawful.  This correspondence may include examples or terms based upon current assumptions with any costs shown excluding VAT and cannot be considered as a quotation, offer or commitment in any way.  Whilst reasonable precaution has been taken to minimise the risk, the contents or an attachment to this e-mail may have become corrupted during transmission or contain viruses, we cannot accept liability in this regard, and you should carry out your own virus checks.

Axon Limited is a Company registered in England and Wales number 5728502. Registered Office:
C/o Berry Smith LLP, Haywood House, Dumfries Place, Cardiff, Wales, CF10 3GA.
Reply | Threaded
Open this post in threaded view
|

Re: constraint proposal

Nick Vaidyanathan
I like it. It minimizes the distance between the constraint definition and the actual logic of the constraint (as opposed to a static def constraints = later) which makes Domains/other constrained object a little DRYer.

Could it support custom validators too, or a class attribute to specify which class should provide the constraining logic?




On Sat, Mar 15, 2014 at 8:17 AM, James Rybicki <[hidden email]> wrote:
I too agree with Graeme. Also why fix what ain't broke when there are so many other things to work on?

Jamie

Sent from my iPhone 4S

On Mar 15, 2014, at 9:59 AM, Jeff Beck <[hidden email]> wrote:

I will go with Graeme on this fewer annotation the better.

Jeff

On Mar 15, 2014 7:56 AM, "Jonathan Stott" <[hidden email]> wrote:
The only value that I can see for annotation-based constraints is that the rules are then written next to the field rather than in a constraints block somewhere else. I'd be in favour of having annotation based constraints for the normal things and then using the constraints block for custom validations only. In my view, the annotations would then work like an extension to the type of the field, i.e. this is a String, but it's a string that is 1-255 chars long (much like how some languages have the "unsigned" keyword to constrain the type).

Jonathan


On 14 March 2014 22:10, Rick Jensen <[hidden email]> wrote:
I agree with Graeme. I find annotations irritating, in general, particularly when they start to stack up. To me, they obscure the code, and never really seem to have the benefit of "decoupling" the code the way that they are supposed to. Annotations feel too much like configuration that is just embedded in the code.

On the other hand, I am all for giving more compile-time checking (and static compilability) to Grails (and groovy in general). I think, like Zyro said, adding this as a plugin makes a lot of sense.

I must confess, I've done a bit of dabbling with Scala and Play recently, and while Groovy and Grails still win, the rich type system in Scala (without the ugly syntax) and the "async by default" nature of Play would make groovy and Grails just about perfect.

- Rick



On Fri, Mar 14, 2014 at 4:01 PM, Owen Rubel <[hidden email]> wrote:
Totally dig it. Am seeing constraints more and more as common reuseable code snippets like this.

It would be better if we had an anno map for when we had 5 or 6 annos per method to simplify the classes :)

Owen Rubel
<a href="tel:415-971-0976" value="+14159710976" target="_blank">415-971-0976
[hidden email]


On Thu, Mar 13, 2014 at 9:33 PM, Jeff Scott Brown <[hidden email]> wrote:
While looking at constraints type checking tonight and thinking about the problems type checking can solve there I got distracted with an idea of attaching constraints to the field directly with an annotation.  I did a quick spike and was able to make the following pass.  The code is a really quick-n-dirty little 20 minute spike kind of thing but could be fleshed out without too much work.  Do you guys thing something like this would be a nice add?...

class Widget {
    
    @Constrained({[range:5..10]})
    Integer size
    
    @Constrained({[size:5..10, matches: /[A-Z].*/]})
    String name
}

@TestMixin(GrailsUnitTestMixin)
class ConstrainedAnnotationSpec extends Specification {

    void 'test a single constraint'() {
        when:
        def obj = new Widget(size: 2)
        
        then:
        !obj.validate()
        
        and:
        obj.errors.getFieldError('size').code == 'range.toosmall'
        
        when:
        obj.size = 9
        
        then:
        obj.validate()
    }
    
    void 'test multiple constraints'() {
        when:
        def obj = new Widget(name: 'short')
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'matches.invalid'
        
        when:
        obj.name = 'Long'
        
        then:
        !obj.validate()
        obj.errors.getFieldError('name').code == 'size.toosmall'
        
        when:
        obj.name = 'Short'
        
        then:
        obj.validate()
    }
}

All of the work to evaluate the annotation and its value is happening at compile time.  Of course we can impose the same kinds of checks here that we can inside the constraints closure.  For example, we can make sure the value associated with “range” is a Groovy range, impose compile time errors or warnings about things like potentially problematic combinations of blank+nullable, etc...

What say ye?



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email







--
Dr Jonathan Stott
Development Team Leader

Axon Limited
"Connecting Healthcare"
2 Venture Road
University of Southampton Science Park
Southampton SO16 7NP


Tel: +44 (0)2380 11 11 99

www.axonuk.com

This message and the information contained therein is intended only for the use of the person(s) to whom it is addressed.  It may contain information that is confidential or privileged within the meaning of applicable law.  If you are not the intended recipient, please contact the sender as soon as possible and delete this message from your system; please also note that any use or disclosure of the information contained in this message (including any attachments) is strictly prohibited and may be unlawful.  This correspondence may include examples or terms based upon current assumptions with any costs shown excluding VAT and cannot be considered as a quotation, offer or commitment in any way.  Whilst reasonable precaution has been taken to minimise the risk, the contents or an attachment to this e-mail may have become corrupted during transmission or contain viruses, we cannot accept liability in this regard, and you should carry out your own virus checks.

Axon Limited is a Company registered in England and Wales number 5728502. Registered Office:
C/o Berry Smith LLP, Haywood House, Dumfries Place, Cardiff, Wales, CF10 3GA.



--
Nick Vaidyanathan