Refreshing page properly on back button

[Harvey Schmidlapp]

I have a fairly complex form (generated by means of an ASP 3 page).
The form is used to define a query against a database. After running a
query, the user hits their browser's back button and goes back to the
form, where their selections show up. They can change whatever they
want to change and resubmit the new query. Mostly, everything works
fine, with radio buttons, selection lists, check boxes all coming back
in the state they were in before form submission.

Now, however, I have a problem. I'm working on adding a new selection
portion for the form. There are actually four different selection
lists that we want to make available to the user. The first, which is
the default when the form first loads, has about 400 items and loads
in a reasonable amount of time (i.e. a couple seconds). The second,
third, and fourth lists are considerably longer with the third being
the longest -- 15,000 or so entries which takes almost a minute to
load. Yes, I know, that's not ideal but this is what the client wants
so its what the client gets. Since the short, quickly loaded list is
the default, they only wait for the longer lists if and when they
choose them, it's not really too bad. So, they specify that they want
one of the longer lists and click a button to load that list. Instead
of rebuilding the whole page (as it did until now), I use an AJAX call
to refresh just that portion of the page. It works pretty well (if I
do say so myself).

Once the user has the list they want (whether the default, short list
or one of the longer ones), they can select one or more items in the
list and either click an arrow button or they can double click items
in the list. Either way, this moves the items from the list into an
initially empty list to the right of it. If that doesn't make sense,
it's something along the lines of this, although I wrote the code
before I found this one - http://www.codeproject.com/KB/webforms/DblPanePickList.aspx.

However many items are moved to the box on the right when the form is
submitted, they are all used in the query. That much is working great.
Now the problem. When you finish looking at the results of your query,
you click your browser's back button and return to the page where you
define the query. Everything that you selected is selected, as before,
with the exception of these two lists. The list on the right is empty
and the list on the left has nothing selected. I've been messing
around with every way I could think of to get it to repopulate them
correctly. The solution I finally came up with works beautifully in
Firefox but not at all in Internet Explorer (version 6, anyway, that's
all I've tested so far and it's what the client uses so if I fix it
there, I'm 95% done).

What I have done is on the results page, save the list of items
submitted to a session variable. When I go back, I read that session
variable and use the list to populate the selection boxes properly. In
Firefox, this works. In IE, it always loads the correct list but never
sees that the session variable has been changed. If I manually refresh
the page, of course, it loads correctly that time. If I change the
items select, I submit the query, wait for it, go back to the
definition page and once again, it doesn't remember the new values. I
assume this has to do with IE loading that page completely from cache
no matter what I ask it to do. Actually, Firefox did this at first.
Then I had the code that the AJAX calls get the session variable and
pass it back in the XML. That fixed it in Firefox but IE doesn't even
seem to request that code.

I'm not sure if I've explained the problem very well so please ask
questions. I wish I could give you a link to the site but I can't (as
the client would have a cow). If necessary, I could probably produce a
much abbreviated version that just has enough to demonstrate the
problem but it would take a good bit of time so would rather not if I
don't have to.

I'm open to any suggestions. Actually, I'm considering going back to
the drawing board and eliminating the AJAX portion of the code and
rebuild the entire page each time the user changes the list because of
this. I'd rather not, but then, I need it to work. Not that I'm even
sure it would work then. Thanks for any help you can provide.

 

[David Mark]

I have a fairly complex form (generated by means of an ASP 3 page).
The form is used to define a query against a database. After running a
query, the user hits their browser's back button and goes back to the

There's your problem. The back button can't be the only means of
navigation.

form, where their selections show up. They can change whatever they
want to change and resubmit the new query. Mostly, everything works
fine, with radio buttons, selection lists, check boxes all coming back
in the state they were in before form submission.

Yes, the browser remembered the state of the form from the previous
visit.

Now, however, I have a problem. I'm working on adding a new selection
portion for the form. There are actually four different selection
lists that we want to make available to the user. The first, which is
the default when the form first loads, has about 400 items and loads
in a reasonable amount of time (i.e. a couple seconds). The second,
third, and fourth lists are considerably longer with the third being
the longest -- 15,000 or so entries which takes almost a minute to
load. Yes, I know, that's not ideal but this is what the client wants
so its what the client gets. Since the short, quickly loaded list is
the default, they only wait for the longer lists if and when they
choose them, it's not really too bad. So, they specify that they want
one of the longer lists and click a button to load that list. Instead
of rebuilding the whole page (as it did until now), I use an AJAX call
to refresh just that portion of the page. It works pretty well (if I
do say so myself).

Once the user has the list they want (whether the default, short list
or one of the longer ones), they can select one or more items in the
list and either click an arrow button or they can double click items
in the list. Either way, this moves the items from the list into an
initially empty list to the right of it. If that doesn't make sense,
it's something along the lines of this, although I wrote the code
before I found this one -http://www.codeproject.com/KB/webforms/DblPanePickList.aspx.

Be very wary of .NET components.

However many items are moved to the box on the right when the form is
submitted, they are all used in the query. That much is working great.
Now the problem. When you finish looking at the results of your query,
you click your browser's back button and return to the page where you
define the query. Everything that you selected is selected, as before,
with the exception of these two lists. The list on the right is empty
and the list on the left has nothing selected. I've been messing
around with every way I could think of to get it to repopulate them

You will have to deal with this in the load event.

correctly. The solution I finally came up with works beautifully in
Firefox but not at all in Internet Explorer (version 6, anyway, that's
all I've tested so far and it's what the client uses so if I fix it
there, I'm 95% done).

What I have done is on the results page, save the list of items
submitted to a session variable. When I go back, I read that session

The server doesn't enter into it. The user clicks back, the browser
restores the input states, you restore the form data as appropriate
(e.g. populate the appropriate selects based on these states.)

And I assume you have some unload listeners. If you get rid of those,
you may find that the problem magically goes away (in browsers that
preserve the DOM during history navigation.)

 

[Harvey Schmidlapp]

There's your problem.  The back button can't be the only means of
navigation.

Yes, after posting this, I began thinking about adding a "Return to
Query Definition" button of some sort that would actively reload that
page with parameters that I can control. It seems quite likely that's
where I'll end up but it's not trivial.

Be very wary of .NET components.

There is no .NET in my system. The site I linked to was to illustrate
the idea but I'm not using that code.

The server doesn't enter into it.  The user clicks back, the browser
restores the input states, you restore the form data as appropriate
(e.g. populate the appropriate selects based on these states.)

And I assume you have some unload listeners.  If you get rid of those,
you may find that the problem magically goes away (in browsers that
preserve the DOM during history navigation.)

When the reload happens when you hit the back button, the page
reloads. At the end of its loading, an onLoad event fires which, among
other things, shoots off an AJAX call which rebuilds the proper list
including selecting those items that had already been selected. As I
mentioned, this is what happens in Firefox. IE seems to fire the
Javascript (i.e. when I stick an alert() or two in there, they show
up) but it doesn't talk to the server, it reuses the XML from the
previous run of the AJAX code.

Anyway, if I understand you correctly, you have confirmed my
impression that I'm not going to get this to work. Since I needed to
implement code to load the form with arbitrary options pre-selected,
now's probably the time to do that. Then I can create my "go back to
the form" button and have it come up with the items selected that had
been selected previously.

Thanks for your time.

 

[David Mark]

Yes, after posting this, I began thinking about adding a "Return to
Query Definition" button of some sort that would actively reload that
page with parameters that I can control. It seems quite likely that's
where I'll end up but it's not trivial.



There is no .NET in my system. The site I linked to was to illustrate
the idea but I'm not using that code.




When the reload happens when you hit the back button, the page
reloads. At the end of its loading, an onLoad event fires which, among
other things, shoots off an AJAX call which rebuilds the proper list
including selecting those items that had already been selected. As I
mentioned, this is what happens in Firefox. IE seems to fire the
Javascript (i.e. when I stick an alert() or two in there, they show
up) but it doesn't talk to the server, it reuses the XML from the
previous run of the AJAX code.

Because it is cached.

Anyway, if I understand you correctly, you have confirmed my

You don't.

impression that I'm not going to get this to work. Since I needed to

You can if you just add the appropriate headers to your request to
prevent caching.

 

[Harvey Schmidlapp]

Anyway, if I understand you correctly, you have confirmed my

You don't.


You can if you just add the appropriate headers to your request to
prevent caching.

You're quite right, I did misunderstand you. When I turned off
caching, it started to forget ALL the settings on the form, which of
course was not what you meant, either. I believe I've finally caught
on. When I leave caching on for the main form page BUT turn caching
off for the page called by the AJAX process, it appears to work the
way I want, recalling all settings on the page except looking to the
server for this one section that gets refreshed with the value(s) from
the session variable. I'll need to do some further testing but so far
it looks good. Once again, thanks.

 

[David Mark]

You're quite right, I did misunderstand you. When I turned off
caching, it started to forget ALL the settings on the form, which of
Yes.

course was not what you meant, either. I believe I've finally caught
Right.

on. When I leave caching on for the main form page BUT turn caching
off for the page called by the AJAX process, it appears to work the
way I want, recalling all settings on the page except looking to the
server for this one section that gets refreshed with the value(s) from
the session variable. I'll need to do some further testing but so far

Refreshed with the values from the session variable? I don't
understand where a cookie enters into it. You update the select's
based on the state of other inputs on the form.

it looks good. Once again, thanks.

No problem. Make sure it works without cookies though.

 

[sasuke]

You're quite right, I did misunderstand you. When I turned off
caching, it started to forget ALL the settings on the form

Read the appropriate section in the FAQ regarding this; it might just
help you out if you are unwilling to disable caching altogether. <URL:
http://www.jibbering.com/faq/#ajaxCache>

/sasuke

 

[Harvey Schmidlapp]

Refreshed with the values from the session variable?  I don't
understand where a cookie enters into it.  You update the select's
based on the state of other inputs on the form.

Because of the way this portion of the form is generated, simply not
caching that page isn't enough. I need to know what was selected when
the form was submitted so I can set it up with those items selected
when it is reloaded. Therefore, when the form is submitted I record
what was selected in this portion and store it in a session variable.
When I re-run the code that generates this section (when the user goes
back to the form from the results page) I get the value from the
session variable, highlight the selected items in the left-hand list,
and populate the right-hand list with those same items. The
determination of which list goes in the left-hand box is based on
other inputs on the form but determining which items in that list are
selected is done by reading the session variable.

No problem.  Make sure it works without cookies though.

When this application was first written (by someone else about six
years ago, working for a subcontractor) it was decided that both
Javascript and cookies would be required for the application to work.
The universe of users is quite small and all seem to be willing to
allow both. Since there are enough other uses of session cookies in
the system, I'm not particularly worried about adding another
dependency at this point.

 

[Mike Duffy]

... I'm not particularly worried about adding another dependency

If you are interested, I have two functions that save and restore all form
values in a big cookie. Use with:

<body onunload="saveSelections(document.forms[0])">

in order to save all form values when the user navigates away. Then, at the
end of the form use:

<script type="text/javascript">loadSelections(document.forms[0]);</script>

Right now, they only do one form, but the functions could easily be
extended to work with any number of forms. The code is not very robust if
the form structure has been changed, but you can use it as a starting
point. I will post it if anyone wants.

 

[David Mark]

Because of the way this portion of the form is generated, simply not
caching that page isn't enough. I need to know what was selected when
the form was submitted so I can set it up with those items selected
when it is reloaded. Therefore, when the form is submitted I record
what was selected in this portion and store it in a session variable.
When I re-run the code that generates this section (when the user goes
back to the form from the results page) I get the value from the
session variable, highlight the selected items in the left-hand list,
and populate the right-hand list with those same items. The
determination of which list goes in the left-hand box is based on
other inputs on the form but determining which items in that list are
selected is done by reading the session variable.

Unless the session times out of course.

When this application was first written (by someone else about six
years ago, working for a subcontractor) it was decided that both
Javascript and cookies would be required for the application to work.

Cookies I can see (especially if you are already using session
variables.) Requiring JS to fill out a series of forms is just silly.