Thanks ! On Wed, Feb 8, 2012 at 8:28 PM, Igor Vaynberg <[email protected]> wrote: > On Fri, Feb 3, 2012 at 9:03 AM, Martin Grigorov <[email protected]> wrote: >> On Fri, Feb 3, 2012 at 6:23 PM, Igor Vaynberg <[email protected]> >> wrote: >>> the code is now much simpler and cleaner because years of baggage have >>> been removed. further, once we start working on clientside validation >>> extending AbstractValidator will not work because these validators >>> will have to extend Behavior instead, this commit paved the road for >>> that. also ValidationError is now much more convenient to use. >>> >>> what exactly confuses you? >> >> Here is the migration docu: >> >> Validation >> `StringValidator` will add the `maxlen` attribute if added to a >> component attached to an input tag >> martin-g: this is OK >> >> `AbstractValidator` has been removed >> martin-g: What to do now? > > reintroduced > >> What is #resourceKey() in 6.0 ? > > this is done by overriding the decorate method mentioned later which > lets you override resource key, variables, and everything else from a > single convenient place. > >> INullAcceptingBehavior doesn't have its method now. I need to make two >> classes instead of using a boolean flag as I did in 1.5. > > INullAcceptingValidator never had any method. you can implement the > boolean logic yourself in your own impl. this is so rare that i dont > think it warrants a subclass of its own in the core.
Yes, I see that actually this method is: org.apache.wicket.validation.validator.AbstractValidator#validateOnNullValue(). The name confused me about its declaring class. Apparently my colleagues use it a lot ... It is a bit strange that FormComponent checks "if (isNull == false || validator instanceof INullAcceptingValidator<?>)" and later AbstractValidator#validateOnNullValue() adds some more logic to reject 'null's for some validators which inherit from INullAcceptingValidator. If #validateOnNullValue() should not be in the API at all then fine, but otherwise I think it should be part of INullAcceptingValidator and the whole check should be in FormComponent. For now I moved the additional logic in our custom validators to avoid having two versions of the same validator - one accepting null and one that doesn't. > >> `ValidationError` now makes creating standard error keys (classname >> and classname.subtype) easier >> martin-g: this statement doesn't help at all in my migration :-) > > added clarification > >> >> Most validators provide a `decorate(ValidationError, Validatable)` >> method for overriding how they report errors >> martin-g: an example would be nice. > > added example > > -igor > > > >> >>> >>> -igor >>> >>> >>> On Fri, Feb 3, 2012 at 2:00 AM, Martin Grigorov <[email protected]> >>> wrote: >>>> Hi, >>>> >>>> Recently I tried to upgrade our app to Wicket 6.0 and I faced problems >>>> related to the changes in >>>> https://issues.apache.org/jira/browse/WICKET-4234. >>>> The migration page doesn't really say what to do now and I needed to >>>> browse the code in both 1.5 and 6.0 to find out how to proceed. The >>>> experience is not really pleasant. >>>> >>>> I suggest to either keep the change and improve the migration page or >>>> revert the old code. >>>> I'm more in favour of the latter because there were no complains (in >>>> tickets, in mailing list, ...). >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
