I suppose so.. Well, at least it's a loophole for big chucks of readonly data.

Thanks for your replies!

Groet,
Vincent

On Jul 26, 2010, at 17:22, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:

> no, this will not work for the larger usecase. like i mentioned
> before, if you place links or textfields or anything but labels into
> listitems they will not work.
> 
> -igor
> 
> On Mon, Jul 26, 2010 at 3:41 AM, Vincent Lussenburg
> <vincent.lussenb...@gmail.com> wrote:
>> Hi Igor,
>> 
>> Excellent suggestion! It took some experimenting, but we managed to get it
>> to work.
>> 
>>        add(new PropertyListView<MonthAmount>("month", new
>> XListViewModel(x)) {
>>            {
>>                setReuseItems(false);
>>                setVersioned(false);
>>            }
>> 
>>            @Override
>>            protected void populateItem(final ListItem<MonthAmount> item) {
>> // ... }
>> 
>>            @Override
>>            protected void onDetach() {
>>                removeAll();
>>                super.onDetach();
>>            }
>>        });
>> 
>> The gotcha's:
>> 
>> - modifying the component tree AFTER rendering increments the page version,
>> which is obviously unwanted and causes fatal errors (since the form action
>> still points the old version of the page which is not stored in the
>> session).
>> - disabling versioning of the list view circumvents this. It seems pretty
>> logical to me - since it is to be re-populated upon each request (it's
>> pretty much stateless), it should not impact the version.
>> 
>> I'm feeling pretty good about this approach - we'll probably make a separate
>> ListView component out of it. Do you have any thoughts on it? Should I
>> create a feature request in Jira to change the implementation of ListView to
>> behave like I described?
>> 
>> Regards,
>> Vincent.
>> 
>> 
>> On 22 July 2010 18:41, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
>> 
>>> what about onDetach() ?
>>> 
>>> -igor
>>> 
>>> On Thu, Jul 22, 2010 at 6:17 AM, Danny van Bruggen <tsuih...@gmail.com>
>>> wrote:
>>>> No, we can't change the component tree in onAfterRender - Wicket
>>>> complains that it cannot increase the page version after rendering.
>>>> 
>>>> On 7/21/10, Vincent Lussenburg <vincent.lussenb...@gmail.com> wrote:
>>>>> I remember trying that, but getting slapped by wicket for trying to
>>> change
>>>>> the component tree after rendering.. Or am I missing something?
>>>>> 
>>>>> We'll doublecheck it tomorrow.
>>>>> 
>>>>> Groet,
>>>>> Vincent
>>>>> 
>>>>> On Jul 21, 2010, at 18:37, Igor Vaynberg <igor.vaynb...@gmail.com>
>>> wrote:
>>>>> 
>>>>>> if the data is strictly read-only and does not contain any links you
>>>>>> can try removing the list items in afterrender()
>>>>>> 
>>>>>> -igor
>>>>>> 
>>>>>> On Wed, Jul 21, 2010 at 7:50 AM, Danny van Bruggen <tsuih...@gmail.com
>>>> 
>>>>>> wrote:
>>>>>>> Hello all,
>>>>>>> 
>>>>>>> We're developing a non-Ajax application that displays a bunch of big
>>>>>>> tables - about five columns, 300 rows. Since session size was
>>>>>>> increasing a lot, we looked into the cause of it, and (after making
>>>>>>> everything detachable and switching to PropertyListModel) found out
>>>>>>> that the ListItems of each ListView still accounted for about 100k.
>>>>>>> 
>>>>>>> Since all the data in the tables is read only, we're wondering if we
>>>>>>> can skip serializing the ListItems. Is this possible?
>>>>>>> 
>>>>>>> Is there another approach?
>>>>>>> 
>>>>>>> Danny van Bruggen
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to