Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
We created our own Bean Validation Annotation like this:
@Constraint(validatedBy = YearMonthDurationValidator.class) public @interface DurationConstraints { String DEFAULT_MESSAGE = "{bad.boundaries}"; ...
And in YearMonthDurationValidator:
@Override public boolean isValid(final Duration<YearMonth> value, final ConstraintValidatorContext context) { context.disableDefaultConstraintViolation(); if (...) { context.buildConstraintViolationWithTemplate("{duration.from.null}").addPropertyNode("from") .addConstraintViolation(); valid = false; } else { context.buildConstraintViolationWithTemplate("{duration.to.null}").addPropertyNode("from") .addConstraintViolation(); valid = false; } ...
Wicket provides a DefaultViolationTranslator which uses
violation.getConstraintDescriptor().getAttributes().get("message")
as key to look up a localized message. However, in our case, this is always "bad.boundaries", and we believe that it would be more useful if the DefaultViolationTranslator used violation.getMessageTemplate() instead, or maybe as the first key (more backwards compatible). That way we could provide specific error messages for the cases duration.to.null and duration.from.null
This is a complex design choice, so we are suggesting this tentatively, not really sure whether this would be actually better, and what breakage could occur.
We will go ahead and implement our own IViolationTranslator as suggested.