hmmm..so correct me if its not the right understanding..i.e. the only time wicket would be fetching the older page versions is when a user hit the back button and clicks on a link (or submit a form) from that previous page, and with that whatever page-version those links/forms were linked to (which would be the original rendered page) wicket would load that page.
That means one (ideally) wouldn't code anything himself to refer to the old page versions lets say in the page to be rendered next, thats why i sort of was into thinking as to why would i refer to an older version, so its only the back button where this whole idea of version-ing comes in. Farhan. Eelco Hillenius wrote: > >> Well i think it is required, at least as far as the browser back button >> is >> concerned (which is one of the features of wicket i.e. "back button >> support"), unless otherwise as you said where one explicitly wants to >> make a >> call to the old versions > > You don't need to do roundtrips right away. It would only generate > load for nothing. The resurrection of old pages can be delayed until > you actually do something with it. > >>, but even with that i wonder how would one go about >> maintaining the references to these older page versions (so as to access >> it >> at later pages)? > > That's the responsibility of the session store. The number of saved > pages is sufficiently large for normal use, and as it is configurable, > you can go as wild as you like. > >> and lets just say even we do explicitly maintain them >> somewhere (e.g. in the session itself OR pass it from the previous >> pages), i >> think one wouldnt come to the need of referring the older versions of >> their >> components from within their application (except for the last couple of >> pages). > > Page versions are stored transparently. It is not something you should > concerned about as a framework user. If a request comes in that can't > be resolved to the current page, Wicket will ask the page store to get > the older version. These older versions were stored using > serialization, so you just roll back to an older snapshot of the > component state. > > Eelco > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Second-Level-Cache-tf4824369.html#a13816327 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
