Client wants ALWAYS functional "back" button 1

[XgrinderX]

Hello!

I have a rather large ASP application written for a client with all kids of variables being passed about to different pages in various frames etc.

My client wants to have a back button on the page that will cycle all the way through the browsing history. The problem is, many of the pages were created using form data and you get that little warning page telling you that you need to refresh. Client does not want that.

Is there some fundamental thing I am doing wrong that if I corrected it then the back button would always work? Or is this just the nature of the beast? Has anyone had any luck with some sort of table that tracks pages and form data which could be used by a back button function to generate history pages?

I have tried several times to get the client to ditch the back button idea altogether, noting that 95% of anything you need to get "back" to can be done by clicking the appropriate button within the interface. But so far I am losing the battle.

Any and all help/comments are appreciated.

-Greg

 

[ChrisHirst]

That's the nature of the beast

You will have to store the page history in a cookie or something and create a UI button.

or use javascript:history.go(-1)

BUT be prepared for the possibility of duplicate form entries and erroneous information as some values may not exist as the page opens.

Chris.

Indifference will be the downfall of mankind, but who cares?
Woo Hoo! the cobblers kids get new shoes.
People Counting Systems

So long, and thanks for all the fish.

 

[Tarwn]

Actually I wouldn't think the back button would cause the popup to fire, since usually when your using the back button it does not refresh the page, just shows you the cached one. The only time it should go back to the server for a fresh copy is if you force the page to refresh, the page is set with an expiration, or the cache for the browser is full.
I would check to make sure you haven't set an expiration for the page and clear your browser cache and see if it still displays the popup when pressing the back button.

The next step would be to find out which pages push data to the database/wherever that absolutely should not resubmit data. For the pages that handle the submission for those selected forms build in some code to detect a duplicate submission to ensure you won't break anything.
Examples of duplicate posts that would hurt: registration forms
Example that don't hurt: setting user preferences (should be an update on an existing record, two updates won't hurt)

-T

 

[XgrinderX]

Ok some clarification.

1) We do expire pages immediately because almost every page has info on it that could be updated at any time and we want the latest info to alway show. We use the following at the top of almost every page:

Response.ExpiresAbsolute = Now() - 1
Response.AddHeader "cache-control", "private"
Response.AddHeader "pragma", "no-cache"

2) I am not too worried about duplicate form entries. I can handle that fairly easily. What is happening most of the time is a situation where I have a single page that can show several options of data - e.g. a message folder page that can show and inbox, sent items, and archived items folder. The page is changed using an onchange event from a dropdown. If the go from inbox to sent items to archive and then hit the back button, they get the "must refresh" message.

Thanks for your prompt replies....keep em coming if you have any other ideas/suggestions.

-Greg

 

[cLFlaVA]

Greg,

we have employed a very similar concept with an ASP application here. We store the current page's URL in a growing array (we append it to the end), if it is not already the last array item.

We have a "Close" button on the bottom-right of every screen. The purpose of this button is to bring the client to the previous different page - because many times they're changing things and reloading the same page - and hitting the browser's back button just brings them to a different view of the same page.

The "Close" button finds the previous URL entry (ubound - 1) and redirects them there.

We store the array in a session variable.

Hope this helps.



*cLFlaVA
----------------------------
[tt]"quote goes here"[/tt]
[URL unfurl="true"]http://www.coryarthus.com/[/url]

 

[XgrinderX]

That does help a little. Our problem would be that we'd have to pass form data to many of the pages to make it work properly. Using my message folder example from above:

The URL is always messageFolder.asp and we pass a folder ID to the page using a POST form to tell it which folder to display. I suppose we could go change a lot of these to use the GET method and then we can store the whole URL and QS in the array. Maybe that is the route I need to go.

 

[cLFlaVA]

sounds like that might be a solid option.



*cLFlaVA
----------------------------
[tt]"quote goes here"[/tt]
[URL unfurl="true"]http://www.coryarthus.com/[/url]

 

[Sheco]

One situation I've seen the "resubmit" warning is when clicking <-BACK to an ASP in the browser history and that ASP uses [tt]Server.Transfer[/tt] to move submitted form values to a subsequent page. The browser goes "back" but is immediately sent forward. This can really make the user upset if they are accustomed to using the <-BACK button.