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]
