On 10/21/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > no that is only done half way it is not really usable, just a test case how > it could be done.. > When we don't finish it (i don't think i will do that) then it should be > removed before the final of 2.0
Yeah, we should remove it then. Looking at it, we would need a different strategy for that anyway. It would be more like: 1) This session store should get the session like eg. HttpSessionStore. I think trying to encode the whole session would be just too much (and we're not actually even doing that here). ClientPageSavingSessionStore now presumes that the last request was encoded by Wicket, but that is a problem for things like shared resources and bookmarkable pages. The thing we want encoded is the state of the last request if that is relevant for call backs (in effect the rendered page). 2) StateWriter is something we would need, but it would need to be extended to converting all links to use a submit too. For this we would probably need to have a javascript function that dynamically builds a form or post. Links etc would be converted to use this. 2a) I learned recently that 255 is not an actual limit for gets, but merely a very outdated 'recommeded' length. For internet explorer this maximum is 2,048 (http://support.microsoft.com/kb/208427) and I read other browsers even exceed that. I haven't measured it, but wouldn't that be enough for one serialized page to hold? A thing to consider is not to worry about posts in the first place (you could argue this is a trade off users have to consider themselves), but put this encoded state in the links we return in urlFor. We could do that, as the complete hierarchy is known in 2.0. Additionally, with that method, there could be a nice optimization, where we ask the component itself for it's 'contribution' to the encoded state (don't aks me how that would work right now, it's just a wild thought). Of course, there would be the overhead that every link on the page would have that full state initially, but that would be something we could optimize later as well. 3) The session store should only intercept the getAttribute requests for the page map. On that request, it should return an on-the-fly pagemap, with the one page reconstructed from the session state that was sent with the request. That pagemap could be lazily constructed and reused throughout the request, and onEndRequest it would be cleared again. These are just a bunch of wild thoughts. I'm convinced that if we wanted and 2a would be viable, we wouldn't be that far off to working client side state saving. The nice urls 'problem' that this thread started with is still something else, and I agree with Johan and Matej that there are a number of problems with it (most notably mounting and redirect to buffer not working), and thinking about it a bit more, even though we probably could achieve something like this if we really tried hard, it wouldn't be for any advantage other then that the urls would like 'nicer'. The thing that I proposed in a thread two weeks ago: components contributing 'state' to urls would at least have the advantage of bringing totally tweakable stateless pages a step closer. This case doesn't have that advantage. And concerning client side state saving, I'm still unconvinced that this is better to have than just server state saving. On the contrary. The only thing interesting about it is the technical challenge and the additional choice it would provide our users. Eelco ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
