On 9/10/07, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: > > Hi, > > According to the javadoc Form.updateFormComponentModels should update > all the models of all FormComponents in a form (without validation > presumably?). This sets all the model objects to the convertedInput
no it updates the form component models where conversion and validation did go alright. value (in FormComponent.updateModel), unfortunately convertedInput is > only set after a call to validate(). This really makes > updateFormComponentModels useless as a protected method. If validation It is only protected final if you want to do some of your own processing see IFormSubmittingComponent.getDefaultFormProcessing() is really mandatory (which I doubt), processInput should be the only > callable method as it validates first and then updates the model. checking required, conversion and validation is mandatory before updating models. In any case, the call to convertInput() inside validate() strikes me as > odd (the wrong place to call such a method). no not really, FormComponent.validate() is really all the validation that can happen first required validation, then conversion validation and then user validation on the converted type We could split up the methods again, like in Form.process() which calls the above validate only. We could split that up in to validateRequired(), validateConversion(), validateXX() but what do we gain then? Also, the javadoc of FormComponent.updateModel() states: ".. it expect > that the object is already converted through the convert() call", but > there is no convert() method in FormComponent. thats then an error in the doc, there are some changes in that area so that should be improved make a jira issue for this. Maybe this is a consequence of the fact that wicket forces you to > subclass components so much. It's just too tempting to override so much > methods. I love wicket (I really do!) but I'd rather see wicket more > event listener oriented. This would also make it easier to listen to > events that are very deeply nested (fetch the component, register a > listener), which is almost impossible now If you want listeners like swing then that is very easy for you to make just extend link or what ever component or behavior you have once and make the addXXXX/removeXXX and fireXXXX methods on them. We have this also because it preserves memory, If you have to make an (inner)class instance and a link instance and attach those 2 each other that can consume much more memory then when just making a new class and have there one instance. johan
