Thanks for the tip! I'll make sure I set that up in my base page.
On Tue, Apr 6, 2010 at 3:53 PM, Craig McIlwee
<craig.mcil...@openroadsconsulting.com> wrote:
> 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:jcar...@carmanconsulting.com]
> Sent: Tuesday, April 06, 2010 8:56 AM
> To: users@wicket.apache.org
> Subject: Re: What happens after browser's 'back' button?
>
> On Tue, Apr 6, 2010 at 8:07 AM, McIlwee, Craig
> <craig.mcil...@openroadsconsulting.com> 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: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
