You're right James, I failed to mention that my approach will not work for
stateless pages. A stateful URL is needed to identify the previous page
instance. Regarding Firefox's lack of server trip on back button, this is what
I was getting at with the cache header stuff I mentioned. The WebPage class's
setHeaders method (in v1.4.1) looks like
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]
