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] > >
