[bv-dev] BVAL-192 'exclusive' flag for @DecimalMin/@DecimalMax

[Emmanuel Bernard]

A few remarks:

- definitely not message1 / message2, that's too ugly :)
- we would probably need to keep around javax.validation.constraints.DecimalMax.message
  for backward compatibility purposes. I don't quite remember if default values on annotations can
  be changed in a backward compatible way
- we have in our list of enhancement to improve message rendering
  Does any one know of a well accepted syntax that lets us use of boolean or equality?

We could have something like:

javax.validation.constraints.DecimalMax.message = 
  must be {if exclusive==true}strictly {/if}less than {if exclusive==false}or equal to {/if}{value}

The syntax is made up

Emmanuel

On 10 déc. 2012, at 13:46, Hardy Ferentschik <hardy at hibernate.org> wrote:

> Hi,
> 
> I was looking at one of the minor changes on the BV 1.1 roadmap [1] - BVAL-192 [2].
> The idea is to add a exclusive flag to the annotation @DecimalMin and @DecmimalMax.
> This way you could for example easily express a negative non-zero decimal number:
> 
> @DecimalMax(value = "0.0", exclusive = true)
> 
> When dealing with decimal number such a flag can indeed simplify things, however it creates
> a problem when dealing with error messages. At the moment the message for DecimalMax is for
> example: "must be less than or equal to {value}". Depending on the exclusive flag this message would
> need to change though. Two versions of the message would be required. Technically the right version 
> of the message could be selected via ConstraintValidatorContext, but it would be a first for built-in
> constraints. We would also need to define the name for alternative messages. Would it be: 
> 
> javax.validation.constraints.DecimalMax.message1
> javax.validation.constraints.DecimalMax.message2
> 
> or 
> 
> javax.validation.constraints.DecimalMax.inclusive.message
> javax.validation.constraints.DecimalMax.exclusive.message
> 
> I hope this rather simple question creates some welcome breaking-up from the harder questions like
> "should we consider getters for method validation" ;-)
> 
> --Hardy
> 
> 
> [1] http://beanvalidation.org/roadmap/
> [2] https://hibernate.onjira.com/browse/BVAL-192
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev