4. Putting it all together

In fact, using an extended control isn’t that much different than using the stock control thanks to inheritance.  For the most part, the extended control works exactly the same as the standard GridView control. I wanted to just touch base on a couple of places that a lot of people are having problem with.

First is the asp tag prefix issue. By default, all the custom controls (*.ascx) will automatically show up in the Toolbox strip within Vistuo Studio. So using the extended GridView is a simple matter of drag and drop. However, the default prefix for custom control is cc1, and depending on how many pre-existing custom controls there are on a page, it could be cc{num}. This becomes hard for replacing existing GridViews with the extended GridViewEx. To resolve this naming issue, we can register the assembly which contains the extended control within system.web->pages->controls tag in web.config:

With this prefix defined, we can use the tag ExtendedGridView wherever GridView is expected. By registering the prefix, we have also provided the solution to a second problem people often run into when using extended web controls–namely the ability to "skin" the control. With the extended control prefix registered, we can now create skins the same way as we do with other controls. For instance, my default.skin might look like:

In this way, the theming issue of the extended GridView is addressed.

The code for the code behind page to display the extended GridView is trivial:

As you can see,  the code is pretty much in line with what we would use for a typical GridView control. When the page is posted back, we set the DataSource and bind the data to the grid. Everything else happens transparently behind the scene. To illustrate the capability of GridViewEx, I included a CheckBox at the end of each row, whenever the check status is changed (CBSelected_CheckedChanged) we dynamically obtain the reference to the GridViewEx object (as an alternative, we could have used the actual control (GridViewEx1) instead of going through the trouble of dynamically converting if from the sender object since GridViewEx1 exists at compile time. Should the control be created dynamically, the code here will come in handy). Please pay special attention to how the checked state is determined. Because paging might be involved when the bound list has more entries than can be displayed, the current row index on the screen might not be the same as the row index in the list. To simplify coding, I created an Index function within GridViewEx to translate the selected row index into what is stored in the list.

The code samples provided in this series can be downloaded here.

Of course, there are a lot more fancy things you can do with the grid or with any objects in that matter. The only limit is your imagination…

See also

Code Download: ExtendingTheGridView.zip

3. GridViewPager

 Here is the code for GridViewPager:

As you can see, the pager control is quite simple. It communicates with GridViewEx control by the SelectedIndexChanged event. Depending on whether the state of number of items per page needs to persist between post backs, either ViewState or SessionState can be used.

See also

Code Download: ExtendingTheGridView.zip

2. GridViewEx
To make the binding as generic as possible, there are pretty much two ways. One way is to bind to an object collection of typed value objects. Since all value objects can be cast into objects, we could manipulate them generically. And because value objects are typically consisted of simple types, we could encapsulate all the operations needed for the GridView within the extended GridView itself.

Another solution is to utilize generics in .Net 2.0 and above. One obvious advantage is that the type information is not lost at any point of the object manipulation and thus a lot of small mistakes can be caught at compile time. This approach does have its draw backs. As you will see, because the purpose of generic types are to eliminate casting introduced by object containers, we have to change the extended GridView to accommodate the type of objects we are binding to the list whenever a new generic type is introduced. This of course requires the changing of the extended GridView control itself whenever we add a new generic type and thus might not be as convenient as the pure object oriented approach mentioned previously. However, weighing both the advantages and disadvantages I personally think this approach is more attractive.

So here, I will show you how to extend the GridView to handle generic lists.

GridViewEx inherits from GridView. We override the DataSource property so that we get a chance to inspect it before the databinding actually taking place. This gives us an opportunity to test whether the data source to be bound is empty. We use this information to decide whether to show the pager or not as you will see in a later post.

The initialization routine (OnInit) is overridden to setup some property values and hook up some events so that we provide row editing functionalities.

