[bv-dev] XML-based configuration of method constraints and group conversions
Gunnar Morling
gunnar at hibernate.org
Fri Jan 18 10:02:59 EST 2013
2013/1/18 Emmanuel Bernard <emmanuel at 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 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/20130118/b3237c9f/attachment.html
More information about the beanvalidation-dev
mailing list