That would be a bug then. What wicket version are you using? -Matej
On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann <[EMAIL PROTECTED]> wrote: > Martijn, > > I'm pretty sure it is serializing PageA again. I've put some breakpoints to > confirm it (at DiskPageStore.PageSavingThread.run()). Also, the growt rate > of the page store indicates that. > > The test I've run: > > PageA has one simple link (to do some stuff and go to PageB) and a byte > array with 25KB. > PageB has another link (to go back to PageA instance), the reference to > PageA and a byte array of 10KB. > > After PageA is first serialized, the page store goes from nothing to about > 27KB. When PageB is serialized, it goes to about 64KB, a 37KB difference. > > Testing the same thing but letting the reference to PageA null makes a lot > of difference. When PageB is serialized, the page strore it grows from 27KB > to just 38KB (a 11KB difference). > > -Cristiano > > > 2008/11/14 Martijn Dashorst <[EMAIL PROTECTED]> > >> iirc Wicket serialization is smart enough to discover that PageA >> should not be serialized as part of PageB, but instead will replace it >> with a reference to PageA's serialized instance. >> >> Martijn >> >> On Fri, Nov 14, 2008 at 7:15 AM, Igor Vaynberg <[EMAIL PROTECTED]> >> wrote: >> > if you are using 1.4rc1 there is no need to pass page references >> > anymore. see Page#getPageId() and requestcycle.urlfor(pageid) >> > >> > -igor >> > >> > On Thu, Nov 13, 2008 at 6: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] >> > >> > >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.4 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> >> --------------------------------------------------------------------- >> 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]
