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

[Gunnar Morling]

> two elements brings the aditional complexity of the incompatible
  combinations or even expected behavior when considering weird
  combinations.

I see your point.

OTOH, also in the current model a user could specify something incompatible
like { NONE, CONSTRUCTORS }. In both models we mitigate the risk for
inconsistent use by properly documenting the behavior, but personally I'd
find two separate attributes, each with clear semantics, "harder" to use
wrong than one enum with mixed values.

Or, to put it in other words, the precedence of an enabled/disabled switch
over another attribute controlling the enabled behavior seems to me more
natural and intuitively understandable than the { NONE, CONSTRUCTORS } case
which only can be resolved by documentation.

But in the end that's details, both approaches surely work.

--Gunnar


2013/2/15 Emmanuel Bernard <emmanuel at hibernate.org>

> 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
>
> _______________________________________________
> 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/b546eb52/attachment-0001.html