[Wicket-user] Re: The other side of Wicket ...

[Ashley Aitken]

Hello Igor (et al.), Thank you for your reply and explanations. the top container of components in wicket is the page. session keeps references to x number of pages for callbacks and backbutton support. so these are only serialized when replication of the session occurs.  So the pages are only serialised when the session is serialised for replication.  I am not sure how Wicket (or if it is even within Wicket's scope) handles replication/clustering, but if one were using sticking sessions (sessions mapped to the same server in the cluster) then I guess one wouldn't need to serialise the session or pages at all.  Does that sound right? components also have models. when the user calls setModelObject() 2nd+ time we clone the model by serialization so that we can version it. Ok thanks, I didn't realise that.  I guess you serialise the cloned component model to save space or save to disk (rather than leave the objects in memory)?  The models would thus need to be detached (e.g. separate or using a lazyinitproxy) from the full business model.  I'm still trying to get my head around what would happen to the full business model if someone hit the back button and went back to a previous component model ... The back button is surely the bane of the Web application developer.   So, let me see if I understand correctly (please someone correct me if I am wrong).  Sessions are only serialised for replication/clustering (i.e. if one needs to be able to process any request on any server). Pages are only serialised when Sessions are serialised (as above). Models of components (pages, panels, etc.) are serialised when changed (after being set) to handle the back button. So if a Web application has a large business model / service that needs to remain in memory across multiple request-response loops (and as such the application uses sticky sessions) then sessions and pages will not be serialised.  If the application saves no previous pages (so the back button won't work) would the application need to worry about serialised component models? So in this case there would be no reason to need injection or lazyinitproxies etc?    I can see mostly how this works.  However, although others have proclaimed it so, it doesn't seem that elegant or easy to me. if you are going to say something like this you can at least tell us which part of it does nto seem elegant or easy. Firstly, I am sorry I wrote that comment like that, it was late and I was tired.  I wasn't trying to be critical I was just remarking that whereas the "front-side" of Wicket (views) seemed to be thought out beforehand, the "back-side" integration seemed to be an "add-on."  I guess that is the way with new open source projects as they develop under the public eye, and again I apologise.  Secondly, I guess I was also hoping that Wicket would have a more integrated and transparent approach (although I understand that Wicket components are in some sense unmanaged) to maintaining links to business services and larger graphs of business objects.  I see now that it probably does as much as most other frameworks (except for the extra work needed for component models as discussed above). I am not sure if there are any Web frameworks that transparently handle mobile sessions automatically (especially when there are dependencies).   I know there are many types of Web applications (from very light stateless to very heavy stateful applications) and most of these problems are common to all Web application frameworks.  I'm just trying to get a better picture of how Wicket would generally be used to handle each of these situations (although I am more interested in the heavy stateful type of applications at the present time).   Thanks again. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com Skype Name: MrHatken (GMT + 8 Hours!)