Working with View State By default, almost all ASP.NET controls retain the values of their properties between form posts. For example, if you assign text to a Label control and submit the form, when the page is rendered again, the contents of the Label control are preserved.68892
The magic of view state is that it does not depend on any special server or browser properties. In particular, it does not depend on cookies, session variables, or application variables. View state is implemented with a hidden form field called VIEWSTATE that is automatically created in every Web Forms Page.
When used wisely, view state can have a dramatic and positive effect on the performance of your Web site. For example, if you display database data in a control that has view state enabled, you do not have to return to the database each time the page is posted back to the server. You can automatically preserve the data within the page's view state between form posts.
Displaying and Hiding Content
Imagine that you are creating a form with an optional section. For example, imagine that you are creating an online tax form, and you want to display or hide a section that contains questions that apply only to married tax filers.
Or, imagine that you want to add an additional help button to the tax form. You might want to hide or display detailed instructions for completing form questions depending on a user's preferences.
Finally, imagine that you want to break the tax form into multiple pages so that a person views only one part of the tax form at a time.
In the following sections, you learn about the properties that you can use to hide and display controls in a form. You learn how to use the Visible and Enabled properties with inpidual controls and groups of controls to hide and display page content.
Using the Visible and Enabled Properties
Every control, including both HTML and Web controls, has a Visible property that determines whether the control is rendered. When a control's Visible property has the value False, the control is not displayed on the page; the control is not processed for either pre-rendering or rendering.
Web controls (but not every HTML control) have an additional property named Enabled. When Enabled has the value False and you are using Internet Explorer version 4.0 or higher, the control appears ghosted and no longer functions. When used with other browsers, such as Netscape Navigator, the control might not appear ghosted, but it does not function.
Disabling View State
In certain circumstances, you might want to disable view state for an inpidual control or for an ASP.NET page as a whole. For example, you might have a control that contains a lot of data (imagine a RadioButtonList control with 1,000 options). You might not want to load the data into the hidden __VIEWSTATE form field if you are worried that the form data would significantly slow down the rendering of the page.
Using Rich Controls
In the following sections, you learn how to use three of the more feature-rich controls in the ASP.NET framework. You learn how to use the Calendar control to display interactive calendars, the AdRotator control to display rotating banner advertisements, and the HTMLInputFile control to accept file uploads.
Using Client-side Validation
Traditionally, Web developers have faced a tough choice when adding form validation logic to their pages. You can add form validation routines to your server-side code, or you can add the validation routines to your client-side code.
The advantage of writing validation logic in client-side code is that you can provide instant feedback to your users. For example, if a user neglects to enter a value in a required form field, you can instantly display an error message without requiring a roundtrip back to the server.
People really like client-side validation. It looks great and creates a better overall user experience. The problem, however, is that it does not work with all browsers. Not all browsers support JavaScript, and different versions of browsers support different versions of JavaScript, so client-side validation is never guaranteed to work.