ASP.NET - Client Side State Management - Control State
In this post I'm going to explain what is the control state and how to use it as a part of the ASP.NET client side state management. You can read my previous posts in the state management subject in the following links:
- Client side state management introduction
- ViewState technique
- Hidden fields technique
- Query strings technique
- Cookies technique
What is Control State?
The control state is a way to save a control’s state information when the EnableViewState property is turned off. Unlike ViewState a developer can’t turn off control state. The control state can be implemented only in controls that you implement.
How to Use Control State?
Control state implementation is easy. First, override the OnInit method of the control and add the call for the Page.RegisterRequiresControlState method with the instance of the control to register. Then, override the LoadControlState and SaveControlState in order to save the required state information.
The next example shows a simple implementation for a control that saves a string as a state information:
public class ControlStateWebControl : Control
{
#region Members
private string _strStateToSave;
#endregion
#region Methods
protected override void OnInit(EventArgs e)
{
Page.RegisterRequiresControlState(this);
base.OnInit(e);
}
protected override object SaveControlState()
{
return _strStateToSave;
}
protected override void LoadControlState(object state)
{
if (state != null)
{
_strStateToSave = state.ToString();
}
}
#endregion
}
You need to remember only one thing – the control state takes away the choice to disable ViewState. You should
only use it whenever you have to keep a state information that without it your control won’t work.
Summary
To sum up the post, I showed what is the control state and how to enable it in your controls. The control state takes away the decision of a developer whether to use ViewState or not. Whenever you want to use the control state you should think whether to implement it or give the decision of how to save the state information to the developers that use your control. I prefer the second choice. In the next post in this series I’ll start to explain the server side state
management.
Gil Fink is working at Sela Group as a .NET consultant. Gil graduated his computer science BA degree in the Interdisciplinary Center in Israel with honours. Also, Gil holds a Microsoft's MCPD enterprise application developer title. Gil's fun is to develop infrastructure for projects, solve logic and design problems and to return home to his baby boy Oron and his loving wife Liora. Gil's interests includes variety of things including Enterprise Library, WCF, LINQ, Entity Framework or whatever Microsoft is throwing at him. Gil is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 6080 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
dlink22 replied on Thu, 2008/10/16 - 11:07pm
To save multiple properties into Control State:
private int _prop1;
public int Prop1
{
get { return _prop1; }
set { _prop1 = value; }
}
private string _prop2;
public string Prop2
{
get { return _prop2; }
set { _prop2 = value; }
}
protected override object SaveControlState()
{
object[] state = new object[2]; // save the 2 properties
state[0] = _prop1;
state[1] = _prop2;
return state;
}
protected override void LoadControlState(object savedState)
{
object[] state = (object[])savedState;
_prop1 = (int)state[0];
_prop2 = (string)state[1];
}
gilf replied on Fri, 2008/10/17 - 7:03am
in response to: dlink22
Thanks for sharing that code.
You can do it without an array and with an internal class which you can call [NameOfTheControl]State and will hold all the relevant properties. I prefer that solution because I don't like to hard code indexes and it's more elegant. Also, as I wrote I prefer if I can to minimize the number of properties that I save in the control state in order to give the users of the control more flexibility.
snives replied on Tue, 2008/10/21 - 8:55pm
@Gilf, I read the description of how you prefer to store controlstate and decided to test it out for myself. Here are the results of my findings:
When using a composite class to persist your objects the ObjectStateFormatter takes the composite class/struct stores it in viewstate. But before that it checks its type to see if there is a special optimization for that object type. Since it is a custom object it doesn't do any optimization and simply serializes it, but it also needs to include the fully declared name of the object it is serializing! *This* actually results in the opposite behavior than what you are trying to do, optimize viewstate. In a test app storing two GUIDs in a structure instead of a Pair object, the viewstate was 348 bytes larger than the optimized Pair version. Thats alot of overhead for what could essentially be stored in 78 bytes.
As I eluded to above the ObjectStateFormatter has special optimizations for certain types, which can be found here http://msdn.microsoft.com/en-us/library/system.web.ui.objectstateformatter.aspx. If you are storing control state, then there is really hardly reason to store more than 1 or 2 variables, which are usually keys anyhow. If you only have 1 variable just return it. If you have 2 use a Pair object. If you have 3 there is even a Triplet object. If you have 4 or more, then use an object array, as this article shows.
I am all for simplicity and elegance as well, but in this case the more elegant approach is actually causing us a viewstate bloat problem. And since the Object[] is loaded and saved within the same class, there really isn't any downside to using it.
gilf replied on Wed, 2008/10/22 - 1:40am
in response to: snives
As you wrote, I prefer the elegant way but in the control state case, as you mentioned, this will cause us a viewstate bloat problem (I checked it after I read your comment).
Thanks for your insight.
GarryWert replied on Fri, 2009/10/02 - 4:47am