<div dir="ltr">2013/1/18 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It looks like you added ingore-annotation at the param/return value<br>
level out of real-life feedback. Can yuo share your thoughts on this.<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Does the current XSD use the camel case pattern instead of the dash<br>
separated pattern? Ideally, I'd rather have<br>
<br>
<convert-group/><br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Group conversion can happen on regular properties, is that covered?<br></blockquote><div><br></div><div style>Yes, that's available on "field", "getter", "parameter" and "returnValue"/"return-value".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm a bit uneasy with your idea of getter vs method. That means the<br>
getter element (isn't it named property?) has all the enhancements you<br>
are describing correct?</blockquote><div><br></div><div style>The "getter" element has a new optional sub-element, "convertGroup"/"convert-group", that's the changes to it.</div><div style>
<br></div><div style>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.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> In other words, can you dive a bit in the<br>
subject.<br></blockquote><div><br></div><div style>I've done the following changes/additions:</div><div style><br></div><div style>* Added sub-element "convertGroup" [0..unbounded] to the "field" and "getter" elements<br>
</div><div style>* Added elements "constructor" and "method" [0..unbounded] to the "bean" element</div><div style>* The "method" element has the sub-elements "parameter" [0..unbounded], "returnValue" [0..1] and "crossParameterConstraint" [0..unbounded]; "constructor" is the same without "returnValue".</div>
<div style>* 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").</div>
<div style>* With a previous change: added "version" attribute to root element with a fixed value of "1.1"<br></div><div style><br></div><div style>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 <a href="https://github.com/gunnarmorling/hibernate-validator/compare/HV-373" target="_blank">https://github.com/gunnarmorling/hibernate-validator/compare/HV-373</a>.</div>
<div style><br></div><div style>--Gunnar</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
On Fri 2013-01-18 10:24, Gunnar Morling wrote:<br>
> Hi all,<br>
><br>
> I've started to work on a new version of the XSD for constraint mapping<br>
> files in order to allow for the XML-based configuration of<br>
> method/constructor constraints [1] and group conversions [2]. The latest<br>
> XSD draft can be found at [3].<br>
><br>
> The following shows how the configuration of method constraints and group<br>
> conversions would look like:<br>
><br>
> <bean class="com.acme.MyBean" ignore-annotations="false"><br>
> <method name="getFirstname" ignore-annotations="true"><br>
> <parameter type="java.lang.String"><br>
> <constraint<br>
> annotation="javax.validation.constraints.Pattern"><br>
> <message>Last name has to start with with a capital<br>
> letter.</message><br>
> <element name="regexp">^[A-Z][a-z]+</element><br>
> </constraint><br>
> </parameter><br>
> <parameter type="int"><br>
> <valid/><br>
> <constraint annotation="javax.validation.constraints.Min"><br>
> <element name="value">1</element><br>
> </constraint><br>
> <convertGroup from="javax.validation.groups.Default"<br>
> to="com.acme.Basic"/><br>
> </parameter><br>
> <parameter type="long" ignore-annotations="false"/><br>
> <returnValue><br>
> <valid/><br>
> <constraint<br>
> annotation="javax.validation.constraints.Pattern"><br>
> <message>Last name has to start with with a capital<br>
> letter.</message><br>
> <element name="regexp">^[A-Z][a-z]+</element><br>
> </constraint><br>
> </returnValue><br>
> <crossParameterConstraint<br>
> annotation="com.acme.MyCrossParameterConstraint"/><br>
> </method><br>
> </bean><br>
><br>
> I tried to follow the existing style and patterns. Some notes:<br>
><br>
> * Always all the parameters of an executable must be specified in order to<br>
> identify overloaded executables, also if the configuration of a particular<br>
> parameter shall remain unchanged (ignore-annotations="false" is to be used<br>
> in this case).<br>
> * ignore-annotations on methods/constructors overrides ignore-annotations<br>
> on the bean level; ignore-annotations on parameters/return values overrides<br>
> ignore-annotations on the method/constructor and bean levels<br>
> * parameters are identified by their type. The FQN of the type is to be<br>
> used (taking "default-package" into account), or "int", "long" etc. for<br>
> primitive types.<br>
> * A getter method must either be configured using the "getter" or the<br>
> "method" element. If both are given for one and the same getter, a<br>
> ValidationException will be thrown.<br>
><br>
> Is there anything else we should add or consider? If there are no<br>
> objections, I'll move forward with adapting the spec next week.<br>
><br>
> Thanks,<br>
><br>
> --Gunnar<br>
><br>
> [1] <a href="https://hibernate.onjira.com/browse/BVAL-273" target="_blank">https://hibernate.onjira.com/browse/BVAL-273</a><br>
> [2] <a href="https://hibernate.onjira.com/browse/BVAL-333" target="_blank">https://hibernate.onjira.com/browse/BVAL-333</a><br>
> [3] <a href="https://github.com/gunnarmorling/hibernate-validator/compare/HV-373" target="_blank">https://github.com/gunnarmorling/hibernate-validator/compare/HV-373</a><br>
<br>
</div></div><div class=""><div class="h5">> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div></div>