Programming Microsoft ASP.NET 4 - Dino Esposito [121]
The binding container indicates which control in the page hierarchy represents the parent of a control as far as data binding is concerned. In other words, the binding container is the control that receives bound data from the host (typically, the page) and that passes it down to child controls.
As you can easily imagine, binding and naming containers often coincide. The only exception is when the control is part of a template. In that case, the NamingContainer property is generally set to the physical parent of the control, namely a control in the template. BindingContainer, instead, will point to the control that defines the template.
ASP.NET 4 introduced two additional special containers: data item and data keys containers. These containers are exposed through the DataItemContainer and DataKeysContainer properties. These containers don’t introduce a new point in the ASP.NET control architecture. They simply identify some capabilities in an existing naming container. The capabilities are summarized by the IDataItemContainer and IDataKeysControl interfaces.
View State of Controls
The view state has been one of the most controversial features of ASP.NET since the advent of the platform. Too many developers are still convinced that the view state is a waste of bandwidth and an unacceptable burden for each and every ASP.NET page. Nearly the same set of developers eagerly welcomed ASP.NET MVC because of its complete absence of view state.
The view state is strictly functional for the Web Forms model because it caches some of the content for the controls in the page. Next, the ASP.NET infrastructure takes care of reading that information to restore the last known good state for each control within the page.
Since the beginning, the view state was designed with a hierarchical structure—if it is enabled for the parent, it is enabled also for the children. To keep the size of the view state under control, you might decide to disable the view state only on certain controls. The property EnableViewState seems to be just the perfect tool for the job.
Unfortunately, the capabilities of the EnableViewState property have been exaggerated in the past years. The strictly hierarchical nature of the view state requires that if the view state is enabled on the parent control, it won’t be disabled on any of its child controls—regardless of the value assigned to EnableViewState on child controls. This issue has been fixed with ASP.NET 4, but for the sake of thousands of existing applications the fix comes through a new, dangerously similar property: the ViewStateMode property.
In summary, if the view state is enabled on the page (which is the default setting), you have no means to keep the state of individual controls off the storage. To gain some control over it in ASP.NET 3.5, you need to disable the view state at the page level and then re-enable it where needed. However, you should be aware that any container control that has the view state enabled will inevitably push its setting down to the list of its children.
Imagine you have a page with three hundred controls and need view state disabled only on three of them. Until ASP.NET 4, you had to disable the view state on the page first and then re-enable it for the 297 controls where you want to keep it. That’s too much work, isn’t it?
The ViewStateMode property allows for the enabling and disabling of the view state on any controls in the direct way that always seemed natural. The property accepts values from the following enumeration:
public enum ViewStateMode
{
Inherit,
Enabled,
Disabled
}
Enabled and Disabled mean the view state is enabled or disabled for the specific control—no matter what. Inherit means the control inherits any settings defined on its parent. This is the default setting.
Note
To better understand the intricacy of the view state issue in earlier versions of ASP.NET, consider the following fact. Any ASP.NET control has