8:21 a.m.
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.
Does the current XSD use the camel case pattern instead of the dash
separated pattern? Ideally, I'd rather have
<convert-group/>
Group conversion can happen on regular properties, is that covered?
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? In other words, can you dive a bit in the
subject.
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