Hi all,<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">@DecimalMax(value = "0.0", exclusive = true)</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div>Can we name it "inclusive" rather than "exclusive"? Personally I prefer positive variable/method names as I think they read better, in particular when it comes to negation.</div><div>
<br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> When dealing with decimal number such a flag can indeed simplify things, </span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> however it creates </span><span style="font-family:arial,sans-serif;font-size:13px">a problem when dealing with error messages.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>I think selecting the right message within the validator impl is sufficient. The spec could just describe which text is to be chosen in which case. Being able to make use of more advanced formatting logic (conditionals etc.) in messages is something which we should discuss separately IMO.</div>
<div><br></div><div>A possible alternative would be to make use of constraint composition. E.g. @DecimalMin could be a composed constraint like this:</div><div><br></div>@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })<br>
@Retention(RUNTIME)<br>@Documented<br>@DecimalMinExclusive("")<br>@DecimalMinInclusive("")<br>@Constraint(validatedBy = { })<br>public @interface DecimalMin {<br><br> String message() default "";<br>
Class<?>[] groups() default { };<br> Class<? extends Payload>[] payload() default { };<br><br> @OverridesAttribute.List( {<br> @OverridesAttribute(constraint=DecimalMinInclusive.class, name="value"),<br>
@OverridesAttribute(constraint=DecimalMinExclusive.class, name="value") <br> } )<br> String value();<br><br> @OverridesAttribute.List( {<br> @OverridesAttribute(constraint=DecimalMinInclusive.class, name="inclusive"),<br>
@OverridesAttribute(constraint=DecimalMinExclusive.class, name="inclusive") <br> } )<br> boolean inclusive() default true;<br>}<br><div><br></div><div>Depending on the value of the "inclusive" attribute, only one of the validators for @DecimalMinExclusive and @DecimalMinInclusive would validate the given value and potentially raise an error. By decomposing the validation into two distinct constraints we could make use of plain error messages:</div>
<br>javax.validation.constraints.DecimalMinInclusive.message = must be greater than or equal to {value}<br>javax.validation.constraints.DecimalMinExclusive.message = must be greater than {value}<br><div><br></div><div>The main issue with that approach is that DecimalMinInclusive etc. would be part of the API, although they ideally shouldn't be directly used by BV end users.</div>
<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">I don't quite remember if default values on annotations can</span></div>
<span style="font-family:arial,sans-serif;font-size:13px">> be changed in a backward compatible way</span><div><br></div><div>According to [1], they can:</div><div><br></div><div>"Change default clause on annotation type element [is] Binary compatible [...] Defaults are applied dynamically at the time annotations are read. Changing the default value may affect annotations in all classes, including ones compiled before the change was made."</div>
<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">I also like the approach taken in OVal. There you can create/change message </span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> variables by overriding 'Map<String, String> createMessageVariables()'. </span><span style="font-family:arial,sans-serif;font-size:13px">Something </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">> like this could for example be added to ConstraintValidatorContext.</span><br><div><br></div><div>A while ago I created BVAL-339 [2] which I think goes into this direction. It suggests to add a method setValue() to ConstraintValidatorContext, allowing to set arbitrary message attributes:</div>
<div><br></div>context<br> .buildConstraintViolationWithTemplate( "Must be after {now}" )<br> .setValue( "now", now )<br> .addConstraintViolation();<div><br></div><div>Independent from the originally discussed issue, I think adding this would makes sense in any case. If no one objects, I can create pull requests for this.</div>
<div><br></div><div>--Gunnar</div>
<div><br></div><div>[1] <a href="http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces" target="_blank">http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces</a></div><div>[2] <a href="https://hibernate.onjira.com/browse/BVAL-339" target="_blank">https://hibernate.onjira.com/browse/BVAL-339</a><br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2012/12/10 Hardy Ferentschik <span dir="ltr"><<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>></span><br><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">
Hi,<br>
<br>
Seem Michael's and Emmanuel's suggestions are related to BVAL-223 [1].<br>
<br>
Regarding this issue I had so far a much simpler improvement of the message interpolation in mind. Something along the lines of Hibernate Validator's<br>
ValueFormatterMessageInterpolator [2]. There the idea is that parameters can be formatted with the syntax supported by String#format and<br>
the validated value itself becomes interpolatable as well. Something like '${validatedValue: '%1$5f' }'.<br>
<br>
I also like the approach taken in OVal. There you can create/change message variables by overriding 'Map<String, String> createMessageVariables()'.<br>
Something like this could for example be added to ConstraintValidatorContext.<br>
<br>
Obviously this does not solve yet the conditional logic required for the @DecimalMin/Max. Is it realistic that we agree on a syntax for inclusion into<br>
BV 1.1 given the current time frame? Is there a syntax out there we could base it on.<br>
<br>
<br>
--Hardy<br>
<br>
<br>
[1] <a href="https://hibernate.onjira.com/browse/BVAL-223" target="_blank">https://hibernate.onjira.com/browse/BVAL-223</a><br>
[2] <a href="https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/messageinterpolation/ValueFormatterMessageInterpolator.java" target="_blank">https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/messageinterpolation/ValueFormatterMessageInterpolator.java</a><br>
<div><div><br>
<br>
<br>
On 10 Jan 2012, at 4:17 PM, Michael Nascimento <<a href="mailto:misterm@gmail.com" target="_blank">misterm@gmail.com</a>> wrote:<br>
<br>
> Yes, I think we need to improve on the message format as you suggested<br>
> to include conditional formatting statements (maybe a ternary?).<br>
><br>
> Regards,<br>
> Michael<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">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>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">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>