Not really if PageA refrences PageB, and PageB references pageA then during serialization of PageA we should detect circular reference and only serialize PageA once. Also PageA serialization data should only contain placeholder of PageB, not the pageB itself.
-Matej On Mon, Nov 17, 2008 at 9:45 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > this is exactly how we want it to happen. > > On Sun, Nov 16, 2008 at 9:24 PM, Mikko Pukki <[EMAIL PROTECTED]>wrote: > >> Hi, >> >> I tried to recreate similar situation where Page A has a link to PageB >> and PageB holds a reference to PageA. I got similar result with as >> Cristiano. >> though I only tried Wicket 1.3.5. >> >> PageA is serialized twice and pageId, versionNumber and ajaxVersionNumber >> are same with two instances of PageA (I put a breakpoint and checked >> contents >> of List "pages" on DiskPageStore line 961). Field "data" was also >> identical. >> >> Also on line 246: >> channel.write(ByteBuffer.wrap(page.getData()), window.getFilePartOffset()); >> >> PageA is written to channel twice with identical content. >> >> >> Hope this helps. >> >> Regards, >> Mikko Pukki >> >> -----Original Message----- >> From: Johan Compagner [mailto:[EMAIL PROTECTED] >> Sent: 14. marraskuuta 2008 21:10 >> To: [email protected] >> Subject: Re: Page references and serialization >> >> >Doesnt have to be a bug, (it could be a new version of page a) but >> >besides that dont we have a sliding window in the pagemap, so if page >> >a is touched shouldnt it get its own new place in the file (more 2 the >> >top) so that it doesnt get overwritten later on to early? >> > >> >On 11/14/08, Matej Knopp <[EMAIL PROTECTED]> wrote: >> >> 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] >> >> >> >> >> >> --------------------------------------------------------------------- >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
