> 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]
