[
https://issues.apache.org/jira/browse/WICKET-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096826#comment-14096826
]
Andrea Del Bene commented on WICKET-5654:
-----------------------------------------
I created a quickstart project that shows the problem. The validator I created
(CustomValidator) is pretty silly: it checks for positive integer value,s
returning the default error message if value == 0 (bundle key
"{com.mycompany.validator.default}") or a different one (bundle key
"{duration.from.null}") if value < 0.
If we run the test case we can see the problem reported in this issue. In both
error cases the resulting Wicket errors uses the default error message as
bundle key.
Using violation.getMessageTemplate() or violation.getMessage() as suggested by
Thibault solves the issues but I'm not sure of the impact of this change.
To me using violation.getMessage() is safer and I don't think it could break
existing code.
> DefaultViolationTranslator should maybe use getMessage()
> --------------------------------------------------------
>
> Key: WICKET-5654
> URL: https://issues.apache.org/jira/browse/WICKET-5654
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-bean-validation
> Reporter: Thibault Kruse
> Assignee: Igor Vaynberg
>
> We created our own Bean Validation Annotation like this:
> {code}
> @Constraint(validatedBy = YearMonthDurationValidator.class)
> public @interface DurationConstraints {
> String DEFAULT_MESSAGE = "{bad.boundaries}";
> ...
> {code}
> And in YearMonthDurationValidator:
> {code}
> @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;
> }
> ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
