Johan,
I had a similar idea, except that I used PropertyModel (which is what
CompoundPropertyModel.bind does anyway).
The issue that I had with this one is that every component exposes a
setModel method, so I always wonder how my components will behave if
someone calls it. In this case, if someone calls BigPage.setModel,
then SmallComponent will be left pointing to the wrong model. I try
to have only component that holds the model object directly and let
other components access it indirectly.
I suppose that I could do this:
add(new SmallComponent("smallObject", new PropertyModel(this,
"modelObject.smallObject")))
However, ComponentPropertyModel does the same thing in a clearer and
slightly more efficient manner.
W
On Feb 16, 2009, at 3:04 PM, Johan Compagner wrote:
do it then a bit different
public class BigPage {
public BigPage(BigObject object) {
CompoundPropertyModel model = new CompoundPropertyModel(object)
setModel(model)
add(new SmallComponent("smallObject",
model.bind("smallObject.name"));
}
}
public class SmallComponent {
public SmallComponent(IModel model) {
add(new Label("name", model);
}
}
or
public class BigPage {
public BigPage(BigObject object) {
CompoundPropertyModel model = new CompoundPropertyModel(object)
setModel(model)
add(new SmallComponent("smallObject", model.bind("smallObject"));
}
}
public class SmallComponent {
public SmallComponent(IModel model) {
setModel(new CompoundPropertyModel(model));
add(new Label("name");
}
}
On Mon, Feb 16, 2009 at 20:59, Willis Blackburn <wbo...@panix.com>
wrote:
Johan,
The below solution requires that SmallComponent know it's parent has
CompoundPropertyModel and that there is a member called
"smallObject." I'm
trying to keep SmallComponent generic, like the Wicket built-in
components.
W
On Feb 16, 2009, at 2:46 PM, Johan Compagner wrote:
yes initmodel shouldnt call getModel() on the parent
because that was a big performance penalty on some solutions
because that
would create and walk over the complete hierarchy of things
and then many many in between models are created, that dont do
really
anything.
But why not something like this:
public class BigPage {
public BigPage(BigObject object) {
setModel(new CompoundPropertyModel(object));
add(new SmallComponent("smallObject", getModel()));
}
}
public class SmallComponent {
public SmallComponent(CompoundPropertyModel model) {
add(new Label("name", model.bind("smallObject.name"));
}
}
johan
On Mon, Feb 16, 2009 at 05:50, Igor Vaynberg
<igor.vaynb...@gmail.com
wrote:
hrm, looks like johan changed it here
526472 4/7/07 12:13 PM 3 jcompagner component
initModel will
not call
getModel on the parent, but will directly use the field (so that
not
all kinds of inbetween models are created) if model is an
iwrapmodel
and the wrapped modes is an inherited one then the model will be
cleared on detach Compound.getTarget() removed. Compound will not
unwrap in getObject() anymore AbstractPropertyModel will unwrap
until
all models are processed
seems to me that the change breaks what i thought the contract of
initmodel was... we should discuss on dev, mind sending a message?
-igor
On Sun, Feb 15, 2009 at 10:08 AM, Willis Blackburn <wbo...@panix.com
>
wrote:
Igor,
Are you sure that will work? I don't think that SmallComponent's
initModel
method is ever called, because when the Label that is part of
SmallComponent
is searching for a model (in Component.initModel), it invokes the
getModelImpl method of SmallComponent, which doesn't call
initModel.
(The
comment in the code says "Don't call getModel() that could
initialize
many
in-between useless models."
W
On Feb 15, 2009, at 12:23 PM, Igor Vaynberg wrote:
public class smallcomponent extends component {
protected imodel initmodel() {
imodel model=super.initmodel();
return new compoundpropertymodel(model);
}
}
-igor
On Sun, Feb 15, 2009 at 8:19 AM, Willis Blackburn <wbo...@panix.com
>
wrote:
Hello,
I have a situation that keeps coming up. All of my solutions
have
seemed
clumsy, which makes me think that there's a better way of
approaching
this
that I just haven't figured out. Can someone point me in the
right
direction?
What I want is to have a Page that uses CompoundPropertyModel,
and
then
include a component on that page that also uses
CompoundPropertyModel.
So
roughly it looks like this:
public class BigObject {
public SmallObject get SmallObject() { ... }
}
public class SmallObject {
public String getName() { ... }
}
public class BigPage {
public BigPage(BigObject object) {
setModel(new CompoundPropertyModel(object));
add(new SmallComponent("smallObject"));
}
}
public class SmallComponent {
public SmallComponent() {
add(new Label("name"));
}
}
If I try to do just this, then I get an error because the
label that's
part
of SmallComponent finds the BigPage model and fails because
there's no
property of BigObject called name.
So obviously SmallComponent needs some model:
public class SmallComponent {
public SmallComponent(IModel model) {
setModel(new CompoundPropertyModel(model));
add(new Label("name"));
}
}
But what model to give it? I tried passing it new
ComponentPropertyModel("smallObject"), which didn't work because
ComponentPropertyModel implements IComponentAssignedModel and
thus
can't
be
directly wrapped in CompoundPropertyModel. Adding a call to
wrap() in
the
SmallComponent constructor fixed the problem, but I'm not sure
if I
can
just
call wrap and carry on or if there will be some unforeseen
consequence
of
that down the road. Is there a standard way of doing this?
Thanks,
Willis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
