On 7/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > the real client side wicket , so storing the data in the browser didn't make > it > and i don't think it will make it very soon because no current committer > really sees > the big benefit of this approach.
Yep. We played with it a while ago and we have a fair idea how to do it but we felt it wasn't worth the energy to keep working on it. There are disadvantages to client side state saving: * First of all you'd lose the secure-by-default model you have with Wicket. For instance, imagine having a detail panel for a product. If you pass around objects (or ids) on the server side, there is no way a client could get access to the details he/ she is not supposed to see. When passing state via the client, you would always have to check the incoming state for misuse. This is actually a pretty strong feature Wicket has over most other frameworks. The other side of this is that if you want to have your whole app bookmarkable, you'll have to do some extra work :) * Secondly, synchronously serializing, encoding and sending the state to the client eats processor time and bandwith. The size of the serialized, encoded state will be larger than than on the server. Even if we do something really smart, chances are we're sending *at least* 20KB to the client on each request. Maybe even more. We think using RAM is way more favorible. * Last but not least, GETs have to be made POSTs or you'd have to run the risk that state doesn't fit a request. Of course, there are advantages to client state saving as well: * No worries about RAM, at least not because of Wicket[1]. * Pages are recoverable by default. Even when a session times out, you could let the client pick up where he/ she left. * No need for session affinity[2] Conclussion: we don't support client side state saving currently, and we don't feel it's a priority at this time. However, if someone does feel it is important, we'd be more than happy to look at patches. I think the easiest way to achieve this is to implement it as a IResponseFilter and a custom session store. Eelco [1] worrying about using RAM is the typical knee-jerk reaction of people. Before worrying, calculate how many concurrent sessions you'll have to support, and how much RAM you'd need for that. [2] this increases your options when it comes to the way you cluster, though not using session affinity can have disadvantages as well (for instance when using ORM caches). ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
