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

[Gunnar Morling]

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

[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 at hibernate.org>

> 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' }'.
>
> 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.
>
> 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/main/java/org/hibernate/validator/messageinterpolation/ValueFormatterMessageInterpolator.java
>
>
>
> On 10 Jan 2012, at 4:17 PM, Michael Nascimento <misterm at gmail.com> 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121211/03f751f6/attachment.html