8:58 a.m.
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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev