Another thought:
Why do we have a setter for the model actually?
I never call setDefaultModel() (formerly setModel()) in my code. In
wicket-examples it seems that most calls to setDefaultModel() are done
from inside the constructor (where it is sometimes needed because you
cannot call instance methods before the super constructor call).
Shouldn't we declare this method (final) protected?
Custom components could just handle generified models in the
constructor, the non-final getDefaultModel() could be overriden with the
preferred return type (as already suggested).
And we could get rid of the 'default' in all this method names which
frankly don't look too good to me.
Sven
Johan Compagner schrieb:
thats completely up how you use it
I can think of a lot that dont use models on FormComponents but only on
Forms
If you use CompoundModel then you never will touch or give a FormComponent a
model.
and all your stuff is done on the Model of the Form. (in the onSubmit for
example)
So this can never be generalized like this will never be used this way
The only way for this is to have a complete separate stack of
"ModelComponents/GenericComponents"
See for example Link, Igor says i use model a lot. Eelco says he never uses
it.. (but he uses it on button if i read correctly which is the same thing
as a link)
johan
On Wed, Jul 2, 2008 at 9:15 AM, Jan Kriesten <[EMAIL PROTECTED]>
wrote:
Hi,
i agree that its no big deal, i am just trying to figure out some sort
of guidelines for when we do include the type and when we dont. if we
say that we only include the type when the component uses its model
then neither Link nor Form qualify. in fact neither will ListItem.
only things like ListView and FormComponents will qualify.
I'd actually prefer untyped Link and Form, since I also don't use Models on
them directly most of the time. But other's may have a different style and
always use Models...
Best regards, --- Jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
