Yes, I need that exact state. 2008/11/14 James Carman <[EMAIL PROTECTED]>
> Do the pages you need to go back to need to be the exact same > instances (do you need that exact state)? > > On Thu, Nov 13, 2008 at 9:20 PM, Cristiano Kliemann > <[EMAIL PROTECTED]> wrote: > > Hi! > > > > Some questions about Wicket serialization... > > > > Let's say I have two pages, A and B, and page B holds a reference to page > A. > > First, an instance of page A is rendered and gets serialized by Wicket. > Then > > the user clicks on a button that creates an instance of page B, sets a > > reference to the current page A and executes setCurrentPage using page B > as > > the response page, like the following: > > > > PageB b = new PageB(); > > b.setPageA(this); > > setResponsePage(b); > > > > The first question is: when the page B gets serialized, Wicket serializes > > the instance of page A again, right? If several of my pages need to hold > > references to other pages, the page store gets very big. I know that > Wicket > > must serialize the same instance again because one of its attributes > might > > have been changed. > > > > In my application, sometimes I need to hold references to the page that > > originated certain operations. Later, the user has the option to go back > to > > that page. The 'problem' is that the originated page gets serialized all > the > > time, and I don't need that. It gets worse when I have a chain of > > references. > > > > So, another question is: what's the best way to reference another page > > without serializing it again? I know I can hold the page's page map, id > and > > version and get the instance on demand. Is it a good solution? Is there > > someting ready for that? > > > > Thanks > > Cristiano > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
