Making a "Private" Use of the "Public" ViewState

Published 27 November 03 03:50 PM | despos

Very few built-in server controls make a private use of the view state; and most often this is limited to particular features. A private use of the view state is when a control stores the content of non-public properties in the view state. By storing its internal properties to the view state, the control is using the view state privately. There's no way for parent controls and for the page to access this info. That's OK because that info is private to the control itself.

Making private use of the public viewstate is and remains a perfectly legal practice. However, it becomes a dangerous one when the view state is disabled at the page level. Like it or not, if the viewstate is disabled altogether there's not much a control can do.

Purposedly, ASP.NET 2.0 introduces a new type of state for controls--the control state. This is one of my favorite new features of ASP.NET--though one too specific for being mentioned in the highlights of the technology. In ASP.NET 2.0, the control state is safer to use than the view state because none of the application or page level settings can ever affect it. If your custom control has private or protected properties stored in the view state, you should move all of them to the control state in ASP.NET 2.0. Everything you store in the control state remains there until explicitly removed. The control state is persisted to a new hidden field named __CONTROLSTATE. This means that the more data you pack into in it, the more data is moved back and forth between the browser and the Web server. Unlike the view state, though, there’s no way to control the size of the control state. You should be using control state in ASP.NET 2.0; but be very very careful about it.

The implementation is left to the control developer. In other words, there's no predefined hashtable like ViewState where you add to. At least, this is not the case in the alpha. The idea is that you maintain your state in the variables that best suit you, much like what you would do in a stateful WinForms app. Then, by overriding the new SaveControlState method you pack any critical data into an array or a hashtable and return it to the system for further binary serialization and Base64 encoding. It is important for SaveControlState to return a serializable structure.

Hidden fields are more and more at the core of ASP.NET programming :-)

On the other hand, how could it be otherwise as long as HTTP is the underlying transportation?

Comments

# TrackBack said on November 27, 2003 05:00 AM:
# Andrew said on November 27, 2003 11:37 AM:

Glad to see you here.

If you are writing code to use viewstate, how do you make the data private?
Is it just a conceptual difference?

# DinoE said on November 27, 2003 11:51 AM:

>>If you are writing code to use viewstate, how do you make the data private?
>>Is it just a conceptual difference?

Sort of.
Private viewstate is just a property implemented through the viewstate but private or protected. For example:

private int _sortDirection
{
get {return Parse.Int32(ViewState["SortDirection"]);)
set {ViewState["SortDirection"] = value;)
}

With control state you use _sortDirection as a strong-typed property but avoid the intermediation of the ViewState collection to read/write it. Faster!

To make a private variable survive page postbacks, you have to add it to YOUR own collection (personal ViewState property). For example:

private override object SaveControlState()
{
object[] stateToSave = new Object[…];
stateToSave[0] = _sortDirection;
stateToSave[1] = _myProperty1;
:
return stateToSave;
}

The framework will serialize and encode that object for you. It can be an array as well as any other serializable type. It will be restored in LoadControlState.


private override void LoadControlState(object savedState)
{
object[] currentState = (object[]) savedState;
if (currentState == null)
return;

_sortDirection = (int) currentState[0];
:
}


PS: Just quoting from my next Introducing ASP.NET 2.0 book :-)))
PS2: Sorry in advance for any other shameless plugs :-)

# Victor Garcia Aprea said on November 28, 2003 01:14 AM:

Dino,

AFAIK, in the latest bits __CONTROLSTATE has been merged into __VIEWSTATE for perfs reasons. Or are you saying they're splitted again?

-Vic.

# DinoE said on November 28, 2003 03:56 AM:

Victor,
what do you mean when you say "latest" bits? I don't have the PDC or later bits, but the alpha I have is nearly identical to the PDC build. (So I was told <g>)
My alpha uses two distinct hidden fields. However, merging control state and view state in a single hidden field makes sense from a perf perspective.

A lot of internal code is shared between viewstate and control state management. Merging them together is a good idea.

--Dino

# Victor Garcia Aprea said on November 30, 2003 01:20 PM:

I'm talking about the M3 bits. We can assume they're still merged then ;-)

-Vic.

# 杭州主机托管 said on July 6, 2004 03:57 AM:

~~

# Turunen said on June 16, 2007 02:04 PM:

replicawatchesdiscount.info/.../citizen-heart-watch.php

Leave a Comment

(required) 
(required) 
(optional)
(required)