The RowEditing, PageSelectedIndexChanged and some of the other overridden functions are handled in a pretty standard way. To demonstrate how easy it is to add new functionality to the GridView, I added an event handler for RowDataBound. The purpose of the code for this RowDataBound event is to check if the CheckBox on a particular row is checked and if so, the background color of that row is changed. This behavior is particularly helpful for giving a visual cue to the end user which row of data he/she is currently dealing with.

When each row is created, OnRowCreated method is called, here we determine whether the row being created is the header or not and if so, we add an arrow to indicate the current sorting option depending on how the grid is currently sorted. If the row being created is a data row, we add some nice touch so that the data row becomes highlighted when mouse moves pass it.

We also have to override the OnSorting function to handle our generic lists. This is where we need to add the supported list types (see comments in code). For additional generic list types, we simply need to add three lines for each type of the list. While this might not be as convenient as using generic objects, all the changes are kept in a central place so that adding/removing types should not be an issue.

Because we are using customized objects as data bound objects, we also need to provider our own comparer so that the grid knows how to sort each column. This task is fairly easy and I modified the implementation from GridViewGuy. One thing you need to pay special attention is that since the comparison is done using property reflections, the property names are by default case sensitive (e.g. if you have a value property named Item, the binding in ASP.Net must be "Item" as well. "item" will give a run time error).  The code for the comparer is as follows:

See also

Code Download: ExtendingTheGridView.zip

For instance, the default data binding is limited to SqlDataSource, ObjectDataSource or a DataSet object (including DataView, DataTable, etc.). When building a large scale business solution, it is generally desirable to complete separate the data manipulation and business logic from the presentation layer and the most common solution is to employee a Model-View-Controller pattern.  This requirement makes SqlDataSource and DataSet bindings unsuitable. While ObjectDataSource does provide some level of isolation, the way business objects can be constructed is limited in order for these objects to be used as ObjectDataSource.

Most business objects incorporate the so-called Value Object data structure. Basically, it is a serializable class with the sole purpose of holding values and possibly other functionalities like data validation. Unfortunately, by default, GridView’s support for such value objects is poor (i.e. you can bind a value object to a grid view, but sorting is not supported by default). Over the years, I have seen many ad-hoc implementations to make GridView suitable for binding with customized value objects. Unfortunately, many of the solutions were implemented poorly and the implementation techniques vary from person to person, making it difficult if not impossible to maintain.

In the next few blog posts, I will show you how to extend the stock GridView in ASP.Net to make it suitable for using with value objects. The goal of extending the standard GridView is not only to add sorting capabilities, but to make the new component compatible with the standard GridView. I also intended to hide as much implementation details as possible so that the end users do not need to worry about the syntactical nuances as do with the standard GridView when binding to objects.

I assume that the development environment is Visual Studio 2005 with AJAX extension installed. The samples I show here can run within either Visual Studio 2005 (with AJAX extension) or Visual Studio 2008 without any modifications.

1.Defining the Value Object

As mentioned before, the reason we would like to define our own so-called value objects instead of using a DataSet to hold data is to ensure type safety. Since DataSet can hold any kind of objects, debugging becomes more difficult as error checking happens at run time not compile time. It also makes it easy to make mistakes as columns must be accessed by their names and any changes in column names could result in code broken at runtime somewhere in the UI.  Most importantly, binding a dataset directly to the UI violates the layered design principal, making the data and the presentation tightly coupled and difficult to adapt. The solution is to create a level of indirection by utilizing the so called value objects. Value objects are nothing fancy, they are merely a serializable class that provides the properties that represent the data (e.g. a row in a table) we are dealing with. For instance, here is what we might create as a value object for a simple phone book:

By creating a collection of such value object we just defined, we have a full representation of the result set returned from the database via a query or stored procedure. And via value objects, all the accesses are guaranteed to be type safe.

See also

Code Download: ExtendingTheGridView.zip

