So basically i meant setting "no-store" in your response header so that the browser doesnt load the page from its local-cache, and instead sends the request to the server and let wicket load the last serialized page.
Farhan. Eelco Hillenius wrote: > >> I understand that the browser back button doesnt really come in the above >> context, but you agree to the fact that one has to do a no-store to >> actually >> LET wicket load the page from the SLC otherwise this back button support >> by >> wicket (which is considered to be one of the main features of it) >> wouldn't >> really come into play? > > I don't understand what you mean here tbh. Wicket's default > configuration handles the back button, and pages are loaded from > DiskPageStore. If you use a 'no-store' (you mean an empty > implementation of IPageStore with that, right?), you wouldn't have > back button support as Wicket wouldn't be able to find any other page > than the current one. You have to understand that SLCSS comes in two > parts: the session store itself, which uses the HttpSession to store > the current page (which is why it would be clustered if you'd use > normal session clustering) and the page store, which exists to store > older page versions. > > 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#a13815263 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
