What really to do about Viewstate
I am about 5 days into my first non-trivial ASP.NET application, and I am running into the dreaded "huge gnarly viewstate string problem".
I've read around and thus far it would appear that I must either choose between:
* The great timesaving form state preservation features of ASP.NET
* Using IE only
* Breaking the form into smaller forms (not really an option)
When I turn off Viewstate all my array-bound dropdown menus lose their values after a form submission.
With viewstate off everything works lovely in IE, but this is a dealbreaker as I am deploying this for techies in Japan who hate IE with a passion.
Help! I can't believe this is really how it's supposed to work!
Thursday, April 8, 2004
You can override LoadPageStateFromPersistenceMedium and SavePageStateToPersistenceMedium if you wish to stash the ViewState somewhere else besides that hidden field in the form.
One reasonable approach is to stash the view state data into the cache, and store the key to the view state in a hidden field instead. Then, when reconstructing the view state from the post, you can retrieve the view state from the cache and delete it. If the user doesn't post back, then the cache will eventually time the view state out so it doesn't stick around indefinitely.
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 8, 2004
You can be more selective about ViewState. Rather than turn it completely off (either as @page or web.config level) you can enable/disable on a control by control basis. DataGrids tend to be a big consumer of ViewState. In fact why not turn the trace on for the page in question - and it will tell you exactly which controls are hogging the majority of the space. Then you can focus of removing their reliance on ViewState.
Tuesday, April 13, 2004
Fairly old post, and maybe you're well past solving this, but my two cents anyway:
I've taken to clearing the ViewState (by simply Response.Redirecting to the same page) whenever possible. "Whenever possible" essentially means any time the changes have been committed, to the database (or wherever). Your page then re-loads fresh, with a clean ViewState.
If there are actions a user can take on a page that commits changes (e.g. does an Insert/Update/Delete) but then displays the same page again, this works really well with minimal effort.
Sunday, April 18, 2004
Fog Creek Home