9:02 a.m.
2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
It looks like you added ingore-annotation at the param/return value
level out of real-life feedback. Can yuo share your thoughts on this.
I added "ignore-annotations" to the new elements mainly due to consistency
reasons. As of BV 1.0 it's already there for the "field" and
"getter"
elements, so I think it makes sense to have it on the new ones as well.
One could think about having it on "method" only. But then, if you have a
method with parameter and return value constraint annotations and want
(only) to disable the return value constraints in XML, you'd have to
re-specify all the parameter constraints.
Does the current XSD use the camel case pattern instead of the dash
separated pattern? Ideally, I'd rather have
<convert-group/>
Good point, the 1.0 type names (which are not visible to the reader of an
instance document) are (mostly) camel case, while the actual
element/attribute names are dash separated. It makes sense to follow that
pattern, I'll update the names.
Group conversion can happen on regular properties, is that covered?
Yes, that's available on "field", "getter", "parameter"
and
"returnValue"/"return-value".
I'm a bit uneasy with your idea of getter vs method. That means
the
getter element (isn't it named property?) has all the enhancements you
are describing correct?
The "getter" element has a new optional sub-element,
"convertGroup"/"convert-group", that's the changes to it.
As of 1.0, "A given field or getter must not be described more than once on
a given class description." I think defining a "getter" and a
"method"
element falls into the same category, so I think we should throw a
ValidationException in that case, too.
In other words, can you dive a bit in the
subject.
I've done the following changes/additions:
* Added sub-element "convertGroup" [0..unbounded] to the "field" and
"getter" elements
* Added elements "constructor" and "method" [0..unbounded] to the
"bean"
element
* The "method" element has the sub-elements "parameter"
[0..unbounded],
"returnValue" [0..1] and "crossParameterConstraint" [0..unbounded];
"constructor" is the same without "returnValue".
* The "parameter" and "returnValue" elements resemble the
"field" and
"getter" elements and have sub-elements "valid" [0..1],
"constraint"
[0..unbounded] and "convertGroup" [0..unbounded] (actually we could extract
a common super-type for "field", "getter", "parameter" and
"returnValue").
* With a previous change: added "version" attribute to root element with a
fixed value of "1.1"
Not sure whether that's what you were up to; if something needs more
clarification let me know. You can compare the draft with the old version
at https://github.com/gunnarmorling/hibernate-validator/compare/HV-373.
--Gunnar
On Fri 2013-01-18 10:24, Gunnar Morling wrote:
> Hi all,
>
> I've started to work on a new version of the XSD for constraint mapping
> files in order to allow for the XML-based configuration of
> method/constructor constraints [1] and group conversions [2]. The latest
> XSD draft can be found at [3].
>
> The following shows how the configuration of method constraints and group
> conversions would look like:
>
> <bean class="com.acme.MyBean"
ignore-annotations="false">
> <method name="getFirstname"
ignore-annotations="true">
> <parameter type="java.lang.String">
> <constraint
> annotation="javax.validation.constraints.Pattern">
> <message>Last name has to start with with a capital
> letter.</message>
> <element
name="regexp">^[A-Z][a-z]+</element>
> </constraint>
> </parameter>
> <parameter type="int">
> <valid/>
> <constraint
annotation="javax.validation.constraints.Min">
> <element name="value">1</element>
> </constraint>
> <convertGroup from="javax.validation.groups.Default"
> to="com.acme.Basic"/>
> </parameter>
> <parameter type="long"
ignore-annotations="false"/>
> <returnValue>
> <valid/>
> <constraint
> annotation="javax.validation.constraints.Pattern">
> <message>Last name has to start with with a capital
> letter.</message>
> <element
name="regexp">^[A-Z][a-z]+</element>
> </constraint>
> </returnValue>
> <crossParameterConstraint
> annotation="com.acme.MyCrossParameterConstraint"/>
> </method>
> </bean>
>
> I tried to follow the existing style and patterns. Some notes:
>
> * Always all the parameters of an executable must be specified in order
to
> identify overloaded executables, also if the configuration of a
particular
> parameter shall remain unchanged (ignore-annotations="false" is to be
used
> in this case).
> * ignore-annotations on methods/constructors overrides ignore-annotations
> on the bean level; ignore-annotations on parameters/return values
overrides
> ignore-annotations on the method/constructor and bean levels
> * parameters are identified by their type. The FQN of the type is to be
> used (taking "default-package" into account), or "int",
"long" etc. for
> primitive types.
> * A getter method must either be configured using the "getter" or the
> "method" element. If both are given for one and the same getter, a
> ValidationException will be thrown.
>
> Is there anything else we should add or consider? If there are no
> objections, I'll move forward with adapting the spec next week.
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.onjira.com/browse/BVAL-273
> [2] https://hibernate.onjira.com/browse/BVAL-333
> [3] https://github.com/gunnarmorling/hibernate-validator/compare/HV-373
> _______________________________________________
> 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