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.Sorry, but you lost me there. Are you saying if one had sticky sessions with fallback clustering then Wicket would still have to replicate the session? I was thinking more that the session would just fail if the server hosting the session failed. Further, I don't believe Wicket does clustering itself (please correct me if I am wrong) so does it conform to some sort of clustering API?
Wicket doesn't replicate..
That does your appserver. That is the one that replicates sessions. We just put stuff in. (as little as possible)
So no wicket doesn't do clustering. Wicket could just make youre own ISessionStore implementation and you can do youre own clustering.
Clone by serialisation? I guess you mean you serialise and then un/de-serialise. So you don't serialise to save to disk?
yes only in mem, not to disk. We just create a copy of the object by serialize and deserialize it.
By detach I was thinking more of separating the model objects from some greater set of business objects (which may in effect be, but not specifically be, what you were referring to). I know, however, that Wicket has the notion of a "detachable model."I guess this correspond well to the Hibernate and now JPA notion of detachable objects. If a Wicket page has a customer objects as its model then before that page or model is serialised the customer object could be detached from the persistence manager.
detaching doesn't have anything to do with serialization.
It is just used to cleanup youre model when it is stored in the session. To keep it as light as possible
So if you have a Hibernate Object in youre model (lets say a User object)
then in the detach you only store the user_id in a none transient field, and set the user field to null)
then on attach you load the user again by its id.
This way you don't have large object in mem, when you are not in a request.
Ok, you can role back the model that was "versioned" with the page change. However, that would not undo any changes that were possibly made to the greater business model associated with the session.
Lookin at the example above.
Then when the id changegs (so now i am editting a different user) THAT is something that must be versioned.
But when you alter the users name and store that to the db. That doesn't have to be changed. Because that doesn't make sense.
This way if you edit first user X and then browser in the same page to user Y and then use the back button to edit user X.
Then the model must be reverted to X first before you submit the form with the data or X else use user Y is loaded and data of X (that comes from the browser)
is copied over Y.
I am starting to think that the more Web applications try to be like desktop application (Web 2.0 and all that) the less we will be able to handle the back button (or that it will even make sense). I don't think the back button can be equivalent to an "undo" type operation?
you can't disable the backbutton.
It is much to handy and users are really customed to it.
The strange thing is that we in a Swing application als introduced the backbutton there. To go to the previous screen.
It is just to handy.
So perhaps this versioning of the models won't be a key feature in the future (for certain types of Web applications - lets call them Web apps with heavy sessions). I am open to opposing views here?
see my previous example.. It could be a issue for anything where the backbutton comes into play.
Sorry if I am not getting this. I thought a model could be a simple String, or a more complex object (or small object graph) like Customer. I thought most components were associated with a model, i.e. the object(s) that they are representing in some way in their view.
A Model in wicket is just and IModel object that is more a locator of a object that it must display.
That can be a simple string yes.
But it can also first lookup a user by user_id and then get the username out of that user.
So when we are talking about models it is not the data itself but more a model object locator.
As above, personally speaking, I am not sure this is a high priority feature for Web 2.0 applications. But, of course, these are only one type of Web applications, and perhaps not a focus of Wicket.
Web2.0 is just a buzz/hype word made by managers.
It is just loads of Ajax and wicket can do that fine.
I just think there is a middle way. Use ajax where it is needed and handy, But don't do it all the way because it is ajax/web2 (like echo2)
johan
