I know ASP.NET doesn't allow to disable control state.
Does anybody know why? I've googled a lot but only saw it is not possible, but was not able to find "WHY?"
Any thoughts on this would be welcome!
P.S. In my particular case I need to put a lot of items into a dropdown list that will NOT be used for server side events. Instead of just disabling control state I need to write my own custom DropDownList... :(
Control state was separated from view state so that view state could be disabled without breaking critical functionality. In theory, control state should contain everything necessary for the server control to function properly.
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.
http://msdn.microsoft.com/en-us/library/1whwt1k7(v=vs.100).aspx
However...ASP.Net does a poor job of making this distinction, and disabling view state will indeed break certain server controls despite the mandatory control state.
In your case, disabling view state for the dropdown list should remove the vast majority of state data; control state is usually quite small for a dropdown with view state disabled. I suggest trying it first before writing your own.
Related
I have been writing a bunch of generic ASP.NET controls, and one thing I can't seem to wrap my mind around is when to store values in viewstate, and when to assume it's OK not to.
On one hand, it makes sense to store the entire state of the control in viewstate, including properties like:
Text box values entered by the user (or any form data)
Configuration options like height or page size
Even how the control has been composed - for example storing all the data a grid view is built from, or the grid itself.
Ignoring performance, the more you can shove in viewstate the better, because it means the control will behave exactly the same across postbacks and never "accidentally" revert a value or "forget" it was disabled. But viewstate is not free. Storing everything means the control will now output both the HTML and all its internal properties to create that HTML, which would almost always more than double the output.
My question is not about performance, but about strategy. On what criteria do I decide to put a property in viewstate? I was thinking something along these lines:
If the user can't change a property, then the server will always set it explicitly, so it's OK to leave it out of viewstate. Even for something like color=red, the user doesn't set this property directly; they will click a button elsewhere which indirectly sets this property. That button or its owner should keep the state, not the control that renders the color red.
This logic implies that the only properties that should go into viewstate would be:
Form elements like <input> (and with Request.Form[c.UniqueID] this can be avoided still)
Properties that the user can control interactively directly on the control.
Does this logic make sense? It seems weak and I'd like to hear more from experts.
Use ViewState for things that are not necessary for your control to work.
Use ControlState for things that are necessary for your control to work even if ViewState is disabled.
The initial values and the control hierarchy(even html-controls) are compiled into Temporary ASP.NET Files when the page is first requested. So they don't need to be stored anywhere when they are never changed (and even ViewState will not save them).
A control does only store properties in ViewState which have changed during the page's life-cycle(since TrackViewState). A control which state was changed is "dirty". For example if you change TextBox1.Text in page_load, ViewState.IsItemDirty("TextBox1.Text") would return true. These values will be stored in ViewState.
Look here and here. (I really recommend to read both articles)
Control State vs. View State Example
Check this article on MSDN covering when, where and what to use the plethora of state management options available in ASP.NET the view state section is posted below for convenience - checking your requirements against the advantages and disadvantages should guide you on usage on a case by case basis:
Whole article here: http://msdn.microsoft.com/en-us/library/z1hkazw7(v=vs.100).aspx
Viewstate Excerpt:
View State
Web Forms pages provide the ViewState property as a built-in structure
for automatically retaining values between multiple requests for the
same page. View state is maintained as a hidden field in the page. For
more information, see ASP.NET State Management Overview.
You can use view state to store your own page-specific values across
round trips when the page posts back to itself. For example, if your
application is maintaining user-specific information — that is,
information that is used in the page but is not necessarily part of
any control — you can store it in view state.
Advantages of using view state are:
No server resources are required The view state is contained in a
structure within the page code.
Simple implementation View state does not require any custom
programming to use. It is on by default to maintain state data on
controls.
Enhanced security features The values in view state are hashed,
compressed, and encoded for Unicode implementations, which provides
more security than using hidden fields.
Disadvantages of using view state are:
Performance considerations Because the view state is stored in the
page itself, storing large values can cause the page to slow down when
users display it and when they post it. This is especially relevant
for mobile devices, where bandwidth is often a limitation.
Device limitations Mobile devices might not have the memory capacity
to store a large amount of view-state data.
Potential security risks The view state is stored in one or more
hidden fields on the page. Although view state stores data in a hashed
format, it can still be tampered with. The information in the hidden
field can be seen if the page output source is viewed directly,
creating a potential security issue. For more information, see ASP.NET
Web Application Security and Basic Security Practices for Web
Applications.
I think you're right to be concerned about viewstate bloat, but what other options are available to you? If you don't store your variable data there, where will you put it? (You may wish to consider removing some configuration items- perhaps not let the user change so many properties).
I set ASP.Net ViewState to off for a text box control, but the value for the name of the user is still there. Why is this so?
In a nutshell:
View state's purpose in life is simple: it's there to persist state across postbacks. (For an ASP.NET Web page, its state is the property values of the controls that make up its control hierarchy.) This begs the question, "What sort of state needs to be persisted?" To answer that question, let's start by looking at what state doesn't need to be persisted across postbacks. Recall that in the instantiation stage of the page life cycle, the control hierarchy is created and those properties that are specified in the declarative syntax are assigned. Since these declarative properties are automatically reassigned on each postback when the control hierarchy is constructed, there's no need to store these property values in the view state.
like balexandre already posted
ViewState cannot be modified by the browser, as the browser has no knowledge of what viewstate is. It's merely a snapshot of what was sent to the client and will be interrogated once the form is post back to the server.
Have a look at the following article to get a better understanding of what ViewState is
In a simple answer: Yes
But you should read all about View State as it's important to undertsand it and not thinking that things automagical work.
Understanding ASP.NET View State
I'm working on a webform with various controls. Depending on user-input I show/hide (using JQuery's show()/hide() functions) bits of the GUI. However if the form is posted-back and fails validation, I want the GUI to remain in the same state it was pre-postback rather than returning to the first-load state. Obviously the ASP.Net controls retain state, but I have HTML containers that are pure client-side objects.
In attempting to design a solution I find myself heading towards the murky (and tricky-to-debug) realms of hidden form fields - more reminiscent of my pre-JQuery work than anything 21st Century :-(
Can anyone suggest a better way ...?
If anyone's reading this:
I went with a JQueryish solution - a JS function now runs onready. It checks the state of any ASP.Net controls which act as 'visibility controllers' (which obv. maintain their own state across postbacks) and sets the UI accordingly via JQuery calls.
I think the trick is to use the hidden fields to persist the state of the client-side fields.
So the process is something like:
user action -> update hidden value(s) -> update UI
Then when the page posts back, you re-set the UI:
page load -> update UI
I have turned off all the viewstate settings but there is still viewstate in the page, i need to switch the control state off also.
Control state cannot be disabled.
See Control State vs View State example, a few lines down from the top.
See also this other question.
See this blog post for a longer discussion about Control State.
We have a web content management system (based on Sharepoint 2007/MOSS, but for the purposes of this problem, that is not relevant, so please stick around even if you haven't worked on MOSS!). On a given page, there are conditions we cannot change:
An editor clicks "Edit" and the page posts back.
When it reloads in edit mode, the control tree is entirely different.
ViewState must be enabled in edit mode, since the edit controls post back frequently
If we disable ViewState in presentation mode, everything works fine. ViewState gets set to "enabled" on the edit postback, the ViewState tree is built up for the first time as the edit controls are generated, and all is well.
If we enable ViewState in presentation mode, when transitioning from presentation to edit, we get a ViewState error because the control tree changes.
We need to enable ViewState in presentation mode, so we need to fix this transition error.
We have tried disabling ViewState during the postback, then programmatically posting back again and re-enabling it, but this causes validation issues with MOSS, so it does not appear to be an option.
Ideas?
Have you tried the clear method on the property bag ;-)
Are you changing the control tree with some advanced information? Typically on the postback you'll rebuild the same control tree before the event handlers for buttons fire (view state should validate at this point) and then handle the event - which may include clearing out previous parts of the control tree.