Such a strategy would be possible, but one downside of it is that that only works with submits. We have some testing code for client side state saving (serialized page written to a hidden field). We haven't put a lot of effort in it to complete it - though the basic idea works - as it is not something any of the current committers really believe in. However, if you want to see how a strategy like you proposed could be done, you could check that out (it's in 2.0, ClientPageSavingSessionStore).
Of course, any contributions in the form of patches are always welcome and might serve as a good starting point for further discussion :) Eelco On 10/20/06, Upayavira <[EMAIL PROTECTED]> wrote: > Eelco Hillenius wrote: > > On 10/20/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > >> all bookmarkable pages can have forms.. > >> that is already possible at the moment we had bookmarkable pages (like > >> wicket 0.x) > >> > >> Again you mixup the notion of Bookmarkable and Stateless > >> Those are NOT the same, especially bookmarkable in regards to stateless. > >> the other way around, Stateless pages are most likely bookmarkable. > > > > No, I don't think so. Are you telling me those forms are populated > > automatically from a 'bookmarkable' url? I think not, and thus you > > have to interpret/ repopulate the form yourself. Now bookmarkable > > forms in the way they are in 2.0 now can be used just as normal form > > with the only difference from an end-user's perspective that you can't > > depend on instance variables. > > Just a thought coming from Cocoon-land. > > Cocoon has the concept of continuations in server-side java script, and > this can be used to maintain state. > > Although the programming model is different, the need is the same - when > you connect to the backend server, to identify yourself in some way so > that you can be reconnected with your particular state. The session > itself is too general - you need something particular to your form/etc. > > Cocoon handles this with a continuation ID. Using Cocoon's sitemap, you > can configure it to get that ID either from within the URL, or from a > request parameter (or anywhere else you might care to think of). > > I always tended to put the continuation ID into a hidden field on the > page, as I wanted to maintain pretty URLs (even if those URLs weren't > 'RESTful' - i.e if you bookmark it you won't go back to that particular > state). > > Is it possible in Wicket to use a hidden field to pass that state > information rather than tacking it onto the URL? > > Regards, Upayavira > > ------------------------------------------------------------------------- > 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 > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------------------------- 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 Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
