Unhandled Exception

My first channel 9 video!

davidfowl — Fri, 23 Oct 2009 04:16:00 GMT

Wow, I haven't blogged in a while...but that will end soon. Watch me talk about the QueryExtender control. It's a new control we added in ASP.NET 4.0 to make Linq queries even simpler. The new control works with LinqDataSource and EntityDataSource. We also built all of the new DynamicData filters on top of this new control.

Check it out here

Dynamic Data in Regular Websites/Web Applications

davidfowl — Thu, 07 May 2009 01:33:00 GMT

Today I'm excited to share that we've released DynamicData Preview 4 on codeplex. Check out the latest bits here.

This release is particularly interesting not only for people that have been using Dynamic Data for a while now, but anyone that has an existing application today who wants to use some of the niceties Dynamic Data offers without having to take all the junk associated. Take a look at the SimpleDynamicData project for examples.

Existing Sites

Here are 2 good reasons to use Dynamic Data:

Rich model validation
Rich templating support via FieldTemplates

If you've ever written a data driven app in webforms using our data controls, you would have realized that we are lacking a lot when it comes to validation. You can enable all of this goodness with a magic extension method.

protected void Page_Init() {

    GridView1.EnableDynamicData(your type here);

Note: The method requires that you pass in the type that may have annotations in order for us to read Metadata. If you're not familiar with the way annotations work in Dynamic Data then watch the videos here.

This method call enables DynamicControl/DynamicField to work within any of the data controls which makes use of FieldTemplates, and enables the rich validation support.

Making it work

So we know about this magic method call and somehow calling it with a type makes it all just work. Let's walk through an example of how we would use this. Here is my model:

public class Student {

    [Required]

    [Range(0, 100)]

    public int Age { get; set; }

    [Range(0.0, 4.0)]

    public double GPA { get; set; }

    [Required]

    public string FirstName { get; set; }

    [Required]

    public string LastName { get; set; }

    [DisplayFormat(DataFormatString = "{0:d/M/yyyy}")]

    public DateTime BirthDate { get; set; }

This is the type we are going to use for metadata. Using the attributes from System.ComponentModel.DataAnnotations we can add useful annotations to our model that will be used for validation and display formatting. Adding these attributes allows Dynamic Data to enable the appropriate validator. i.e RangeValidator, RequiredFieldValidator etc.

Now we're going to enable this on our GridView using the same method call as above in conjunction with an ObjectDataSource to complete our application:

protected void Page_Init() {

    GridView1.EnableDynamicData(typeof(Student));

Markup

<asp:GridView ID="GridView1" runat="server" DataSourceID="ObjectDataSource1" AutoGenerateEditButton="true">

    </asp:GridView>

    <asp:ObjectDataSource ID="ObjectDataSource1" runat="server"

        DataObjectTypeName="Student" DeleteMethod="DeleteStudent"

        InsertMethod="InsertStudent" SelectMethod="GetStudents"

        TypeName="StudentsRepository" UpdateMethod="UpdateStudent">

    </asp:ObjectDataSource>

Note: Dynamic Data takes care of the Metadata not the data. You still need databind the data control against some data source/data source control.

Here are the results when we are editing:

As you can see, the attributes we specified on our Student class directly affect the grid and validation is enabled.

There's more cool stuff to talk about but I'll mention those in upcoming posts. For now, download the preview and read up on Dynamic Data!

External ITemplates and Hierarchical Databinding

davidfowl — Tue, 17 Mar 2009 06:25:00 GMT

Ever wish you could declare a template outside of the control you were defining the template for? We always get requests to have FormView's InsertItem template fall back on the EditItemTemplate and vice versa. That would be easy if we could do what was mentioned above.

Consider:

<asp:FormView ID="myFormView" runat="server" DefaultMode="Edit"

    EditItemTemplate="editTemplate"

    InsertItemTemplate="editTemplate">

</asp:FormView>

<asp:Template runat="server" ID="editTemplate">

    Name : <asp:TextBox runat="server" Text='<%# Bind("Name") %>'></asp:TextBox>

    Age : <asp:TextBox runat="server" Text='<%# Bind("Age") %>'></asp:TextBox>

</asp:Template>

Then you could do things like hierarchical databinding pretty easily; just define the template in terms of itself. Today, properties typed as ITemplate are treated specially by the ASP.NET parser, and what is written above will not work.

How would you do this with what asp.net offers now? Well check out this sample:

<cc:SpecialRepeater runat="server" ItemTemplateID="folderTemplate" DataSource='<%# GetDirectories() %>' />

<cc:Template runat="server" ID="folderTemplate">

    <ItemTemplate>

        <ul>

            <li>

                <%# Eval("Name") %>

                <cc:SpecialRepeater runat="server" DataSource='<%# GetDirectories((string)Eval("FullName")) %>' ItemTemplateID="folderTemplate" />

                <ul>

                    <cc:SpecialRepeater runat="server" DataSource='<%# GetFiles((string)Eval("FullName")) %>' ItemTemplateID="fileTemplate" />

                </ul>

            </li>

        </ul>

    </ItemTemplate>

</cc:Template>

<cc:Template runat="server" ID="fileTemplate">

    <ItemTemplate>

        <li> <%# Eval("Name") %>

        </li>

    </ItemTemplate>

</cc:Template>

We have a SpecialRepeater that understands how to hookup template properties through their ID (it's just FindControl) and a Template control that defines our file template and folder template. We define the folder template in terms of itself. Can you think of any more uses for something like this?

Get the code here.

What do you think?

Invalid postback or callback argument

davidfowl — Mon, 09 Mar 2009 07:54:00 GMT

I'm sure many of you have seen this error message when developing your web application:

Server Error in '/' Application.
--------------------------------------------------------------------------------

Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

I'm going to discuss this in the context of the data controls. This happens when a control that isn't registered for event validation causes a postback, but surely that can't be the case.. right?

Let's look at a small repro:

Markup:

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

    <Columns>

        <asp:TemplateField>

            <ItemTemplate>

                <asp:Button runat="server" Text="Button" />

            </ItemTemplate>

        </asp:TemplateField>

    </Columns>

</asp:GridView>

Code behind:

public partial class _Default : System.Web.UI.Page {

    protected void Page_Load(object sender, EventArgs e) {

        GridView1.DataSource = Enumerable.Range(0, 5);

        GridView1.DataBind();

Now click on the button and see the dreaded error message. Why does this happen? EventValidation was added in ASP.NET to ensure that controls causing the postback came from the same page being rendered. Take a look at __EVENTVALIDATION hidden field on the page. It is a serialized version of all of the controls registered for postbacks(read more here). You might be wondering how they got in there and why is the button inside of a GridView a special case. It's not a special case, in fact, Button registers itself with the current page.

The reason this happens is because we rebind the data control in Page_Load every time which means that we will lose all of the posted data and viewstate. As a result, the ID of the button is different and when the event is validated there will be no matching unique id and hence event validation will fail. We are acutally raising an event for a button that is no longer in the control tree.

You can work around this by wrapping that code in if (!IsPostBack). This is a good proof of why you should use DataSource controls.

Hope this helps

A new way to DataBind()

davidfowl — Thu, 05 Feb 2009 06:27:00 GMT

The Problem

I've been thinking alot recently about the problems with data binding (and they're alot). There are some patterns that play well with ASP.NET (and are repeated everywhere) and some that don't quite fit the model. One of those patterns that don't mesh well is, setting the DataSource property of any of the DataControls. Before ASP.NET 2.0 and DataSource controls we'd have to set the DataSource property and manually call DataBind.

What's wrong with this you may ask? When are you supposed to DataBind? Page_Load ? Page_Init? Page_PreRender? I'm sure anyone that has had to manually data bind has had the problem of figuring out which code goes in and out of the IsPostBack block.

Whats the solution?

I'm looking at an alternative approach to this problem. Event handlers are nice because we all feel confident that the author of the event knows when that event should be raised. No need to figure out the postback logic because the control author already thought about that. All you have to worry about is handling the event.

I propose a new hypothetical event OnDataRetrieveing, that would be on all DataControls in conjunction with a new flag AutoBind to enable it.

Let's take a look at a sample implementation of a derived GridView control that has this new behavior. First the markup:

<custom:AutoGridView

    OnDataRetrieving="OnDataRetrieving"

    OnPageIndexChanging="OnGridViewPageIndexChanging"

    OnRowEditing="OnGridViewRowEditing"

    OnRowCancelingEdit="OnGridViewRowCancelingEdit"

    AllowPaging="true"

    runat="server"

    ID="GridView1"

    AutoGenerateEditButton="true"

    AutoBind="true">

</custom:AutoGridView>

Looks pretty similar to the regular GridView besides the AutoBind="true" flag and OnDataRetrieving event.

And the code behind

protected void OnGridViewRowCancelingEdit(object sender, GridViewCancelEditEventArgs e) {

    GridView1.EditIndex = -1;

protected void OnGridViewPageIndexChanging(object sender, GridViewPageEventArgs e) {

    GridView1.PageIndex = e.NewPageIndex;

protected void OnGridViewRowEditing(object sender, GridViewEditEventArgs e) {

    GridView1.EditIndex = e.NewEditIndex;

protected void OnDataRetrieving(object sender, DataBindingEventArgs e) {

    NorthwindDataContext db = new NorthwindDataContext();

    e.DataSource = db.Products;

We write code as we normally would if we'd been binding manually, but instead, we assign our data to the DataSource property in the DataBindingEventArgs (Which gets called at the "right" time).

So what is the right time to Databind and why does this control do it better than you? I'm not sure :) but let's look at the source of this control.

public override object DataSource {

    get {

        return base.DataSource;

    set {

        if (!_settingDataSource && AutoBind) {

            throw new InvalidOperationException("When AutoBind is enabled, setting the DataSource property explicitly is not allowed.");

        base.DataSource = value;

protected override void PerformSelect() {

    if (AutoBind) {

        DataBindingEventArgs args = new DataBindingEventArgs();

        OnDataRetrieving(args);

        _settingDataSource = true;

        DataSource = args.DataSource;

        _settingDataSource = false;

    base.PerformSelect();

protected override void EnsureDataBound() {

    if (RequiresDataBinding && (AutoBind || IsBoundUsingDataSourceID)) {

        DataBind();

The most interesting method is EnsureDataBound. This method is called from PreRender and the original condition for making the control DataBind is:

if (this.RequiresDataBinding && ((this.DataSourceID.Length > 0) || this._requiresBindToNull)) {

    this.DataBind();

    this._requiresBindToNull = false;

In the case of manually binding this would never be called unless _requiresBindToNull is true. Our AutoGridView control changes this logic by detecting the AutoBind flag and continues to data bind as usual in PreRender.

If you interested in when the event gets called you can put some break points in the control's code. What do you think about this alternative?

Here is a link to the source.

Client side devevelopment in ASP.NET

davidfowl — Thu, 29 Jan 2009 10:09:00 GMT

We ASP.NET developers know how much of a pain it is writing javascript in any app we have today because of naming container madness! You've probably done something like this:

function DoSomeThingCool() {

    var textBox = document.getElementById('ct100_contentplaceholder1_TextBox1');

or something not so hardcoded

function DoSomeThingCool() {

    var textBox = document.getElementById('<%= TextBox1.ClientID %>');

Matthew Osborn, QA on the ASP.NET team has a great post on a new ASP.NET 4.0 feature that gives developers more control over how ClientIDs are generated.

Follow me on twitter!

davidfowl — Sun, 25 Jan 2009 09:52:00 GMT

I've finally got sucked into twitter after avoiding it for many months. Check me out:

http://twitter.com/davidfowl/

Since my name is so common it really annoys me when I sign up for any new service because I have to get accept some partially mangled version of my name (i.e. davidfowl).

Anyways, stay tuned!

Dynamic ListView LayoutTemplate

davidfowl — Sun, 14 Dec 2008 20:34:00 GMT

There are times when you want to let the user change layout dynamically. You can use css to do this but lets look at what the ListView control offers. To get started with the ListView you need a LayoutTemplate and ItemTemplate.

<asp:ListView runat="server" ID="listView">        
    <LayoutTemplate>
        <asp:PlaceHolder runat="server" ID="itemPlaceholder"></asp:PlaceHolder>
    </LayoutTemplate>
    <ItemTemplate>
        <%# Eval("CategoryName") %>
    </ItemTemplate>
</asp:ListView>

The ListView replaces the control with ID="itemPlaceholder" with the zero or more instances of the Selected/Alternating/ItemTemplate.

There is a method on TemplateControl (LoadTemplate) which allows users to dynamically load a user control as a ITemplate. Lets use this to load our LayoutTemplate from a user control.

User Control:

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="FlowLayout.ascx.cs" Inherits="ListViewLayouts.FlowLayout" %>
 
<div id="flow">
    <asp:PlaceHolder runat="server" ID="itemPlaceholder"></asp:PlaceHolder>
</div>

Code Behind:

protected void Page_Init(object sender, EventArgs e) {
    listView.LayoutTemplate = LoadTemplate("~/ListViewLayouts/FlowLayout.ascx");
}

When we run the page we get the following exception:

An item placeholder must be specified on ListView 'listView'. Specify an item placeholder by setting a control's ID property to "itemPlaceholder". The item placeholder control must also specify runat="server".

The problem here is that user controls are naming containers and when the ListView internally tries to find the control with ID="itemPlaceholder" it fails. So what is the id of the itemPlaceholder? We'll we could start guessing that it might be something like ctl001$itemPlaceholder, but that doesn't seem like a good solution. Instead we can create our own template that will allow us to specify the ID of the user control so that the itemPlaceholderID is more predictable.

public class CustomTemplate : ITemplate {
    private string _virtualPath;
    private string _controlID;
 
    public CustomTemplate(string virtualPath, string controlID) {
        _virtualPath = virtualPath;
        _controlID = controlID;
    }
 
    public void InstantiateIn(Control container) {            
        Control control = (Control)BuildManager.CreateInstanceFromVirtualPath(_virtualPath, typeof(Control));
        control.ID = _controlID;
        container.Controls.Add(control);
    }
}

This template gives us the opportunity to specify a controlID for the user control we are going to load. Now we instantiate a new CustomTemplate and specify the control ID as well as path to the user control.

protected void Page_Load(object sender, EventArgs e) {
    listView.LayoutTemplate = new CustomTemplate("~/ListViewLayouts/FlowLayout.ascx", "flowLayout");            
}

Don't forget to set the ItemPlaceHolderID proprety on the ListView.

<asp:ListView runat="server" ID="listView" ItemPlaceholderID="flowLayout$itemPlaceholder">
        <ItemTemplate>
            <%# Eval("CategoryName") %>
        </ItemTemplate>
</asp:ListView>

Now we can load the LayoutTemplate at runtime.

AutoFieldGenerators

davidfowl — Sun, 14 Dec 2008 08:01:00 GMT

In 3.5 SP1 we added new properties to GridView and DetailsView which allows the page developer to change the way AutoGenerateColumns creates its columns. This feature is well know in Dynamic Data, but it is not tied to this technology. Dynamic Data takes advantage of this by looking at the meta data that users set on properties to generate columns.

You too can roll your own IAutoFieldGenerator. Lets look at the interface:

public interface IAutoFieldGenerator {
    ICollection GenerateFields(Control control);
}

The interface itself is pretty weird but it gets the job done. GenerateFields takes the control that we're generating the fields for, and expects to get some ICollection of stuff back. If we had the chance to redo this interface we'd probaby rewrite it to be like this:

public interface IAutoFieldGenerator {
    IEnumerable<DataControlField> GenerateFields(Control control);
}

Now it's clear what we expect to get back, but thats besides the point. Lets implement our own.

public class ColumnGenerator : IAutoFieldGenerator {
private IEnumerable<string> _columns;
public ColumnGenerator(IEnumerable<string> columns) {
    _columns = columns ?? Enumerable.Empty<string>();
}
 
public ICollection GenerateFields(Control control) {
    return (from column in _columns
            select new BoundField {
                SortExpression = column,
                HeaderText = column,
                DataField = column
            }).ToArray();
    }
}

We're going to pass a set of column names to our generator that just creates bound fields with the column's name. To make use of our new generator we can just set it like this:

GridView

gridView1.ColumnsGenerator = new ColumnGenerator(Columns);

DetailsView

detailsView1.RowsGenerator = new ColumnGenerator(Columns);

You can do alot of cool things with these generators. Some things I can think of off the top of my head:

Hide/Show columns dynamically based on metadata (like what we do with dynamic data)
Hide/Show columns based on permissions
Create a configurable UI that allows users to hide or show columns based on their preferences.

I've written a sample that allows you to hide or show columns based on a selectable UI. You can download it here:

AutoFieldGenerator.zip

Here is a screen shot of it running.

How <%# Bind %> Works

davidfowl — Sat, 13 Dec 2008 16:57:00 GMT

In my last post I spoke about 2-way databinding and how it can be used to extract values from control properties. How does this all work? Lets take a look at a page with 2-way databinding:

<asp:LinqDataSource ID="productsSource" 
    runat="server" 
    ContextTypeName="FowlerSamples.NorthwindDataContext" 
    EnableDelete="True" 
    EnableInsert="True" 
    EnableUpdate="True" TableName="Products">
</asp:LinqDataSource>        
<asp:GridView ID="products" 
    DataKeyNames="ProductID,CategoryID" 
    AutoGenerateColumns="False" 
    runat="server" DataSourceID="productsSource">
    <Columns>
        <asp:CommandField ShowEditButton="True" />                
        <asp:BoundField DataField="ProductName" />
        <asp:TemplateField>
            <EditItemTemplate>
                <asp:LinqDataSource 
                    ID="categoriesSource" 
                    runat="server" 
                    ContextTypeName="FowlerSamples.NorthwindDataContext" 
                    TableName="Categories" AutoGenerateWhereClause="true">
                </asp:LinqDataSource>
                <asp:DropDownList 
                    runat="server" 
                    ID="categories"
                    DataSourceID="categoriesSource"
                    DataTextField="CategoryName"
                    DataValueField="CategoryID"
                    SelectedValue='<%# Bind("CategoryID") %>'>                            
                </asp:DropDownList>                        
            </EditItemTemplate>                    
        </asp:TemplateField>
    </Columns>
</asp:GridView>

In the above example, the GridView has a template field with an EditItemTemplate that has a DropDownList that is 2-way databound. We're going to introduce a small error in the page in order to see what the generated code looks like:

<EditItemTemplate>
     <asp:LinqDataSource 
         ID="categoriesSource" 
         runat="server" 
         ContextTypeName="FowlerSamples.NorthwindDataContext" 
         TableName="Categories" AutoGenerateWhereClause="true">
     </asp:LinqDataSource>
     <asp:DropDownList 
        runat="server" 
        ID="categories"
        DataSourceID="categoriesSource"
        DataTextField="CategoryName"
        DataValueField="CategoryID"
        SelectedValue='<%# Bind("CategoryID") %>'>                            
    </asp:DropDownList>
    <%# Eval(3) %>
</EditItemTemplate>

When we try to run this page we'll get a compile error and the famous ASP.NET YSOD(Yellow Screen of Death):

Click on Show Complete Compilation Source, if your curious about how ASP.NET converts your the markup to code.

When examining the source, we see a rather interesting method:

[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public System.Collections.Specialized.IOrderedDictionary @__ExtractValues__control8(System.Web.UI.Control @__container) {
    System.Collections.Specialized.OrderedDictionary @__table;
    System.Web.UI.WebControls.DropDownList categories;
 
    categories = ((System.Web.UI.WebControls.DropDownList)(@__container.FindControl("categories")));
 
    @__table = new System.Collections.Specialized.OrderedDictionary();
 
    if ((categories != null)) {
        @__table["CategoryID"] = categories.SelectedValue;
    }
 
    return @__table;
}

As you can see in the above method, an OrderedDictionary is created and the SelectedValue property of the DropDownList is pushed into the "CategoryID" field. But how does this get all the way to the data control? Each control has a BuildControl method associated with it, if we examine the BuildControl method for the TemplateField it becomes a bit more clear how things get hooked up.

[System.Diagnostics.DebuggerNonUserCodeAttribute()] 
private global::System.Web.UI.WebControls.TemplateField @__BuildControl__control7() {
    global::System.Web.UI.WebControls.TemplateField @__ctrl;
 
    @__ctrl = new global::System.Web.UI.WebControls.TemplateField();
 
    @__ctrl.EditItemTemplate = new System.Web.UI.CompiledBindableTemplateBuilder(new System.Web.UI.BuildTemplateMethod(this.@__BuildControl__control8), new System.Web.UI.ExtractTemplateValuesMethod(this.@__ExtractValues__control8));
 
    return @__ctrl;
}

The EditItemTemplate property is of type ITemplate. CompiledBindableTemplate implements both ITemplate and IBindableTempalte.

public interface IBindableTemplate : ITemplate {            
    IOrderedDictionary ExtractValues(Control container);
}

It's slowly coming together. So lets put together what we're learnt so far:

Code Gen creates ExtractValues method that returns the dictionary of values for each ITemplate that has a Bind expression.
The BuildControl method for the ITemplate's container (TemplateField in this case) assigns a new CompiledBindableTemplate to an ITemplate (EditItemTemplate in this case)
CompiledBindableTemplate implements IBindableTemplate, which has a method, ExtractValues which returns the dictionary given a container.

It almost all makes sense now. Each data control uses this mechanism to extract values from template fields with 2-way databinding expressions.
What can you do with your new found knowledge?

<asp:FormView 
    runat="server" 
    ID="formView" 
    DefaultMode="Edit">
    <EditItemTemplate>
        <asp:TextBox ID="textBox" runat="server" Text='<%# Bind("Name") %>'></asp:TextBox>
        <asp:TextBox ID="textBox1" runat="server" Text='<%# Bind("Age") %>'></asp:TextBox>
        <asp:Button runat="server" ID="updateButton" CommandName="Update" Text="Update" />
    </EditItemTemplate>
</asp:FormView>

And the code behind:

class Person {
    public string Name { get; set; }
    public int Age { get; set; }
}
 
protected void Page_Load() {
    formView.ItemUpdating += formView_ItemUpdating;
    if (!IsPostBack) {
        formView.DataSource = new Person[] { new Person { Name = "David", Age = 22 } };
        formView.DataBind();
    }
}
 
protected void formView_ItemUpdating(object sender, FormViewUpdateEventArgs e) {
    IBindableTemplate template = formView.EditItemTemplate as IBindableTemplate;
    if (template != null) {
        IOrderedDictionary values = template.ExtractValues(formView);
        Response.Write(values["Name"]);
        Response.Write(values["Age"]);
    }
}

How cool is that? :)

Getting your data out of the data controls

davidfowl — Fri, 12 Dec 2008 23:03:00 GMT

After you've created a layout with a data control of your choice and eventually bound them to some datasource, you almost always want to get that data back out of them(and why wouldn't you, its your data). One thing you'll learn about developing asp.net webpages is that its like petting a porcupine (yikes). If you go with the flow, you probably won't get stuck, but the moment you try to go against the grain you end up with a hand full of thorns.

Most of the data controls have events ending in ing and ed e.g. RowUpdating, RowUpdated etc. In most of the event handlers of the ing events it is easy to get the values from the event args.

private void OnGridViewRowUpdating(object sender, GridViewUpdateEventArgs e) {
    IDictionary keys = e.Keys;
    IDictionary newValues = e.NewValues;
    IDictionary oldValues = e.OldValues;
}

Forgive me for the variation in my code formatting I'm trying to find the right one.

If we look at this event we can see the GridView nicely packages for us the new values, old values and the keys for the updating row. Unfortunately these dictionaries are only filled out if you are bound to a datasource control :(. So that means when you bind to some raw collection and hook up to the DataSource property then call databind, if you try to handle the delete or update events these dictionaries are going to be empty. Right now you must be asking yourself how can you get those dictionaries filled out just as if you were bound to a Datasource control? The good news is you CAN do it(this is what this blog post is all about right?).

Going Hunting in the Control Tree

This is probably one of the worst things you can do. From the time you write code that depends on the immediate layout of your page then your asking for trouble. I often see people on the forums writing code like this:

((TextBox)GridView1.Rows[e.RowIndex].Cells[2].Controls[1]).Text

Seeing stuff like that makes my spine tingle (and not in a good way). DO NOT write code like this!

FindControl
FindControl is a very powerful method on Control that allows you to search for a nested control, NOT synonymous to DOM function getElementById. I Often see people abusing find control and not understand that it is NOT recursive by default and complain when code like this

((TextBox)GridView1.FindControl("TextBox1")).Text

Throws a null reference exception. My advice is use Use FindControl as a last resort.

2-way DataBinding
2-way Databinding is a cool feature in ASP.NET 2.0 which allows the user to write some special syntax to bind against property values they would like to extract from a control.
There is alot of magic going on behind the scenes (which I will blog about in a separate post), but you do not need to know how it works to use it, e.g

<asp:GridView runat="server" ID="GridView1">
    <Columns>
        <asp:TemplateField>
            <EditItemTemplate>
                <asp:TextBox ID="TextBox1" runat="server" Text='<%# Bind("ProductName") %>'></asp:TextBox>
            </EditItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

When you write the <%# Bind("ProductName") #> expression then the value of the Text property is pushed into a dictionary which the data control can retrieve later. So how does GridView/FormView/DetailsView/ListView get these values? Each data control has a method which is responsible for populating a dictionary of name value pairs from field name to value. Here is a mapping of data control to method used to extract values:

GridView => protected ExtractRowValues
FormView => protected ExtractRowValues
DetailsView = > protected ExtractRowValues
ListView => public ExtractItemValues

As we can see with the exception of ListView these oh so useful methods are protected, that means we can't call them from our code if we are using these built in controls. What can we do to surface these methods:

Derive new controls that expose ExtractRowValues through a public method
Use private reflection to call the protected method (yikes)
Stick all of your interesting fields in DataKeyNames, then use the DataKeys[rowIndex].Values[fieldName] (and watch your ViewState grow :( )
Do Nothing :)

To rectify some of this I've written a little helper for the GridView (and the other controls if you demand) that basically duplicates the functionality of ExtractRowValues method.

public static IDictionary GetValues(GridViewRow row) {            
    IOrderedDictionary values = new OrderedDictionary();
    foreach (DataControlFieldCell cell in row.Cells) {
        if (cell.Visible) {
            // Extract values from the cell
            cell.ContainingField.ExtractValuesFromCell(values, cell, row.RowState, true);
        }
    }
 
    return values;
} 

The method itself is pretty simple. It iterates over the control collection of the GridViewRow and calls ExtractValuesFromCell on each cell which puts values into the dictionary.

Uses
Most data controls support writing custom commands and handling some Command event(RowCommand for GridView). This method would come in handy if you needed to get the values out of the GridView for some custom command you wanted to execute.

If you can, use 2 way databinding, if your control doesn't have a useful property to bind against and you need to do some more logic to get the right value then use FindControl.

Edit:
I've updated the code to loop over the Cells collection instead of the Controls collection (which is alot cleaner). Also there is no real compelling reason to return a strongly typed IDictionary<string, object>, so I just return the IDictionary instead.

DetailsView:

Reader daveh551 needed some help adapting the code to DetailsView so here it is:

public static IDictionary GetValues(DetailsView detailsView) {

    IOrderedDictionary values = new OrderedDictionary();

    foreach (DetailsViewRow row in detailsView.Rows) {

        // Only look at Data Rows

        if (row.RowType != DataControlRowType.DataRow) {

            continue;

        // Assume the first cell is a header cell

        DataControlFieldCell dataCell = (DataControlFieldCell)row.Cells[0];

        // If we are showing the header for this row then the data is in the adjacent cell

        if (dataCell.ContainingField.ShowHeader) {

            dataCell = (DataControlFieldCell)row.Cells[1];

        dataCell.ContainingField.ExtractValuesFromCell(values, dataCell, row.RowState, true);

    return values;

FormView:

public static IDictionary GetValues(FormView formView) {

    IOrderedDictionary fieldValues = new OrderedDictionary();

    ExtractValuesFromBindableControls(fieldValues, formView);

    IBindableTemplate itemTemplate = null;

    if (formView.CurrentMode == FormViewMode.ReadOnly && formView.ItemTemplate != null) {

        itemTemplate = formView.ItemTemplate as IBindableTemplate;

    else if (formView.CurrentMode == FormViewMode.Edit && formView.EditItemTemplate != null) {

        itemTemplate = formView.EditItemTemplate as IBindableTemplate;

    else if (formView.CurrentMode == FormViewMode.Insert && formView.InsertItemTemplate != null) {

        itemTemplate = formView.InsertItemTemplate as IBindableTemplate;

    if (itemTemplate != null) {

        foreach (DictionaryEntry entry in itemTemplate.ExtractValues(formView)) {

            fieldValues[entry.Key] = entry.Value;

    return fieldValues;

private static void ExtractValuesFromBindableControls(IOrderedDictionary values, Control container) {

    IBindableControl control = container as IBindableControl;

    if (control != null) {

        control.ExtractValues(values);

    foreach (Control childControl in container.Controls) {

        ExtractValuesFromBindableControls(values, childControl);

Let me know if you find any bugs.
Hope this helps

UPDATE: I've had some requests to add more data controls and to convert the code to VB etc. So I decided to instead put the code in an assembly and make available for download here.

Dynamic Sorting with Linq

davidfowl — Thu, 11 Dec 2008 13:26:00 GMT

When trying to implement a Business Logic Layer (i will refer to this as BLL) with linq one thing that is an annoyance is sorting. Lets say you had a BLL that was being used by ObjectDataSource and had a select method that does sorting and paging, then you'd probably be tempted to write something like this:


private IQueryable<Product> SortBy(IQueryable<Product> source, string sortBy) {
    int desc = sortBy.IndexOf("DESC");
    bool isDescending = desc >= 0;
    if (isDescending) {
        sortBy = sortBy.Substring(0, desc).Trim();
    }
    switch (sortBy) {
        case "ProductName":
            if (isDescending) {
                return source.OrderByDescending(p => p.ProductName);
            }
            source = source.OrderBy(p => p.ProductName);
            break;
        case "UnitPrice":
            if (isDescending) {
                 return source.OrderByDescending(p => p.UnitPrice);
            }
            source = source.OrderBy(p => p.UnitPrice);
            break;

         ..... One for every property
    }
    return source;
}

But that can be really tedious and you probably have more than one object. Would you want to duplicate that for Categories, Suppliers, etc? I don't think so. Linq takes
advantage of another C# 3.0 feature called Expression Trees and we can take advantage of these in our code to build a dynamic sort expression for any object.

The code:
So how do we do this? I'm not going to explain how expression trees work in this blog post but there are plenty of resources out there that you can take a look at if your interested.
The method is an extension method on IQueryable<T> that takes the IQuerable<T> source and the sort parameter which should be the property name that you would like to sort by. In the case of DataSources like ObjectDataSource, the sort parameter will contain "DESC' if the sort direction is descending. Here is the code:

public static class QueryExtensions {
    public static IQueryable<T> SortBy<T>(this IQueryable<T> source, string propertyName) {
        if (source == null) {
            throw new ArgumentNullException("source");
        }
        // DataSource control passes the sort parameter with a direction
        // if the direction is descending           
        int descIndex = propertyName.IndexOf(" DESC");
        if (descIndex >= 0) {
            propertyName = propertyName.Substring(0, descIndex).Trim();
        }
 
        if (String.IsNullOrEmpty(propertyName)) {
            return source;
        }
 
        ParameterExpression parameter = Expression.Parameter(source.ElementType, String.Empty);
        MemberExpression property = Expression.Property(parameter, propertyName);
        LambdaExpression lambda = Expression.Lambda(property, parameter);
 
        string methodName = (descIndex < 0) ? "OrderBy" : "OrderByDescending";
 
        Expression methodCallExpression = Expression.Call(typeof(Queryable), methodName,
                                            new Type[] { source.ElementType, property.Type },
                                            source.Expression, Expression.Quote(lambda));
 
        return source.Provider.CreateQuery<T>(methodCallExpression);
    }
}

And a link to the file.

QueryExtensions.cs

Hope this helps

DataControls 101 Part 2: Why you should love Datasource controls

davidfowl — Tue, 21 Oct 2008 09:41:00 GMT

I've been scouring the forums recently trying to find problems people encounter when using the data controls. One thing that I found is mostly asked for but is kind of a hidden art:
How do I use the GridView/ListView/DetailsView.... without a Datasource control? (and still get all the fancy features offered).

Now I've always know that you can do this but I decided to explore how much is involved in making this stuff to work. This sample shows a GridView using raw Linq queries in C#. Let’s dive into the code:

Markup

<asp:GridView 
    DataKeyNames="ProductID" 
    ID="products" runat="server" 
    AllowPaging="True"
    AllowSorting="True" 
    CellPadding="4" 
    ForeColor="#333333" 
    GridLines="None">
    <RowStyle BackColor="#F7F6F3" ForeColor="#333333" />
    <Columns>
        <asp:CommandField 
            ShowDeleteButton="True" 
            ShowEditButton="True" 
            ShowSelectButton="True" />
    </Columns>
    <FooterStyle BackColor="#5D7B9D" Font-Bold="True" ForeColor="White" />
    <PagerStyle BackColor="#284775" ForeColor="White" HorizontalAlign="Center" />
    <SelectedRowStyle BackColor="#E2DED6" Font-Bold="True" ForeColor="#333333" />
    <HeaderStyle BackColor="#5D7B9D" Font-Bold="True" ForeColor="White" />
    <EditRowStyle BackColor="#999999" />
    <AlternatingRowStyle BackColor="White" ForeColor="#284775" />
</asp:GridView>

Code behind

protected void Page_Load(object sender, EventArgs e) {
    // Setup Events
    products.RowEditing += new GridViewEditEventHandler(OnProductsRowEditing);
    products.RowUpdating += new GridViewUpdateEventHandler(OnProductsRowUpdating);
    products.RowCancelingEdit += new GridViewCancelEditEventHandler(OnProductsRowCancelingEdit);
    products.RowDeleting += new GridViewDeleteEventHandler(OnProductsRowDeleting);
    products.Sorting += new GridViewSortEventHandler(OnProductsSorting);
    products.PageIndexChanging += new GridViewPageEventHandler(OnProductsPageIndexChanging);
 
    if (!IsPostBack) {
        DataBindProducts();
    }
}
 
private void DataBindProducts() {
    using (NorthwindDataContext db = new NorthwindDataContext()) {
        products.DataSource = db.Products;
        products.DataBind();
    }
}

The code above can be done in the markup but I chose to do it in the code behind. The code in Page_Load is very basic and self explanatory.

Editing

private void OnProductsRowEditing(object sender, GridViewEditEventArgs e) {
    // Set EditIndex
    products.EditIndex = e.NewEditIndex;
    DataBindProducts();
}

The Edit event handler is pretty simple and straight forward. We set the new edit index and Databind the grid.

Paging

privatevoid OnProductsPageIndexChanging(object sender, GridViewPageEventArgs e) { 
    products.EditIndex = -1;
    products.PageIndex = e.NewPageIndex;
 
   DataBindProducts();
}

Paging code is similar to editing; we just set the new page index and reset the edit index to -1.

Cancel

privatevoid OnProductsRowCancelingEdit(object sender, GridViewCancelEditEventArgs e) { 
    // Reset the edit index
    products.EditIndex = -1;
    DataBindProducts();
}

Now the hard stuff...

Sorting

privatevoid OnProductsSorting(object sender, GridViewSortEventArgs e) { 
    products.EditIndex = -1;
    products.PageIndex = 0;
 
    if ((SortExpression == e.SortExpression) && (SortDirection == SortDirection.Ascending)) {
        e.SortDirection = SortDirection.Descending;
    }
 
    using (NorthwindDataContext db = new NorthwindDataContext()) {
        products.DataSource = QueryableExtensions.SortBy(db.Products, e.SortExpression, e.SortDirection);
        products.DataBind();
    }
 
    SortExpression = e.SortExpression;
    SortDirection = e.SortDirection;
}

Woah! What’s going on here? When you examine the event arguments of the sorting event you will realize that the SortExpression changes but the SortDirection is always Ascending... This seems very weird, because the GridView keeps track of the sorting state (SortExpression and SortDirection). The problem is this state is only updated when the GridView is bound to a Datasource control :(. Why did we make that decision I’m not sure, but it is what it is so we must keep track of this ourselves.

public string SortExpression {
    get {
        return (string)ViewState["SortExpression"] ?? String.Empty;
    }
    set {
        ViewState["SortExpression"] = value;
    }
}
 
public SortDirection SortDirection {
    get {
        object o = ViewState["SortDirection"];
        return o != null ? (SortDirection)o : SortDirection.Ascending;
    }
    set {
        ViewState["SortDirection"] = value;
    }
}

We store the current SortExpression and SortDirection in the viewstate (GridView keeps it in control state). Then we do the obvious logic to change the sort direction appropriately.
The rest of the sort method just uses my helper to convert SortExpression and SortDirection to a Linq expression.

Updating/Deleting

private void OnProductsRowUpdating(object sender, GridViewUpdateEventArgs e) {
    GridViewRow row = products.Rows[e.RowIndex];
 
    IOrderedDictionary values = new OrderedDictionary(StringComparer.OrdinalIgnoreCase);
    DictionaryHelper.ExtractRowValues(products, values, row, true /* includeReadOnlyFields */, true /* includePrimaryKey */);
 
    // Update the product
    QueryableExtensions.UpdateProduct(values);
 
    products.EditIndex = -1;
    DataBindProducts();
}
 
private void OnProductsRowDeleting(object sender, GridViewDeleteEventArgs e) {
    GridViewRow row = products.Rows[e.RowIndex];
 
    IOrderedDictionary values = new OrderedDictionary(StringComparer.OrdinalIgnoreCase);
    DictionaryHelper.ExtractRowValues(products, values, row, true /* includeReadOnlyFields */, true /* includePrimaryKey */);
 
    // Delete the product
    QueryableExtensions.DeleteProduct(values);
 
    products.EditIndex = -1;
    DataBindProducts();
}

These 2 methods are pretty similar in nature.First thing you may realize when examining the EventArgs in these methods are that all the dictionaries are empty! (again, another weird design choice) There is some logic in the Databound controls that detects if it is bound to a Datasource control or Datasource. In the case of the GridView, it calls ExtractRowValues to fill the dictionaries for update/delete if it is bound to a Datasource control. Since this function is protected the only other way to get the values from the row is to use find control and manually extract the data yourself, which can be a mess. I used private reflection in my sample to call the function and fill the dictionary (yes it's a little hacky :)).

Other random other pieces of code:

The calls to QueryableDataSourceHelper.SortBy, QueryableDataSourceHelper.UpdateProduct, QueryableDataSourceHelper.DeleteProduct, can be seen as specific implementations of a Datasource control’s ExecuteDelete, ExecuteInsert, and ExecuteSelect (sorting handled here) methods.

What your Datasource does for you:

CRUD operations for a specific technology (SQL/XML/objects)
Sorting and paging
Conversion of values from controls/querystring/session…etc through parameters.

If you look at my previous post and the amount of code I wrote to get it working compared to the above is mind boggling.

DON'T TAKE YOUR DATASOURCE FOR GRANTED.

Here is a link to the sample solution.

Data Controls 101

davidfowl — Tue, 14 Oct 2008 09:46:00 GMT

I’ve worked with asp.net a bit at school before I came to Microsoft. Being the “data dev” as you would imagine, I get lots of bugs that have to do with the data (datasource/databound) controls. I also scan the internal and external forums and try to help customers find solutions to their problems. This blog post is the first of a series on common scenarios using data controls, that I call Data Controls 101.

When new developers come to asp.net from other web technologies/backgrounds the tendency is to continue doing things as they did before, when in fact they should learn the paradigms we expect in asp.net webforms (mvc is kind of different).

These posts will be scenario driven with tidbits of information here and there. Let’s start with a simplest case:

I want to show a list of categories from my database.

Before you pick a control and rush to go write code, you should ask other questions that will help narrow the choices down. Do I want to delete, update, insert, select? Do I want to define my control template manually or use column auto generation? After you decide what set of functionality you want there is still probably a bunch combinations of controls you want choose to accomplish your goal.

Controls	Select	Delete	Inline Edit	Insert	Paging	Sorting	Column Autogeneration
GridView	x	x	x	-	x	x	x
ListView	x	x	x	x	x (DataPager)	x	-
Repeater	-	-	-	-	-	-	-
DetailsView	-	x	x	x	x	-	x
FormView	-	x	x	x	x	-	-
DataList	x	x	x	-	-	-	-

The above table is a summary of what those controls on the left support out of the box without much added effort (some other controls can do the same thing with a little more work).

Ok so we’ve decided to we want a tabular layout, paging, sorting and selection with inline editing. Looking at the table I’d pick the GridView or ListView.

Next goal is to choose the datasource control. The same kinds of questions apply when picking the datasource control, but it is more specific to how you want to access your data. In my case I’ll use LinqDataSource.

Finally the code:

<asp:LinqDataSource ID="categoriesSource" 
    EnableUpdate="true" 
    runat="server" 
    ContextTypeName="FowlerSample.NorthwindDataContext" 
    TableName="Categories">
</asp:LinqDataSource>        
 
<asp:GridView ID="categories" 
    runat="server" 
    AllowPaging="True" 
    AllowSorting="True" 
    DataKeyNames="CategoryID" 
    DataSourceID="categoriesSource">
    <Columns>
        <asp:CommandField ShowSelectButton="True" ShowEditButton="true" />
    </Columns>
</asp:GridView>

That’s all you have to write and suddenly things just work. Next time I'll go over some of how the “magic” works.

First Post

davidfowl — Tue, 07 Oct 2008 04:22:00 GMT

Hey everyone, my name is David Fowler and I'm new to the ASP.NET team. I've been an intern here in Redmond for the last 2 summers and I’m glad to be back as a FTE (Full Time Employee in microspeak). My responsibilities include all things data related to ASP.NET. This includes things like the Datasource and Databound controls as well as Dynamic Data. I look forward to posting some interesting stuff in the near future!