Yes, I think we need to improve on the message format as you suggested to include conditional formatting statements (maybe a ternary?). Regards, Michael

Hi all, 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. 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. 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." message Something 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 [1] http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces [2] https://hibernate.onjira.com/browse/BVAL-339 2012/12/10 Hardy Ferentschik <hardy(a)hibernate.org&gt; > Hi, > > Seem Michael's and Emmanuel's suggestions are related to BVAL-223 [1]. > > 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 > ValueFormatterMessageInterpolator [2]. There the idea is that parameters > can be formatted with the syntax supported by String#format and > the validated value itself becomes interpolatable as well. Something like > '${validatedValue: '%1$5f' }'. > > message variables by overriding 'Map<String, String> > createMessageVariables()'. > Something like this could for example be added to > ConstraintValidatorContext. > > 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 > BV 1.1 given the current time frame? Is there a syntax out there we could > base it on. > > > --Hardy > > > [1] https://hibernate.onjira.com/browse/BVAL-223 > [2] > https://github.com/hibernate/hibernate-validator/blob/master/engine/src/m... > > > > On 10 Jan 2012, at 4:17 PM, Michael Nascimento <misterm(a)gmail.com&gt; wrote: > > > Yes, I think we need to improve on the message format as you suggested > > to include conditional formatting statements (maybe a ternary?). > > > > Regards, > > Michael > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >

I did a quick look at the Expression Language JSR and that might be enough for what we want to do. We could simply delegate message interpolation to the EL engine. It has the ternary operator which would offer what we need for DecimalMin / Max messages. Can someone dive into this approach to see of that is indeed doable and how much work we need to do in the specification? On 10 déc. 2012, at 23:53, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote:

Well, I just used 'exclude', because it was used in the jira ticket. Now that I think about it 'inclusive' is much better. Maybe I can play the newborn card as well? Does it still count after 4 months? I definitely still feel tired. Welcome to the club. --Hardy

On 11 Jan 2012, at 2:52 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: I can have a look on how this could look like. --Hardy

Yes ${amount} and #{number} are casualties of the new approach and I don't have a good solution to that. On Wed 2012-12-12 9:42, Matt Benson wrote: