> Wicket 1.5: https://cwiki.apache.org/confluence/x/qIaoAQ
> This explains how page storing works.

You were right about 1.4 ;)

> Question: If you don't serialize the page then how would you get it if
> it is not stored when the user presses browser back button ?

Keep it in memory as it is.

**
Martin

>
>>
>> **
>> Martin
>>
>> 2012/2/23 Bernard <bht...@gmail.com>:
>>> If there are thousands of objects in a page then there is the question
>>> whether all of these objects actually represent state - state being
>>> the only reason why Wicket should serialize the page.
>>>
>>> In other words, is the page so complex that it requires 10MBytes to
>>> serialize itself in a manner that it can be re-created accurately from
>>> a stream. If yes then there is probably nothing you can do about it.
>>>
>>> If not then perhaps Wicket could be improved in that area. I would not
>>> be surprised if that was the case.
>>>
>>> Consider Java Swing desktop components. Swing has optimizations such
>>> as TableCellRenderer and TableCellEditor that are used as single
>>> instances to render cells for all rows in a column or more. If that
>>> makes sense in desktop applications with cheap memory and CPU then
>>> this makes even more sense on the server side. However, Wicket does
>>> NOT have such components and therefore really large lists are
>>> hopeless. There are things like IItemReuseStrategy but I cannot see
>>> how these would achieve the required efficiency.
>>>
>>> On Thu, 23 Feb 2012 09:06:42 +0200, you wrote:
>>>
>>>>I think that would be something that should be implemented at wicket
>>>>core... anybody done this before?
>>>>
>>>>Is there any way to tell wicket NOT to serialize a page? For example
>>>>give a timer.... if user does not invoke the page for 1 minutes it
>>>>will not be serializeed..?
>>> [snip]
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> 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