On 5/4/06, Ashley Aitken <[EMAIL PROTECTED]> wrote:
almost but not exactly :) if you have fallback in your cluster the session would be replicated from user's node to the backup-buddy node, or multicast to all nodes, or whatever - depending on your fallback strategy. so in this case the session is replicated on every request. but, if you have a fast backplane between cluster nodes this should not be a big deal.
no, we actually clone by serialization. the Clonable interface in java is a pita and so we chose to clone by serialization. see wicket.util.lang.Object.cloneObject(Object)
yes, the models are detached before we clone them.
in this case we would roll the model and any other changes back to what it was on the page thereby restoring the component hierarchy to what it was before the backbutton was pressed.
yes, especially when building web applications and not web sites
see above
yep
yep
i think you misunderstand what the model is. the model is the databinding. it allows the component to retrieve and store data in an abstract way.
that depends. if you are always going to be careful about looking up the service layer objects and never leaving a reference to them, then yes, you do not need injection or wicket proxies
its ok to be critical as long as you explain what is bothering you. this is how we know what parts of wicket need work.
wicket is a focused framework. it focuses on doing one thing and doing it extremely well. that thing is making the creation of complex web based uis very easy. integration with the middle tier is not an afterthought but is probably not the highest priority either. as i said, i think our integration is as good as it can be for an unmanaged framework, and i will stand by this statement until someone can show me a better way of doing it.
it is unmanaged in the sense that /you/ instantiate components and manage their lifecycle and /not/ some ioc container. if you search the list for 'spring' you will find a few threads where i go into detail as to why the injection/proxies work the way they do.
the extra work with models gives you the backbutton support, something that almost no other framework that stores state in session does.
well, wicket is perfect for the heavily stateful applications imho. i think the best way to learn would be to write a small application in the prod like environment. see where the challenges are, and we will try to help you along the way.
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?
almost but not exactly :) if you have fallback in your cluster the session would be replicated from user's node to the backup-buddy node, or multicast to all nodes, or whatever - depending on your fallback strategy. so in this case the session is replicated on every request. but, if you have a fast backplane between cluster nodes this should not be a big deal.
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)?
no, we actually clone by serialization. the Clonable interface in java is a pita and so we chose to clone by serialization. see wicket.util.lang.Object.cloneObject(Object)
The models would thus need to be detached ( e.g. separate or using a lazyinitproxy) from the full business model.
yes, the models are detached before we clone them.
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 ...
in this case we would roll the model and any other changes back to what it was on the page thereby restoring the component hierarchy to what it was before the backbutton was pressed.
The back button is surely the bane of the Web application developer.
yes, especially when building web applications and not web sites
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).
see above
Pages are only serialised when Sessions are serialised (as above).
yep
Models of components (pages, panels, etc.) are serialised when changed (after being set) to handle the back button.
yep
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?
i think you misunderstand what the model is. the model is the databinding. it allows the component to retrieve and store data in an abstract way.
So in this case there would be no reason to need injection or lazyinitproxies etc?
that depends. if you are always going to be careful about looking up the service layer objects and never leaving a reference to them, then yes, you do not need injection or wicket proxies
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.
its ok to be critical as long as you explain what is bothering you. this is how we know what parts of wicket need work.
wicket is a focused framework. it focuses on doing one thing and doing it extremely well. that thing is making the creation of complex web based uis very easy. integration with the middle tier is not an afterthought but is probably not the highest priority either. as i said, i think our integration is as good as it can be for an unmanaged framework, and i will stand by this statement until someone can show me a better way of doing it.
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).
it is unmanaged in the sense that /you/ instantiate components and manage their lifecycle and /not/ some ioc container. if you search the list for 'spring' you will find a few threads where i go into detail as to why the injection/proxies work the way they do.
the extra work with models gives you the backbutton support, something that almost no other framework that stores state in session does.
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).
well, wicket is perfect for the heavily stateful applications imho. i think the best way to learn would be to write a small application in the prod like environment. see where the challenges are, and we will try to help you along the way.
-Igor
