I have a ASP.NET 4.0 webforms site where I have the MasterPage so it is set to ViewStateMode="Disabled" along with the content placeholders being set similarly.
When I'd view my page I'd still see a ViewState field rendered, I then tried adding the ViewStateMode="Disabled" to the page level also but that didn't change anything.
I'm not aware of latest changes on ViewState for the framework 4 but you have to take into account that the ViewState field rendered to the client has 2 components: ViewState itself and ControlState.
The ControlState is ALWAYS sent to the client on the viewstate field no matter if you have enabled ViewState or not.
So you can expect to drastically reduce the size of the viewstate field sent to the client but not completely remove it.
Control state contains the minimal things that a control needs to persist across postbacks in order to work as expected.
Control State
In addition to view state, ASP.NET supports control state. The page uses control state to persist control information that must be retained between postbacks, even if view state is disabled for the page or for a control. Like view state, control state is stored in one or more hidden fields.
http://msdn.microsoft.com/en-us/library/bb386448.aspx
Related
What is the difference between ViewState and ControlState in terms of IsPostBack and how they work?
What is the actual use of ControlState?
Control state is a new construct within ASP.NET 2.0, and it is really nothing more than view state; however, it is view state with a significant advantage; that advantage is that other developers using your control cannot disable control state as they can view state.
http://www.codeproject.com/Articles/15300/Using-Control-State-in-ASP-NET-2-0
The ViewState & ControlState both stores the control properties ,you can disable the ViewState Property only and that will not affect the ControlState at all which loads in the page first loading or if the page is postBack the controlState already loads from saved memory
Since Control State and View State are the same then first question is , isn't it duplication of data?
Then we realise there is an advantage to Control State that it cannot be disabled. Then we might think why can't we do the same to View State :) why invent a new "Control State" for that. Now we have duplication of data. The reason to disable View State is nullified by the presence of Control state, right?
That is where the real advantage of Control State comes in. Control State is versatile. That is, a custom control can decide what to store in a control state. Where as view state is not intended to be stored specifically by a control, it is a general out of the box feature available. Because control state has a specific reason(and it has to be dependable) it is not designed to be disabled.
Control state, introduced in ASP.NET version 2.0, is similar to view state but functionally independent of view state. A page developer can disable view state for the page or for an individual control for performance. However, control state cannot be disabled. Control state is designed for storing a control's essential data (such as a pager control's page number) that must be available on postback to enable the control to function even when view state has been disabled. By default, the ASP.NET page framework stores control state in the page in the same hidden element in which it stores view state. Even if view state is disabled, or when state is managed using Session, control state travels to the client and back to the server in the page. On postback, ASP.NET deserializes the contents of the hidden element and loads control state into each control that is registered for control state.
i was recently surfing the msdn for the session state management tools, i came accross viewstate, which can be used the retain the page or controls value accross the page postback, so i created a simple application, which contains a asp:textbox and asp:button now i made the EnableViewState="false" for textbox and run the page, entered some values and clicked on the button, the page postbacked but the value was retained, i thought that would be because the pages viewstate property is enabled, so i changed the EnableViewState="false" in the page directives, and run the page, still the textbox value was retained in the textbox accross the postback, can anyone tell me with small example how the does viewstate work in my scenario
ViewState can probably not be explained with a small example ;-)
I'd recommend to read this article: Truly Understanding ViewState
The TextBox is rendered as input control, so the value is post back and set again to the TextBox.
The viewstate have a meaning on the TextBox for the other attributes that you can set it pro grammatically, or in case that you make it hidden and you like to keep the content of it.
I sort of answered my own question I think but I want to make sure I am understanding correctly. I initially thought that when a user provided values in a form, that on postback the values were submitted as part of the Viewstate, because TextBox.Text is part of the viewstate. Now I have found that user supplied values actually aren't applied to the controls until after the OnLoad event. This confused me because I thought that viewstate was loaded into the controls before OnLoad(or when calling Controls.Add()). I have gone over the documentation on page and control lifecycles a few times and I am just now realizing that there was a different step for handling postback data(this step didn't appear in a lot of documentation :(
1) So postback data, the values user's type into the fields, is applied after the OnLoad event, and Viewstate data is applied just before the OnLoad event?
2) So essentially all this means is that on postback the server gets two values for a TextBox.Text property, the one in Viewstate, which is like the "old" value from the previous request, and the new value supplied by the user in the form?
3) Does the .net framework apply postback data the same was as Viewstate, in that it finds the appropriate control via it's ID property? This is important because I am creating controls dynamically and I may even have forms that change structure overtime and need to think about how I handle ID's. So far I haven't been setting the ID property and everything works fine but things may be more complicated later on.
4) Does viewstate data ever get modified at all on client side? Or is the viewstate identical to what was sent by the server in the previous request(assuming no tampering)? My impression used to be that the server encoded all the control properties into the viewstate, and on the client side when the user submitted the form, the viewstate field was decoded, modified, encoded, and submitted to the server with modifications. I assumed there was a bunch of javascript doing all this for me. Now I think I had it all wrong. Instead it seems that the Viewstate never changes on client side, and all the client changes are in the postback data such that the next request the server loads viewstate, loads postback, and provides a new updated viewstate in the next response?
1) Both are loaded before Load
2) Basically, yes
3) ViewState is applied first, then Post Data
To quote Scott Mitchell(see below)
dynamically added controls must be
programmatically added to the Web page
on each and every page visit. The best
time to add these controls is during
the initialization stage of the page
life cycle, which occurs before the
load view state stage. That is, we
want to have the control hierarchy
complete before the load view state
stage arrives. For this reason, it is
best to create an event handler for
the Page class's Init event in your
code-behind class, and add your
dynamic controls there.
4) Unless you're doing something way outside of the box, ViewState is never modified client-side. "ViewState" is an HTML form field and is processed on the server side.
Here's a few images from Understanding ASP.NET View State by Scott Mitchell that may help you.
(source: microsoft.com)
(source: microsoft.com)
Bonus Reading Material: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
My impression used to be that the server encoded all the control
properties into the viewstate, and on the client side when the user
submitted the form, the viewstate field was decoded, modified,
encoded, and submitted to the server with modifications.
No, the point of the ViewState is simply to preserve the state of the page since the last "Save View State" page event, i.e. that event occurs shortly before the page is rendered to the client.
When the client makes selections to a dropdown box or changes text in a textbox the hidden ViewState property, which exists on the client page as a static HTML tag, is not dynamically changing / encoding those values, it remains the same as when the page was originally rendered.
So how is the new state of the page being preserved, i.e. how are user dropdown selections and text box values retained in ASP controls? Those dropdown selections and text box values are captured in Post Back data.
A server control can indicate that it is interested in examining the posted back data by implementing the IPostBackDataHandler interface. In this stage in the page life cycle, the Page class enumerates the posted back form fields, and searches for the corresponding server control. If it finds the control, it checks to see if the control implements the IPostBackDataHandler interface. If it does, it hands off the appropriate postback data to the server control by calling the control's LoadPostData() method. The server control would then update its state based on this postback data.
- Scott Mitchell
Put a textbox, a checkbox and a button on a website.
Set the "EnableViewState" property of textbox and checkbox to false.
Write something into textbox and check the checkbox.
Click the button.
Why is the textbox still written and the checkbox checked after response?
Some things aren't totally dependent on ViewState. In the controls you listed, those values are available in the POST sent to the server, so they're gotten out of there and the controls restore their state that way.
Other things, like the text in a <asp:Label> for instance aren't sent back in any way, and they'll lose their data without ViewState. The same is true for other properties, like the styling of the textbox, etc...only it's value will be restored, because that's all that's sent back and as a result, all it's coded to grab and restore. If you were to say make it red, that would be lost on postback.
As a general rule, what a control can restore strictly from posted data will be restored on postback, everything else is lost.
Because HTML Controls are Stateless control. Therefore Microsoft provide a feature of ViewState that help when a user sends the data into server or after post back the value remain same. Therefore you have to set the property "EnableViewState" to True. By default, all the ASP.NET controls have their EnableViewState set to True
I have an asp:Gridview bound to an asp:ObjectDataSource. I have disabled the ViewState on the GridView, and have not set the DataKeyNames property. I have about 10 BoundFields and a few TemplateFields. These TemplateFields are not bound to server controls but to an anchor tag or to an img tag.
However, at runtime, when I switch on page tracing I see that the ControlState of the Gridview varies between 7 and 12K for displaying just 14 rows of data. (View source on the rendered page also gives a same long string in the __VIEWSTATE hidden field). I do not understand why this happens as I have enableViewState="false" on the gridview and, as said above, I am not using DataKeyNames. So, where is this Gridview ControlState coming from and is there a way to get rid of it?
Thanks in advance,
Tim
i think its normal because:
control state cannot be disabled, Control state is designed for storing a control's essential data (such as a pager control's page number) that must be available on postback to enable the control to function even when view state has been disabled
note: By default, the ASP.NET page framework stores control state in the page in the same hidden element in which it stores view state. Even if view state is disabled microsoft said
that mean you actually saw the data of ControlState in _ViewState field which is ok
because as microsoft said the ControlState of the control stored in viewstate even if you disable ViewState
If you're disabling viewstate, not using any postback controls within the gridview, and not doing paging/sorting, then you're probably better off using a repeater. Repeaters don't have to be placed inside a tag. So, the control state won't be an issue.
If you're using .net 3.5 you could also investigate using the ListView, which to me seems like a repeater / gridview hybrid.
This article says that control state is actually stored in the __VIEWSTATE in a HybridDictionary.
Also, these articles say that even though you can set EnableViewState=false, you can never turn off ControlState (which is the point - so clients can't break your application):
Control State vs. View State Example
ASP.NET State Management Overview
ASP.NET State Management Recommendations