Paul Bors wrote: > Assuming that you don't set a model for the FormComponet won't Wicket fail > back to the CompountPropertyModel of the form?
Yes, for sure. But you explicitly recommended: >> If you're using CompoundPropertyModel and set the model on your >> FormComponentPanel then your TextField ID and type should be all you >> need for wicket to know which getter/setter to call. I.e., you told Raul that he should set the FormComponentPanel's model. And then he risks getting null values set in his model at the panel level. Please note, that I don't argue for or against storing CompountPropertyModels in FormComponetPanels. I have many places in my applications where storing models is sensible and where the form's CompountPropertyModel is not the right thing, design-wise. And the other way round, too. As a common use case, consider when a FormComponentPanel is actually a reusable model that may be used in several situations. A recent example of mine is a component that handles address input and validation for a person. The base model, available as a CompountPropertyModel at form level, has several persons. So the FormComponentPanel gets passed the right person model (actually, the address model from that person model -- a person might have several addresses!) and uses it. And in such cases, one has to take care that the FormComponent processing lifecycle is properly adapted to such situation. > Who will perform the conversion then? As I've written, quite often it's not the conversion that's the problem, but the updateModel() call that stores FormComponent.convertedInput into the model object. To repeat: On the panel level, no input is available, and convertInput() stores that as null in FormComponent.convertedInput. You need to prevent usage of that stored field in updateModel(), otherwise your model object will end up to be null. Overriding convertInput() is of no use here, if there *is no input* that can be converted. Thus quite clearly, overriding FormComponentPanel#convertInput() is only sensible if you do something with the input values of sub-components, beyond storing them, and if you can compute something that you can place into convertedInput. If it's just about storing and you use a CompountPropertyModel, overriding FormComponentPanel#updateModel() is adequate and sufficient. I hope this makes my arguments clearer. It probably won't help Raul, though. :-( Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jsch...@acm.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org