Hi,
I try to make my components re-usable whenever this is feasible. A
problem that I'm running into is this:
A Component itself decides that it needs a CompoundPropertyModel,
because it wants to use the automatic property model lookups feature
when a model is omitted on a child component.
public class MyPanel extends Panel {
public MyPanel(String id, IModel model) {
super(id, new CompoundPropertyModel(model));
add(new Label("person.name"));
add(new TextField("person.address.street"));
// etc.
}
}
But, the method setDefaultModel (inherited from Component) on MyPanel
can be used by outside code to change the model. And that should be ok.
However, when an outside class does that, it needs to know that it
should set a CompoundPropertyModel, or else MyPanel will break. I don't
really like that, because the fact that I need a CompoundPropertyModel
is an implementation detail that I want to have encapsulated in my
Component, and not something that the rest of my code should know about.
I could override setDefaultModel and wrap any argument inside a
CompountPropertyModel, but I would still have to do the same in the
constructor, since a model that was passed in the constructor is not set
using the method setDefaultModel, but using setModelImpl.
Is there a clean and simple solution to this?
I'm beginning to think that the feature provided by
CompoundPropertyModel (and perhaps even any IComponentInheritedModel) is
perhaps not something that should conceptually be provided by a model,
but rather by a new concept; something like an IModelAccessor or
IModelModifier (I hope you catch my meaning).
The way that a model is used inside a Component is, I think, an
implementation detail, private to a component itself. The model itself
is something that should be set by the outside world on the Component.
So even though they can, technically, be integrated in one concept (as
it is now), it may be better from the perspective of encapsulation and
reusability to separate these two concepts.
I'm interested to know what the wicket designers think about this.
Kind regards,
Erwin Bolwidt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
