• Choose a category
• All
• Classic-Fiction

By Root 5278 0

data from the data-binding process or programmatically through the Items collection and the DataItem property, respectively. Composite data-bound controls (such as ListView and GridView) work on the assumption that they receive data exclusively from data binding and, for this reason, don’t persist bound data in any form. Consider now the following scenario.

Imagine a page that contains a rich control such as the GridView and some button controls. One of the button controls, when clicked, executes no code that involves the GridView but still refreshes the page. Without some special tricks in the control’s code, you can be sure that the composite data-bound control would be empty upon postback. Why is this so? If the postback event handler doesn’t bind data back to the composite control, the control has no way to figure it out and refresh properly. In ASP.NET, by design, composite data-bound controls take their data only from data binding and don’t cache any bound data. So a special workaround is required to handle postback events.

For composite data-bound controls, the CreateChildControls method works in either of two modes: binding or nonbinding. When CreateChildControls is working in binding mode, the control tree is created as usual. When it’s working in nonbinding mode, the control calls an overloaded version of CreateChildControls. The method is defined as abstract on the CompositeDataBoundControl and must be overridden in any derived class.

The Overloaded CreateChildControls

The overloaded version of CreateChildControls that is defined on the CompositeDataBoundControl class is shown here:

protected abstract int CreateChildControls(

IEnumerable dataSource, bool dataBinding);

The first parameter is the collection of bound data. The second parameter indicates whether the control is being bound to fresh data (that is, it is working in binding mode) or is being refreshed after a postback. The return value indicates the number of items added to the control tree. This value will then be stored in the view state during the call to PerformDataBinding. The following code snippet shows an excerpt from the source code of PerformDataBinding on the CompositeDataBoundControl class:

protected internal override void PerformDataBinding(IEnumerable data)

{

base.PerformDataBinding(data);

Controls.Clear();

base.ClearChildViewState();

TrackViewState();

int numOfItems = CreateChildControls(data, true);

base.ChildControlsCreated = true;

ViewState["_!ItemCount"] = numOfItems;

}

Note that PerformDataBinding calls into the new overload of CreateChildControls and passes it true as the second argument, indicating that a binding operation is taking place. This makes sense because executing PerformDataBinding, by definition, means you are performing a binding operation.

What kind of code should you place in the overloaded CreateChildControls? Basically, you call your own control builder method (typically, CreateControlHierarchy) and return its return value. I’ll return to this point later when discussing the sample BarChart control.

The overloaded CreateChildControls method is invoked in binding mode from within PerformDataBinding, and it’s invoked in nonbinding mode from within the other CreateChildControls method:

// o is the value read from ViewState

int numOfItems = (int) o;

object[] items = new object[numOfItems];

CreateChildControls(items, false);

In this case, the bound data passed to the method is an empty array of objects of a well-known size. The goal of this array is to force the control builder method (typically, CreateControlHierarchy) to loop the right number of times and build an outermost container with the right configuration—for example, a table with the right number of rows and columns.

As you’ll see in detail for the sample BarChart control, a composite data-bound control neatly separates hierarchy from data. If the Boolean parameter of CreateChildControls is false, no data is added to the hierarchy. How can the control show up as it did the last time? The ASP.NET postback mechanism guarantees