I guess you are right. But in an Ajax world, there really is no other way
around the problem, is there ?
Johan Compagner wrote:
>
> no i am against no-store as default.
>
> back button should be quick. If the line is a bit slow then users get very
> very very (i would) annoyed
> if the back button takes a while because it connects back to the server.
>
> A back button shouldnt do that. I know we in wicket wants it to do it but
> from an end user perspective it is a horrible experience.
>
> johan
>
>
> On Fri, May 16, 2008 at 11:01 AM, gumnaam23 <[EMAIL PROTECTED]> wrote:
>
>>
>> Adding "no-store" to the "Cache-Control" header did the trick.
>>
>> According to Page.setHeaders() javadoc , Wicket already adds cache
>> related
>> headers
>> response.setHeader("Pragma", "no-cache");
>> response.setHeader("Cache-Control", "no-cache, max-age=0,
>> must-revalidate")
>>
>> Is there any particular reason why "no-store" is not added to the
>> "Cache-Control" header ?
>> Or is this a bug and should be raised so ?
>>
>> Unfortunately even after "no-store" , I have problems.
>>
>> Here's my Page flow.
>> User Clicks on a Bookmarkable page (say /pages/Page1 ), Page1.class, has
>> a
>> BreadCrumbBar and a BreadCrumbPanel.
>>
>> The BreadCrumbPanel has an AjaxFallBackDefaultDataTable (AFDDT) . One of
>> the
>> Columns of the AFDDT
>> has BreadCrumbPanelLinks to navigate further down the hierarchy.
>>
>> The AFDDT is paginable, and fetches next/previous records over Ajax. So
>> when
>> a user fetches next records, the contents of AFDDT are fetched over AJAX.
>> As
>> I said previously, One of the Columns contain
>> BreadCrumbBarPanelLink , which when the user clicks takes him down the
>> BreadCrumb hierarchy.
>>
>> So far so good, but now if the user clicks the back button, the request
>> that
>> is sent to the server is for the bookmarkable page /pages/Page1, So the
>> Page1.class is reinstanciated, instead of it's correct version being
>> fetched
>> from the Session. So when the user hits back button, the Navigation of
>> the
>> AFDDT is lost, and we are back to the first set of rows in the AFDDT.
>>
>> If I use DefaultDataTable instead of AFDDT then this problem doesn't
>> arise,
>> because next/previous records are fetched as normal requests, and not
>> over
>> ajax.
>>
>> Is this a known limitation , or can something be done to solve this
>> problem
>> ?
>>
>>
>>
>>
>>
>>
>> Are you sure you also send the cache-control: no-store header?
>> (no-cache is not enough). Also for opera there's no way to force the
>> reload.
>>
>> -Matje
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Back-button-retrieving-cached-data-even-with-proper-headers.-tp17260832p17270411.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Back-button-retrieving-cached-data-even-with-proper-headers.-tp17260832p17273368.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
