5:27 p.m.
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(a)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(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
> >
> _______________________________________________
> 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