hi friends

Question

where is the view state stored and can we get the view state value

prathi Atluri · Answer

View state is simply text. It is an aggregate of values of controls on a page. It's a string that contains values of page controls hashed and encoded in some manner. The view state contains no information about the server or the client. It only comprises information about the page itself and its controls. It lives along with the page in the user's browser. As a rule, view state is stored right in the page and therefore it travels with it back and forth. Remember good old hidden input fields? View state is nothing more than a hidden input which holds a hash of control values. If you view the source of an ASP.NET web form you will see something like this: "hidden" name= "__VIEWSTATE" value="CEbzzzEnmmz+Bc8IDFlnpgCLJ/HB00...> Nobody in sane mind can read these strings fluently. What you see here is a base64 encoded string. I emphasize encoded because some folks assume view state is encrypted. Base64 is not an encryption algorithm. Base64 makes a string suitable for HTTP transfer plus it makes it a little hard to read. Just a little. It's easy to decode this string and see what's inside. Can this be a security issue? It sure can. We'll address your concern in due time. Stick around. Every server control ultimately derives from the Control class. Be it a WebControl , HtmlControl or even LiteralControl it has a property called EnableViewState . When a page is built every control that has this property enabled contributes to the view state by serializing its contents (in this case: converting its contents into a string). Now, some controls are easy to serialize, while others might give us grief. What manages the view state is the title="StateBag class manages the view state of ASP.NET server controls, including pages." href=" StateBag'> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebuistatebagmemberstopic.asp">StateBag class . This class is like a dictionary—you may store key/value pairs in it. This is how you store a piece of useful data in the view state: ViewState ["SortOrder"] = "email" When the page posts back its view state is taken apart (decoded) on the server and each control participating in the view state gets its value restored. There's an interesting gotcha you need to be aware of. Some controls get their values restored automatically (courtesy of ASP.NET) and you don't need to maintain their values! I put together two almost identical pages—one is an title="Sample web form which maintains its view state automatically" href=" " web form , and the other one is title="HTML web page which does not maintain its view state" href=" " HTML . The ASP.NET page has its view state turned off completely. See how it maintains text and selections once you click Submit. Scroll down to "Form Collection" to see what was posted. ASP.NET restored these values automatically! src="" > The second page is old, "traditional", HTML. Click Submit to receive proof that control values won't be restored. What's the moral of this story? You don't always need view state enabled to maintain page state. "When do I need it though? What's it for then?" Glad you asked. The prime candidates for participation in view state are those controls that don't post back with the HTTP form and controls added or populated dynamically. Let me give you an example. Suppose you have an empty dropdown list which you populate with user names from the database. When the page runs for the first time ( !Page.IsPostback . Rings a bell?) you need to databind it and fill it with user names. What happens once the page loads? Without view state the dropdown list will be empty. As you enable view state the dropdown list content will be restored on postback. Or... you would have to populate the list from the database every time the page posts back! If you weigh database access vs. view state the scale tips in favor of view state (unless the list of users is so huge that you'd rather ping the database each time instead of dragging around a giant view state string). What Exactly Can I Store in View State? Documentation states the view state is "optimized" for a small number of types. The lucky ones are strings, integers, booleans, ArrayLists and HashTables. Everything else should either be serializable or have a TypeConverter defined for it. Beware of performance drawbacks for complex types. Serializing and deserializing a complex object could incur too much overhead. Choose wisely! Consider storing such an object in Session or Cache instead. Remember—whatever you store in the view state travels back and forth wasting bandwidth and making page downloads slower. Session State View State Holds server resources? Yes No Times out? Yes – after 20 minutes (default) No Stores any .NET type? Yes No, limited support for: strings, integers, Booleans, arrays, ArrayList, hashtable, custom TypeConverters Increases "HTML payload"? No Yes As you see some objects are a perfect fit for view state, while others had better be stored in the session. If you still need to store an object in the view state think about creating a TypeConverter for it to improve performance. How Do I Enable View State? You may do so on the machine, application, page and control level. First, you must have a server side form ( ). By default view state is enabled (as of ASP.NET 1.1). A quick peek into machine.config reveals this much: enableViewState="true" enableViewStateMac="true" ... /> The nature of machine.config prescribes general settings for all applications. In other words since view state is enabled on the machine level it is enabled on the application, page and control level. Thus each server control has view state enabled by default. Settings roll downhill so to say. How Do I Disable View State? Again, you may do so on the machine, application, page and control level. To disable view state of an individual control set its EnableViewState to false: As a rule of thumb if a control does not contain any dynamic data, or its value is hardcoded or assigned on every page request and you're not handling its events you can disable the control's view state . A good example of a big consumer of view state is the DataGrid control. Should you enable its view state or not? It depends. Again, if the page with the DataGrid does not post back you can live without view state just fine. On the other hand, if the DataGrid has sorting or paging enabled you will want view state. Remember, DataGrid renders as a table with rows and cells being its child controls. View state is maintained for these child controls. The DataGrid has no memory of the datasource you bound it to! The datasource is NOT stored in the viewstate. You may also disable view state on an entire page by modifying the Page directive: If you really wish you may also disable view state on the whole web application by adding the following line to your web.config : Can I Get Rid Of View State Completely? No. You will always have a relatively short string representing the page itself even if you turn off the view state on each and every control.

hi friends

Answers (1)