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

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

Reply via email to