A property according to the JavaBeans specification is either:
- a pair of [PropertyType] get[PropertyName]() / void set[PropertyName]([PropertyType]
value)
- a [PropertyType] get[PropertyName]()
- a void set[PropertyName]([PropertyType] value)
- if PropertyType is boolean, then boolean is[PropertyName]() is accepted (and preferred)
There are ways to customize that further but that's out of the scope of this
discussion. So to answer your question backing fields are an implementation detail.
You and Gunnar seem to want a global VF level flag to activate/inactivate getters as
constrained methods. I would like to know your reasons for that. When I put myself in
situations and try and use method level validations, I can't seem to find it
compelling to get a global flag. It would only let me chose between two evils instead of
giving me choice on a per element basis.
We already discussed the merits of having method validation activated by default vs the
other way around in the past but if I follow your argument, I will ask developers who add
constraints to their methods to also create a META-INF/validation.xml in their various
modules to activate method validation ? That seems to go against the current trend to me.
Emmanuel
On 7 nov. 2012, at 12:36, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
Hi,
I think I would like to clarify a few things first. We keep just talking about getters.
What does this actually mean? Do we talk about any method starting with 'get' or
do we mean getters for properties in the Java Bean sense (aka getters for fields with
the matching name)?
Do you want to exclude any method starting with 'get' from method validation or
just
properties getters? If the latter, are we not introducing some quite arbitrary
distinction
between methods starting with 'get'?
Also what's about methods starting with 'is'? Wouldn't we have to exclude
them
as well in this case?
Also, in the current specification (1.0, 3.1.2. Field and property validation) is the
intention
to only validate a getter when it is a Java Bean property (backed up by a matching
field)?
I think this is not very clear and not explicitly tested in the TCK.
On 6 Jan 2012, at 6:53 PM, Emmanuel Bernard wrote:
> If we treat getters as regular methods, we would add a new
> behavior to all existing constrained beans. Things that were constrained
> at specific lifecycles boundaries would now be constrained every time a
> getter is called. That would break backward compatibility.
Backward compatibility is indeed an issue. However, instead of imo arbitrarily
considering a getXYZ not as a method, I would have just not enabled method validation
out of the box. I would have made it an active choice. Alternatively I would add an
option
to switch between ignoring getters and taking them into consideration for method
validation.
However, I don't think @ValidateOnCall is a good option though. This seems to me to
intrusive. I rather add a configuration option for the ValidatorFactory.
> Even if a getter was to be constrained on call - you would probably want
> to constrain on the setter
What if other method modify the state of the property (not just a setter). Maybe the
intend
is to verify that the object is in a certain state when I request it.
> But I do like the simplicity of the rule claiming that all methods
> are constrained regardless of their similarity to the Bean
> specification. I do not currently thing that this argument alone
> outweighs the other problems.
I think it is a argument for consistency. Excluding getter methods from a general method
validation
framework seems to introduce unnecessary inconsistency and might even exclude the
framework
as general method validation framework of choice.
> ### Forcing a getter to behave as a regular method
>
> To solve this use case, we can introduce a `@ValidateOnCall`
> annotation that should be placed on the getter method.
See above.
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev