Avoid page re-instantiation upon browser back button pushing.

[Fabio Fioretti <wi...@gmail.com>]

Hi all,

I'm dealing with a problem related to unwanted re-instantiation of a
page which is firstly called parametrized with something like:
/mypage?user=ME.

This page contains a ListView displaying some tasks for the specific
user and a DropDownChoice to filter these tasks following some
criteria.

When I click on a ListItem, a page containing details for the single
task is opened.

I want the chosen filter of the DropDownChoice to be remembered if I
go back with the browser back button.

To be clearer, as it's difficult to explain the problem in a few
words, here are the steps I follow to reproduce it:

1) I load my main page with url /mypage?user=ME: it loads showing its
ListView and related filter (set to default);
2) I choose a filter option and the ListView is updaded;
3) I click on a ListItem and the relative details page is opened;
4) then I push the back button of the browser and go back to the page:
the DropDownChoice component forgot the chosen filter selection.

This is because, when I push the back button, /mypage?user=ME url is
loaded, the constructor gets called and a new page is instantiated
instead of displaying the old instance (I presume). Is there a way to
avoid this page re-instantiation?

I noticed that if the page is firstly instantiated following different
paths and gets loaded with something like (for example)
/?wicket:interface=:4:2: (and not /mypage?user=ME), I can push the
back button and be sure that the filter option will be remembered
correctly (because the page is NOT costructed again).


Sorry for being wordy and thanks in advance,

Fabio Fioretti - WindoM

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Avoid page re-instantiation upon browser back button pushing.

[Fabio Fioretti <wi...@gmail.com>]

On 8/1/07, Matej Knopp <ma...@gmail.com> wrote:
> By default wicket doesn't send the no-store Cache header, so the page
> should be pulled from cache on back button. It's weird that the page
> is reloaded.

It really is, as it seems that every bookmarkable page isn't pulled
from cache over here...

> Anyway, new instance is created because there is a bookmarkable url.
> To creating new instances

I think you meant "to avoid the creation of new instances", didn't you?

> you'll have to either make the url
> non-bookmarkable (with the wicket:interface part), or you can mount
> the page using HybridUrlCodingStrategy (such as the ajax exampels
> are). To use this strategy you need the most recent wicket from trunk.

Ok, thanks a lot and thanks to all of you for your precious answers.


Kindest regards,

Fabio Fioretti - WindoM

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Avoid page re-instantiation upon browser back button pushing.

[Matej Knopp <ma...@gmail.com>]

By default wicket doesn't send the no-store Cache header, so the page
should be pulled from cache on back button. It's weird that the page
is reloaded.

Anyway, new instance is created because there is a bookmarkable url.
To creating new instances you'll have to either make the url
non-bookmarkable (with the wicket:interface part), or you can mount
the page using HybridUrlCodingStrategy (such as the ajax exampels
are). To use this strategy you need the most recent wicket from trunk.

-Matej

On 8/1/07, Paolo Di Tommaso <pa...@gmail.com> wrote:
> Ummh .. quite interesting.
>
> I was supposing that Wicket disable browser caching by default, for
> Bookmarkable page also. Isn't it Igor?
>
> Or is there any special API to enable/disable page caching on client side?
>
> Paolo
>
>
> On 8/1/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > On 8/1/07, Fabio Fioretti <wi...@gmail.com> wrote:
> > >
> > >
> > > This is because, when I push the back button, /mypage?user=ME url is
> > > loaded, the constructor gets called and a new page is instantiated
> > > instead of displaying the old instance (I presume). Is there a way to
> > > avoid this page re-instantiation?
> >
> >
> > why is that url loaded again on backbutton? it should come from browser
> > cache, do you add a no-store header or something?
> >
> > also see HybridUrlCodingStrategy, that might help
> >
> > -igor
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Avoid page re-instantiation upon browser back button pushing.

[Paolo Di Tommaso <pa...@gmail.com>]

Ummh .. quite interesting.

I was supposing that Wicket disable browser caching by default, for
Bookmarkable page also. Isn't it Igor?

Or is there any special API to enable/disable page caching on client side?

Paolo


On 8/1/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> On 8/1/07, Fabio Fioretti <wi...@gmail.com> wrote:
> >
> >
> > This is because, when I push the back button, /mypage?user=ME url is
> > loaded, the constructor gets called and a new page is instantiated
> > instead of displaying the old instance (I presume). Is there a way to
> > avoid this page re-instantiation?
>
>
> why is that url loaded again on backbutton? it should come from browser
> cache, do you add a no-store header or something?
>
> also see HybridUrlCodingStrategy, that might help
>
> -igor
>

Re: Avoid page re-instantiation upon browser back button pushing.

[Igor Vaynberg <ig...@gmail.com>]

On 8/1/07, Fabio Fioretti <wi...@gmail.com> wrote:
>
>
> This is because, when I push the back button, /mypage?user=ME url is
> loaded, the constructor gets called and a new page is instantiated
> instead of displaying the old instance (I presume). Is there a way to
> avoid this page re-instantiation?


why is that url loaded again on backbutton? it should come from browser
cache, do you add a no-store header or something?

also see HybridUrlCodingStrategy, that might help

-igor