On Thu, Feb 17, 2011 at 2:32 PM, Daniel Stoch <daniel.st...@gmail.com> wrote: > On Thu, Feb 17, 2011 at 10:37 PM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: >> validation is there to make sure the user of the webapp cannot push an >> illegal value into a model. it doesnt matter if its just the component >> that is being submitted or the entire form. components decide whether >> or not a user can push null in by using their required flag. you want >> to push null, dont mark the component as required. it is as simple as >> that. > > But you ommit something: model can contains a null value on startup > and event though a formcomponent has a valid state on the first > render.
i always said the validation is there to prevent pushing a value into a model not pulling from it. there is no need to validate the pulled value since it is set by the developer, not the user of the webapp. > So passing null to this model later is like resseting its > state to original (null) value :). for that we have clearInput() which will dump whatever value has been entered by the user and pull it again from the model. > Another thing is than I can set null in code and bypass component > validation. So I can push null into this model, but the final > validation will still work. you as a developer can push the null, correct. the validators are not there to safeguard the application from the developer. > Maybe I should explain one of use-cases. Let's say we have a form to > enter RSS feed information. There are two TextFields: > - url for RSS feed (urlModel) > - custom RSS feed name (nameModel). > Both are required and both have OnChangeBehavior attached. When user > enter url for RSS the name of it is retrieved and set into nameModel. > But only when nameModel has null object or nameEdited (boolean flag) > is false. > Now user can edit name field (then nameEdited flag is set to true, to > avoid changing this name when user change url). > But when user clears name field nameModel should be updated to null, > but behavior does not allow this (because of validation of required > field). what you want can be done in a simple manner. do not mark your field as required, since it is not. write your own validator that allows setting the field value to null when the edit flag is set, and fails when it is not. >> you can create your own updating behavior that calls >> setrequired(false) on the component prior to running validation/model >> update if that is what you want. but we will not ship something like >> this as part of core because it doesnt generally make sense. > > Probably I'll write my own behavior, because it seems this is the only > solution :). > Maybe it does not make sense from your point of view, but from mine it > does. I think your point of view is sometimes too narrow. my point of view has to be narrow. as developers of the framework we try to make the 95% usecase as simple as possible, while leaving the door open for the other rare 5%. unfortunately for you, this is the other 5%. -igor > > -- > Daniel > > >> On Thu, Feb 17, 2011 at 1:33 PM, Daniel Stoch <daniel.st...@gmail.com> wrote: >>> On Thu, Feb 17, 2011 at 10:01 PM, Igor Vaynberg <igor.vaynb...@gmail.com> >>> wrote: >>>> if you want to push a null value into a component you marked required >>>> then dont mark it as required. >>> >>> No, because then I must have my own "customrequired" flags instead of >>> using the core mechanism. I think this is wrong way. >>> There is a wrong assumption that when component is marked as required >>> then I cannot push a null value to its model. Validation should not >>> allow to submit a form (not allow to further processing). But during >>> editing process when user fills the form and "updates" componenets >>> (not "submits" whole form) it should be possible to push null in >>> models (of course as an option). >>> The current behavior leads to many boilerplate code which can be avoided. >>> >>>> if you have inter-dependent validation >>>> use a formvalidator or override form's onsubmit. >>> >>> It is not this case here. >>> >>> -- >>> Daniel >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