Suppose we are creating a simple application where you can select multiple people from a contact list and then do somthing with your selection (e.g. export the selection etc.) An intuitive way is to include a column of CheckBoxes in the front of all the rows so that the staus of each CheckBox indicates whether that row is included in the user selection (See below):

In this demonstration, I will use a customized object data source called UserDefinition: 

[Serializable()]

public class UserDefinition

{

    private bool _entrySelected = false;

    private string _userName = string.Empty;

    private string _phoneNumber = string.Empty;

 

    public bool EntrySelected

    {

        get { return _entrySelected; }

        set { _entrySelected = value; }

    }

 

    public string UserName

    {

        get { return _userName; }

        set { _userName = value; }

    }

 

    public string PhoneNumber

    {

        get { return _phoneNumber; }

        set { _phoneNumber = value; }

    }

 

    public UserDefinition(string name, string phone)

    {

        _userName = name;

        _phoneNumber = phone;

    }

}

Alternatively, you could use pretty much any data sources that you are accustomed to. The concept should be similar  enough.

And the GridView is defined as follows:

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False">

    <Columns>

        <asp:TemplateField HeaderText="Select">

            <ItemTemplate>

                <asp:CheckBox ID="CBEntrySelected" runat="server" AutoPostBack="True" Checked=‘<%# Bind("EntrySelected") %>’

                    OnCheckedChanged="CBEntrySelected_CheckedStateChanged" />

            </ItemTemplate>

        </asp:TemplateField>

        <asp:BoundField HeaderText="User Name" DataField="UserName" />

        <asp:BoundField HeaderText="Phone Number" DataField="PhoneNumber" />

    </Columns>

</asp:GridView>

Note that the AutoPostBack property is set to true so that the server side code would have an opportunity to record the user’s action. So far, every thing should be pretty straightforward. The only trick is in the server side code:

    protected void Page_Load(object sender, EventArgs e)

    {

        DisplayGrid();

    }

 

    private void DisplayGrid()

    {

        List<UserDefinition> list = new List<UserDefinition>();

 

        list.Add(new UserDefinition("Bob", "(232) 111-1312"));

        list.Add(new UserDefinition("Sue", "(088) 676-9987"));

        list.Add(new UserDefinition("Jim", "(678) 123-4567"));

 

        GridView1.DataSource = list;

 

        if (!Page.IsPostBack)

        {

            GridView1.DataBind();

            ViewState["CurrentView"] = list;

        }

    }

 

    protected void CBEntrySelected_CheckedStateChanged(object sender, EventArgs e)

    {

        CheckBox checkBox = sender as CheckBox;

        GridViewRow selectedRow = checkBox.Parent.Parent as GridViewRow;

        List<UserDefinition> list = ViewState["CurrentView"] as List<UserDefinition>;

        list[selectedRow.RowIndex].EntrySelected = checkBox.Checked;

    }

 

    protected void BtnSubmit_Click(object sender, EventArgs e)

    {

        List<UserDefinition> list = ViewState["CurrentView"] as List<UserDefinition>;

        StringBuilder sb = new StringBuilder();

 

        sb.Append("<br />Selected items:<br />");

 

        foreach (UserDefinition def in list)

        {

            if (def.EntrySelected)

            {

                sb.Append(string.Format("{0} : {1}<br />", def.UserName, def.PhoneNumber));

            }

        }

 

        Label1.Text = sb.ToString();

    }

Note that in our CkeckBox checked event handler CBEntrySelected_CheckedStateChanged, we used the GridView object hierarchy to figure out which row was selected/unselected by user and record it accordingly in the object that the grid renders. The hierarchy is as follows:

 CheckBox -> DataControlFieldCell -> GridViewRow -> ChildTable -> GridView

 Also note that in our simple example, only the RowIndex is used to determine whether a row is selected or not. This only works when paging is not involved. When there are multiple pages, we have to go two hierarchies higher to the GridView level, where we can use PageIndex and PageSize to identify the correct selection (i.e. PageSize * PageIndex + RowIndex).