Re: How does serialization work?
Johan Compagner escreveu: thats simple what you there create is an inner class in an inner class... so your textfield has a ajax behavior that is an inner class fo the Visitor inner class so that behavior has a parent reference to the visitor.. make that ajax behavior his own class and your problem is solved Very good catch. :-) Unfortunately the exception was not helpful. Thanks, Adriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
thats simple what you there create is an inner class in an inner class... so your textfield has a ajax behavior that is an inner class fo the Visitor inner class so that behavior has a parent reference to the visitor.. make that ajax behavior his own class and your problem is solved johan On Tue, Nov 4, 2008 at 4:26 PM, Adriano dos Santos Fernandes < [EMAIL PROTECTED]> wrote: > I had a serialization problem (when redeploying the application in Tomcat) > that I can't understand... Basically, I had this on my Page.onBeforeRender: > --- > visitChildren(TextField.class, new Visitor>() { > private static final long serialVersionUID = 1L; > > public Object component(TextField textField) > { > textField.add(new AjaxEventBehavior("onchange") { > private static final long serialVersionUID = 1L; > > @Override > protected void onEvent(AjaxRequestTarget target) > { > if (mode == Mode.NAVIGATE) > { > mode = Mode.EDIT; > setupMode(); > target.addComponent(buttonPanel); > } > } > }); > > setupValidators(textField); > return IVisitor.CONTINUE_TRAVERSAL; > } > }); > --- > > The non-serializable class was the one created by "new > Visitor> () { ... }". Creating MyVisitor and replacing this > call solved the problem: > --- > private abstract class MyVisitor > implements IVisitor, Serializable > { > private static final long serialVersionUID = 1L; > } > --- > > Why should a non-serializable Visitor could case this problem? Does (why?) > it get cached on the page? > > > Adriano > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: How does serialization work?
I had a serialization problem (when redeploying the application in Tomcat) that I can't understand... Basically, I had this on my Page.onBeforeRender: --- visitChildren(TextField.class, new Visitor>() { private static final long serialVersionUID = 1L; public Object component(TextField textField) { textField.add(new AjaxEventBehavior("onchange") { private static final long serialVersionUID = 1L; @Override protected void onEvent(AjaxRequestTarget target) { if (mode == Mode.NAVIGATE) { mode = Mode.EDIT; setupMode(); target.addComponent(buttonPanel); } } }); setupValidators(textField); return IVisitor.CONTINUE_TRAVERSAL; } }); --- The non-serializable class was the one created by "new Visitor> () { ... }". Creating MyVisitor and replacing this call solved the problem: --- private abstract class MyVisitor implements IVisitor, Serializable { private static final long serialVersionUID = 1L; } --- Why should a non-serializable Visitor could case this problem? Does (why?) it get cached on the page? Adriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
we still have a last x pages stored on disk. it is just not a number of pages but it is how many pages fit in the default window size of the file on disk (1 file per pagemap) by default it is 10MB per pagemap and 100MB per total session. so by default you can hold 10 pagemaps of 10MB after that least used pagemaps are cleared. johan On Tue, Nov 4, 2008 at 12:48 AM, Igor Vaynberg <[EMAIL PROTECTED]>wrote: > it is cleaned up when the session expires. it used to be that we only > kept X last pages in the store, but now that we use disc that seems to > be redundant. > > -igor > > On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <[EMAIL PROTECTED]> > wrote: > > > > 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 Oyhttp://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] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: How does serialization work?
On Mon, 03 Nov 2008, Igor Vaynberg wrote: > 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. Right, it doesn't matter from the serialisation point of view, but if you replace the component in the component hierarchy, you should make sure that you also update these references to point to the new component instances. That's why I prefer accessing child components dynamically whenever it can be easily done. Best wishes, Timo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
On Mon, 03 Nov 2008, Graeme Knight wrote: > Where on disk are these serialized pages? Servlet context temporary directory, which can be something like /tmp/ or %HOME%\Local Settings\Temp . It can be changed in web.xml (and I suppose that whether it's the servlet context temp dir or some other place can be changed with some Wicket setting or by providing a custom pagestore). I remember seeing a presentation by Johan on some of this stuff on slideshare.net . Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
On Mon, Nov 3, 2008 at 5:09 PM, Graeme Knight <[EMAIL PROTECTED]> wrote: > Where on disk are these serialized pages? i would imagine in a tmp dir, i would have to look in code for the exact location - you can do the same > I remember reading you only cache > the current page in memory. Is that correct? yes, when using the diskstore only the current page is in httpsession. the other pages are only needed if the user uses the back button. > This serializing on disk - what > is the strategy for keeping these files in sync in a clustered environment? standard http session replication. when a node receives a page from another node via session replication it adds it to its own local diskstore. -igor > > Appreciate the help very much! Graeme. > > > igor.vaynberg wrote: >> >> it is cleaned up when the session expires. it used to be that we only >> kept X last pages in the store, but now that we use disc that seems to >> be redundant. >> >> -igor >> >> On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <[EMAIL PROTECTED]> >> wrote: >>> >>> 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
Re: How does serialization work?
Thanks Igor! A great help! Where on disk are these serialized pages? I remember reading you only cache the current page in memory. Is that correct? This serializing on disk - what is the strategy for keeping these files in sync in a clustered environment? Appreciate the help very much! Graeme. igor.vaynberg wrote: > > it is cleaned up when the session expires. it used to be that we only > kept X last pages in the store, but now that we use disc that seems to > be redundant. > > -igor > > On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <[EMAIL PROTECTED]> > wrote: >> >> 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 Oyhttp://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] >> >> > > - > 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--tp20311180p20313794.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]
Re: How does serialization work?
it is cleaned up when the session expires. it used to be that we only kept X last pages in the store, but now that we use disc that seems to be redundant. -igor On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <[EMAIL PROTECTED]> wrote: > > 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 Oyhttp://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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 Oyhttp://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]
Re: How does serialization work?
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 Oyhttp://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]
Re: How does serialization work?
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 Oyhttp://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]
Re: How does serialization work?
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 Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How does serialization work?
Hi! Again, I'm new, so hopefully I'm not posting in a bad way here. I've looked 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). I have a simple page and form as below. The AuthenticationModel is a LoadableDetatchableModel that queries the database for a username/password based on a cookie id (I've cut all this code out for the example below). My questions are perhaps super naive, but for some reason I am panicking about serialized objects: 1) Exactly WHAT is getting serialized and where and when? 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. 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). Many thanks for any help once again... public class LoginPage extends AbstractWebPage { public LoginPage() { // create a login form and add it to the page add( new LoginForm() ); } } public class LoginForm extends Form { private static final long serialVersionUID = 3975327499669581927L; private TextField userIdField; private PasswordTextField passwordField; public LoginForm() { super( "loginForm", new AuthenticationModel() ); userIdField = new TextField( "username", new PropertyModel( authenticationModel, "username" ) ); passwordField = new PasswordTextField( "password", new PropertyModel( authenticationModel, "password" ) ); // add the components to the form add( userIdField ); add( passwordField ); } @Override protected void onSubmit() { // authenticate user } } -- View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20311180.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]