Hi all,
> @DecimalMax(value = "0.0", exclusive = true)
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.
> When dealing with decimal number such a flag can indeed simplify things,
> however it creates a problem when dealing with error messages.
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.
A possible alternative would be to make use of constraint composition. E.g. @DecimalMin could be a composed constraint like this:
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
@Documented
@DecimalMinExclusive("")
@DecimalMinInclusive("")
@Constraint(validatedBy = { })
public @interface DecimalMin {
String message() default "";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
@OverridesAttribute.List( {
@OverridesAttribute(constraint=DecimalMinInclusive.class, name="value"),
@OverridesAttribute(constraint=DecimalMinExclusive.class, name="value")
} )
String value();
@OverridesAttribute.List( {
@OverridesAttribute(constraint=DecimalMinInclusive.class, name="inclusive"),
@OverridesAttribute(constraint=DecimalMinExclusive.class, name="inclusive")
} )
boolean inclusive() default true;
}
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:
javax.validation.constraints.DecimalMinInclusive.message = must be greater than or equal to {value}
javax.validation.constraints.DecimalMinExclusive.message = must be greater than {value}
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.
> I don't quite remember if default values on annotations can
> be changed in a backward compatible way
According to [1], they can:
"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."
> I also like the approach taken in OVal. There you can create/change message
> variables by overriding 'Map<String, String> createMessageVariables()'. Something
> like this could for example be added to ConstraintValidatorContext.
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:
context
.buildConstraintViolationWithTemplate( "Must be after {now}" )
.setValue( "now", now )
.addConstraintViolation();
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.
--Gunnar