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?
-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
