yes, there is a huge fundamental problem with your approach: you keep
the object reference which means the object is serialized instead of
being retrieved through a loadable detachable model.
-igor
On Thu, Oct 2, 2008 at 10:54 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote:
>
> Thanks for the explanation. Still, one questions remains: is there
> a fundamental problem with the first approach or is it ok to use
> the object directly?
>
> J.
>
> Igor Vaynberg wrote:
>>
>> final TestItem itemModel = (TestItem) item.getModelObject();
>>
>> ^ on this line you retrieve the object from the model, you then use
>> this reference inside the onclick() which is called during another
>> request. since you use the model object reference directly it is not
>> loaded from the model.
>>
>> my code, on the other hand, never keeps a direct reference to the
>> model object, instead it retrieves it from the model inside onclick()
>>
>> -igor
>>
>> On Thu, Oct 2, 2008 at 10:10 AM, Jürgen Lind <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Igor Vaynberg wrote:
>>>>
>>>> your link works on the object and not on the model, instead
>>>>
>>>> add(new link("delete", item.getmodel()) { onclick() {
>>>> delete(getmodelobject()); }});
>>>>
>>> Thank you for your quick reply.
>>>
>>> Well the code is roughly the same(?) as in Listing 5.12 of WiA and there
>>> a custom Model is used to illustrate the solution. However, I thought my
>>> test would show me the problem first... Using your code above, the
>>> effect is as expected, i.e. the "wrong" (new) item is returned to be
>>> deleted.
>>>
>>> Now, the question is, what is wrong with my first implementation?
>>> It would seem that the problem that is solved using a custom ItemModel
>>> does not even occur. Or does that code prevent wicket from effectively
>>> detaching model objects and should thus be avoided? What would be the
>>> best practice here?
>>>
>>>
>>> J.
>>>
>>>> -igor
>>>>
>>>> On Thu, Oct 2, 2008 at 9:04 AM, Jürgen Lind <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>
>>>>> Hi there,
>>>>>
>>>>> I have been struggling for some time now to understand how
>>>>> LoadableDetachableModel and a ListView work together. The starting
>>>>> point
>>>>> was Chapter 5.5.2 of "Wicket in Action" where it is recommended to
>>>>> provide
>>>>> your own ItemModel if the underlying list changes frequently. To try
>>>>> out
>>>>> how Wicket behaves without such a custom ItemModel, I wrote the
>>>>> following
>>>>> Test:
>>>>>
>>>>> <body>
>>>>> <em wicket:id="listview">
>>>>> <span wicket:id="label"></span><a wicket:id="delete">delete</a>
>>>>> </em>
>>>>> </body>
>>>>>
>>>>>
>>>>> LoadableDetachableModel model = new LoadableDetachableModel() {
>>>>>
>>>>> @Override
>>>>> protected Object load() {
>>>>> System.out.println("load");
>>>>> return Arrays.asList(new TestItem[] {
>>>>> new TestItem("a" + Math.random()),
>>>>> new TestItem("b" + Math.random()),
>>>>> new TestItem("c" + Math.random()) });
>>>>> }
>>>>>
>>>>> protected void onDetach() {
>>>>> System.out.println("detach");
>>>>> }
>>>>>
>>>>> };
>>>>>
>>>>> ListView listview = new ListView("listview", model) {
>>>>> protected void populateItem(ListItem item) {
>>>>> final TestItem itemModel = (TestItem) item.getModelObject();
>>>>> item.add(new Label("label", itemModel.toString()));
>>>>> item.add(new Link("delete") {
>>>>>
>>>>> @Override
>>>>> public void onClick() {
>>>>> System.out.println("Delete " + itemModel);
>>>>> }
>>>>> });
>>>>> }
>>>>> };
>>>>>
>>>>> add(listview);
>>>>>
>>>>>
>>>>> Now, I would expect that when I hit the "delete" link, Wicket would
>>>>> call
>>>>> the
>>>>> "load" Method of the LoadableDetachableModel before printing
>>>>> "Delete..."
>>>>> as
>>>>> the
>>>>> default implementation will use the index and the list to determine the
>>>>> item
>>>>> to
>>>>> delete. To my surprise, however, the "Delete..." message is printed
>>>>> with
>>>>> the
>>>>> correct item and the "load" Method is called afterwards. In my
>>>>> understanding,
>>>>> this contradicts the idea of the LoadableDetachableModel since Wicket
>>>>> seems
>>>>> to
>>>>> have a copy of the original list somewhere so that it can determine the
>>>>> list
>>>>> item on which the action was invoked before loading the underlying
>>>>> list.
>>>>>
>>>>> Can someone spot my mistake?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> J.
>>>>>
>>>>> --
>>>>> Dr. Jürgen Lind
>>>>> iteratec GmbH Fon: +49 (0)89 614551-44
>>>>> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
>>>>> 82008 Unterhaching Web: www.iteratec.de
>>>>>
>>>>> Sitz und Registergericht der iteratec GmbH: München HRB 113 519
>>>>> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
>>>>> Menzel
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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]
>>>>
>>> --
>>> Dr. Jürgen Lind
>>> iteratec GmbH Fon: +49 (0)89 614551-44
>>> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
>>> 82008 Unterhaching Web: www.iteratec.de
>>>
>>> Sitz und Registergericht der iteratec GmbH: München HRB 113 519
>>> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>
>
> --
> Dr. Jürgen Lind
> iteratec GmbH Fon: +49 (0)89 614551-44
> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
> 82008 Unterhaching Web: www.iteratec.de
>
> Sitz und Registergericht der iteratec GmbH: München HRB 113 519
> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel
>
>
> ---------------------------------------------------------------------
> 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]
