On Thu, Feb 9, 2012 at 5:42 PM, Igor Vaynberg <[email protected]> wrote: > typically there is no usecase for a validator sometimes wanting to > validate null itself and other times letting wicket handle it with the > required flag, whats yours?
Custom validator extends from Wicket validator (e.g. UrlValidator) that extends from AbstractValidator that implements INullAcceptingValidator. This custom validator is used once with a field which may be null and with another field must not be null. > > -igor > > On Wed, Feb 8, 2012 at 11:47 PM, Martin Grigorov <[email protected]> wrote: >> 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
