Touche. On Thu, Feb 9, 2012 at 5:48 PM, Igor Vaynberg <[email protected]> wrote: > 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
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
