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
>
>
