so why isnt the field that must not be null not use the setrequired() flag?
-igor On Thu, Feb 9, 2012 at 7:46 AM, Martin Grigorov <[email protected]> wrote: > 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
