Hi. I wondered another thing - how and when are the serialized objects cleaned up? Is there a mechanism for making sure large amounts of memory or disk are not soaked up by long running sessions and lots of user interactions?
Thanks again, Graeme. Graeme Knight wrote: > > Timo! > > Thanks for your answers - so you think its better NOT to have the > components as private member variables? I may misunderstand... > > 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world into > the Wicket world... > > Wicket in Action - VERY readable and well written, but perhaps I didn't > get far enough along to get to the serialization parts (I'm just beginning > Part 2). > > Cheers, Graeme. > > Timo Rantalaiho wrote: >> >> On Mon, 03 Nov 2008, GK1971 wrote: >>> through the forum but couldn't find the answer. Couldn't find the >>> answers >>> from Tapestry in Action (I'm sure they are there if anyone can point me >>> at a >>> page). >> >> You might want to have a look at Wicket in Action :--) >> >>> 1) Exactly WHAT is getting serialized and where and when? >> >> The page, which includes its whole Component tree. >> >>> 2) What are the main classes in the framework responsible for >>> serialization >>> that I can look at (I have the source)? I guess I am after understanding >>> the >>> flow of logic. >> >> I find it easiest to start from Session.requestDetached(). >> There you have >> >> page.getPageMap().put(page); >> >> => >> >> SecondLevelCacheSessionStore.put(Page) >> >> => >> >> DiskPageStore.storePage(String sessionId, Page page) >> >> and there's already stuff about serialisation. >> >> I'm sure that someone can give you a more scientific answer :) >> >>> 3) What happens if I make userIdField and passwordField scoped to the >>> constructor only? Is it common not to have them as member objects and >>> why? >>> (I've not tried this yet, just wondered). >> >> In here >> >>> add( userIdField ); >>> add( passwordField ); >> >> you add them as children of the constructed component. >> You can always access them for example with a visitor, if >> needed, and holding references to them makes it harder to >> replace them if needed (though it shouldn't be a problem if >> they won't be replaced). >> >> Best wishes, >> Timo >> >> -- >> Timo Rantalaiho >> Reaktor Innovations Oy <URL: http://www.ri.fi/ > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20312968.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
