ASP.NET ViewState postback with page refresh and bookmarks

Question

The ASP.NET ViewState feature can sometimes be a double edged sword. I rely on it on most of my projects and it speeds up development considerably.

My problem is that sometimes users will try to refresh a page which will cause the viewstate to be lost, other times the user might want to bookmark a page but when the get back the viewstate will be lost.

Modern browsers will display a silly dialog when a user tries to refresh a page that is the result of a POST operation (e.g. asp postback) which is not desirable at all.

I wonder is their a way to continue using ViewState and the postback model but without the drawback of the refresh dialog box. (and if possible bookmark the page.)

An example of what i might want to do is having a page with records and checkboxes next to them, the user has the option to check all the records they want to delete and then click on a delete button. After the user clicks delete the records are analyzed on the server and the new page lists all the records that were selected with a confirm delete button. Now if the user clicks refresh they get this silly box to confirm if they want to post or not.

I understant that ViewState is the result of using the Post Back model which means that most asp.net pages are the result of a POST operation, but i wonder if there are any ways around it.

Workarounds that i thought might work:
In the Page_Unload event save the viewstate in the session with a unique id and redirect the user to the same page with the unique id as a query string parameter, after the page loads with a unique id in the url the viewstate is loaded from the session and injected into the current page. Such a method will allow to user to refresh the page and always get back the same results.

P.S. I understand that i can use Response.Redirect() and/or query strings but i want to use the simplicity of ViewState

Answer 1

I'll give my opinions here one at a time.

The fact the dialogue warns you about a repeat post is a good thing IMO. What if it were a checkout page and resubmitting was going to somehow end up re-charging the user's credit card again. I agree the wording could be better on the dialogue but we are where we are.

If you think about bookmarking behaviour it implies that I will want to revisit that page time and again but its likely that my session will have ended well before that happens. So you could save the viewstate to a GUID but then you'll have to keep that viewstate in the database potentially forever. What if the page changes in the meantime? That viewstate will now be invalid.

Surely in your case you want a query string parameter that will load your user's data from the database and populate the page during page_load as normal? www.my-site.com/Customer.aspx?Id=90401 or something like that.

My suggestion is to not fight the tools. Hope this helps.

Answer 2

My 2 cents: Instead of using the simplicity of ViewState sandbag use the simplicity of Session - which really is the same simplicity and you won't have to bother worrying about page refresh and stuff. Moreover session is way more flexible since you can use it to store more than just built-in types without affecting performance (you can do it with ViewState as well but you will affect performance).

Answer 3

This might not be an elegant solution, but I think if you change the form method to GET it solves both your bookmarking problem and refresh one.

It's the same as using query strings, but with the abstraction of VIEWSTATE left untouched.