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
