It was done possibly to save performance hits (devs correct me if I am wrong).
You can read here ( http://blogs.atlassian.com/developer/2007/12/cachecontrol_nostore_considere.html) for some possible insight. Regards, Apple Grew my blog @ http://blog.applegrew.com/ On Thu, Apr 8, 2010 at 1:39 AM, Joseph Pachod <[email protected]>wrote: > Regarding the commented out no-store, any idea why the wicket core > developers didn't used it directly ? Having a consistent behavior across > browser + ajax and back button working seem rather good. I wonder why it > isn't included currently. > > joseph > > _____ > > From: Craig McIlwee [mailto:[email protected]] > > protected void setHeaders(WebResponse response) > { > response.setHeader("Pragma", "no-cache"); > response.setHeader("Cache-Control", "no-cache, max-age=0, > must-revalidate"); // no-store > } > > The "// no-store" is actually there. Overriding it with > > protected void setHeaders(WebResponse response) > { > response.setHeader("Pragma", "no-cache"); > response.setHeader("Cache-Control", "no-cache, max-age=0, > must-revalidate, no-store"); > } > > Will cause firefox to make a trip to the server when back button is > pressed. In my experience this is required for AJAX & the back button, > otherwise wicket won't know that the user hit back and will ignore AJAX > requests because they are being executed against a page that (as far as > wicket knows) is not the active page. > > Craig > > -----Original Message----- > From: James Carman [mailto:[email protected]] > Sent: Tuesday, April 06, 2010 8:56 AM > To: [email protected] > Subject: Re: What happens after browser's 'back' button? > > On Tue, Apr 6, 2010 at 8:07 AM, McIlwee, Craig > <[email protected]> wrote: > > As long as you prevent the browser from caching the page with the form > (just the page itself, caching the resources is fine) then when the user > hits back wicket will pull the old page instance from the pagemap and > rerender it. That page instance is the same one that was used the first > time, so its state will still be the same. Just set some flag when the user > submits, and also check that flag when processing the form like this: > > > > Not exactly. How would Wicket know to pull the "old" page instance if > the browser is re-requesting a bookmarkable URL? It wouldn't. It > would just reconstruct the page from scratch. In fact, Firefox > doesn't re-request anything from Wicket when you click the back button > (at least it doesn't in my app when IE does, go figure). The way > Wicket keeps everything in synch is that each URL in your rendered > page (for forms, links, etc.) has information on it that "points" to a > specific page in the page map (that's what all the ?wicket:interface > stuff is). So, when a form is submitted or a link (non-bookmarkable) > is clicked on your page, Wicket will load the specific page instance > from the page map and invoke the request on that. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > >
