hi friends
where is the view state stored and can we get the view state value
Loading
Know the answer? Post it — somebody with the same question will find it here.
Sign in to answer this question
It is the same account you read, post and publish with — and you will come straight back to this page.
Posted Oct 15, 2007, 5:03 AM
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
Controlclass.Be it a
WebControl,HtmlControlor evenLiteralControlit has a property calledEnableViewState. When a page is built every control that has thisproperty 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."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebuistatebagmemberstopic.asp">StateBaghref="
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:
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!
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 andfill 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.
hashtable, custom TypeConverters
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
TypeConverterfor it to improveperformance.
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.configreveals thismuch:
The nature of
machine.configprescribes general settings for allapplications. 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
EnableViewStateto 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.