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

[Gunnar Morling]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130215/73cca417/attachment.html