>> 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.
But this field is required - from user point of view. User cannot submit form without filling the name. > >>> 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%. My post was only a proposal, because it is not possible to easy extend AjaxFormComponentUpdatingBehavior because onEvent() is final. I want to avoid copy/paste code with only a little change. And I think this change is very useful. But ok, I understand you, so I'll implement it by myself. But always is good to try convince you first :). -- Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org