Client-Based Technique #1: ViewState
|One issue you likely encounter using Web Form control values is that many browsers do not support blanks in a query string.|
I will start with the simplest client-based state management technique to help the server "remember" things about a returning Web page, ViewState. ViewState
is built-in into Web Forms pages and automatically retains control values between multiple requests for the same page.
is implemented through a hidden form field control called __VIEWSTATE
. When a Web page is about to be submitted back to the server it takes a look at the state (value) in each control and writes the name of the control and its state into the __VIEWSTATE
control. If you look at the source of an .aspx page and examine the __VIEWSTATE
control, it will look something like this.
<input type="hidden" name="__VIEWSTATE"
While this mess isn't easily decipherable to us (yes, it is decipherable), fortunately for us, the ASP.NET parser knows how to extract all of the controls, names, and values from this mess and .NET knows how to use the information from the parser to repopulate the controls.
Flipping ViewState On and Off
You may have guessed that parsing the ViewState information can involve some serious processing on the server for a well-populated page. Since ViewState isn't a priority for every page you build you can turn it off when you don't need to use it. Doing so will reduce the demand on server resources and increase the speed of your application.
There are two ways to enable or disable ViewState functionality: at the page level or for individual controls. To disable it at the page level set the enableViewState
attribute to False
in the Page directive at the top of the page.
<%@ Page enableViewState="False"%>
Similarly, set the EnableViewState
property to False
to disable ViewState on a specific control (see Figure 1
Hitching a Ride on ViewState
|Figure 1. TextBox Control Property Sheet: You can find the enableSessionState property for a control on the control's property sheet.|
There may be times when you will want to send other information to the server along with the current page so that same information package returns when the page completes its round trip. The ViewState()
function accepts the name of the value to store as a parameter and then the value to save is assigned.
For example, suppose I want to track how many times the current page has been submitted by the current user. The Page_Load
method code would look like this.
If Not Page.IsPostBack Then
ViewState("PageCount") = 1
ViewState("PageCount") = _
CInt(ViewState("PageCount")) + 1
Me.lblPageCount.Text = _
You can create as many ViewState name/value pairs as you like.
Advantages of Using ViewState
Besides just being built in, ViewState provides some other advantages.
Disadvantages of Using ViewState
- It is easy to implement.
- It retains page and control state for you automatically.
- It does not use server resources since all of the state information is contained within the page itself.
Because ViewState information is stored in the page code itself, the potential for ViewState bloat exists for heavily populated pages or pages containing DataGrids.
- Performance problems with ViewState can cause a page to display slowly and cause a delay when it is posted back.
- Page security can be a problem when using ViewState since the ViewState data is available in the page source and, even though it is encrypted, it can still be tampered with.