as far as serialization wicket uses default java serialization with a few tweaks to optimize it.
> Thanks for your answers - so you think its better NOT to have the components > as private member variables? I may misunderstand... it doesnt matter if you do this. because the page object is serialized and those components are fields of the page they are serialized only once and further references are replaced with links, this is how serialization works and it preserves proper references. -igor > > '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--tp20311180p20312172.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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
