I agree with what Hardy said.

Alternatively we could have one annotation with two attributes:

@ValidateExecutables(enabled=true/false, types=ALL|CONSTRUCTORS|GETTERS|NON_GETTERS)

Where enabled = true by default and types = ALL by default. types would only be considered if enabled = true.

//enable validation for type
@ValidateExecutables 
public class Foo {

}

//exclude getters
@ValidateExecutables(types={CONSTRUCTORS, NON_GETTERS})
public class Foo {

}

@ValidateExecutables
public class Foo {

    @ValidateExecutables(enabled=false)
    public getFoo() { ... }
}

This would avoid the mixing of two things in one enum as mentioned by Hardy and also circumvent the naming issue. On a single method, @ValidateExecutables(enabled=false) is still a bit lengthy, but I think it's better than @ValidateExecutables(types = NONE).

--Gunnar



2013/2/15 Hardy Ferentschik <hardy@hibernate.org>
Hi,

To have a enum which truly makes sense we would have to go for two annotations.

We try to mix two semantics into a single emum. One is the on/off switch and one
is the types of executables to validate. No matter how you rename the enum will always
read awkward unless we separate these two things.

I could live with @ValidateExecutables and @ValidateExecutable. I don't think that it
is a problem that in other contexts the @Xs is a list of @X annotations.

--Hardy


On 14 Jan 2013, at 5:55 PM, Emmanuel Bernard <emmanuel@hibernate.org> wrote:

> Pete from CDI gave me the same feedback.
>
> There are a few competing alternatives
>
> ## enum adjustments
>
> @ValidateExecutable.type defaults to ALL
> and rename ElementType.NONE to ElementType.OFF or NO
>
> We can even rename type to value to make the user even easier at the
> risk of harder evolutions if we need to add more parameters down the
> road.
>
> ## two annotations
>
> @ValidateExecutable(ON|OFF) targeting methods and constructors
> @ValidateExecutables(ALL|NON_GETTER_METHODS|...)
>
> The downside is that the @Xxxs convention is used to add several times
> the same annotation. This is widely used in EE for example.
>
> We could try and find better (different) names for these annotations but
> I could not find a good set.
>
> What are your preferences?
>
> On Mon 2013-02-11 11:04, Emmanuel Bernard wrote:
>> Santiago from the JAX-RS EG is concerned that we have created an
>> over-engineered solution to enable / disable method validation on a per
>> method basis.
>> We have good reasons for it but I am wondering if we can make it a bit
>> easier to enable or disable methods out of the box.
>>
>> Remember, the default is to ignore getters. If we make
>> @ValidateExecutable.type default to ALL, enabling it on a getter would
>> be
>>
>>    @NotEmpty @ValidateExecutable
>>    public String getAction() {...}
>>
>> instead of
>>
>>
>>    @NotEmpty @ValidateExecutable(type=ExecutableType.ALL)
>>    public String getAction() {...}
>>
>> We would still need the verbose approach to disable validation
>>
>>    @NotEmpty @ValidateExecutable(type=ExecutableType.NONE)
>>    public String getAction() {...}
>>
>> I am open to suggestions to make that easier on methods. I don't think
>> an additional annotation will make anything easier
>>
>> Maybe renaming NONE with OFF might help? It's a bit weirder on a
>> class-level but that might work.
>>
>> Thoughts?
>>
>> Emmanuel
>> _______________________________________________
>> 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