There are calls to #setDefaultModel() from various places, e.g.
MarkupContainer and FormComponent.
I'm not sure we should disallow this usage completely (although it would
simplify MarkupContainer's handling of IComponentInheritedModel).
For me it would be enough to ease things for those who "might not got
the whole picture", a *protected* would suffice for that.
Sven
On 09/27/2012 02:22 PM, Michael Mosmann wrote:
Am 27.09.2012 14:19, schrieb Sven Meier:
> IMHO changing a component's model isn't the "wicket way" so I'd
suggest changing the visibility of Component#setDefaultModel() to
protected.
mark as deprecated and remove it later.. ?
Even a simpler example might fail (no PropertyModel involved):
class APanel extends Panel {
APanel(String id, IModel<Some> model) {
super(id,model);
add(new BPanel("b", model);
}
}
A client using APanel might later change the model, leaving BPanel
working on the old model:
aPanel.setDefaultModel(otherModel);
You could argue that APanel should be made failsafe when passing the
model:
add(new BPanel("b", new PropertyModel(this, "defaultModel")));
But it would be much easier if APanel could assume that its model
isn't changed unattendedly.
IMHO changing a component's model isn't the "wicket way" so I'd
suggest changing the visibility of Component#setDefaultModel() to
protected.
Sven
On 09/27/2012 10:47 AM, Martin Grigorov wrote:
I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.
I'll let others give their opinions too.
On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann
<mich...@mosmann.de> wrote:
Am 27.09.2012 09:51, schrieb Martin Grigorov:
Hi,
a dont care about the type issue here.. Maybe i can explain it
again in an
other way:
APanel uses model instance A and the label uses a property model
instance P
which uses a reference to model instance A.
After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before.
So the
label does not see any changes, because no one tells the model
instance P,
that it should use B instead of A. I think, there are rare cases
for such a
usage.
thanks
Michael
Hi,
In this particular code I think the "problem" is PropertyModel, since
it brings the type unsafety.
Another solution is to make Component<T>, this way we can remove
#setDefaultModel() and have #setModel(IModel<T>) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.
For now you can use GenericPanel, GenericPage and all FormComponent.
On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann
<mich...@mosmann.de>
wrote:
Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,
I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance,
the
second
only change the value in the existing model. Some pseudo-code:
class APanel extends Panel {
APanel(String id,IModel<Some> model) {
super(id,model);
add(new Label("name",new
PropertyModel(getDefaultModel(),"name"));
}
}
If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is
fine, but
its not. A child component does not use
getParent().getDefaultModel() to
get
these changes. I saw a lot of code like this, which leads to
trouble, if
you
change the model and not the value.
If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many "you
might not
got
the full picture how to use wicket the right way" errors.
Michael
Hi,
Most of the time it is recommended to use a dynamic model, so
there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().
What is the problem you face with it ?
On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann
<mich...@mosmann.de>
wrote:
Hi,
is there any usefull application of
Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component
model...
thanks
Michael
