Hi Guillaume, If org.apache.wicket.validation.validator.PatternValidator#validate() was 'final' then I'd agree to revert it but the change has been made to make it possible to use custom types of IValidationError. At my former client we used custom IVEs a lot and I'm afraid this may look like a regression to them now. What's wrong with 'instanceof'+casting?
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, May 4, 2015 at 4:36 PM, Guillaume Smet <guillaume.s...@gmail.com> wrote: > Hi all, > > Just a report on the progress of our migration to 7. So far, I have > migrated our bare application template without too many problems. > > The only real issue so far is this change of API in PatternValidator: > protected IValidationError decorate(IValidationError error, > IValidatable<String> validatable) > { > return error; > } > > We used to do this to override the keys of PatternValidator: > @Override > protected ValidationError decorate(ValidationError error, > IValidatable<String> validatable) { > > > error.setKeys(Collections.singletonList("common.validator.username.pattern")); > return error; > } > (note the fact that Wicket 6 used the Impl and not the interface) > > And we can't do it any more without adding an explicit cast. > > While I understand the rationale to use interfaces for public facing API, > I'm wondering if it's a good choice here, considering that IValidationError > only has a getErrorMessage() method so it's quite hard to decorate anything > here. > > I'll be in favor of reverting this change. > > Thoughts? > > -- > Guillaume >
