[bv-dev] Making @ValidateExecutable easier to use on methods

[Emmanuel Bernard]

We discussed that be to me:
- two annotations do make things more complex IMO and thus go against
  the goal here. Esp with annotations with similar names
- two elements brings the aditional complexity of the incompatible
  combinations or even expected behavior when considering weird
  combinations.

I'd rather live with a slightly awkward enum.

Emmanuel

On Fri 2013-02-15 15:58, Gunnar Morling wrote:
> 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 at 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 at 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 at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >

> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev