Part 2 : Building and binding hierarchical data from the database to the ASP.NET Navigation Controls

I wrote about how we can make use of some of the databinding capabilities of controls, that can bind to hierarchical data like the TreeView around last week. While I covered pretty much everything, the data i was binding to was not deeply nested. Instead the data we were consuming was just 3 levels deep and that was that.

Today, we will be binding to a hierarchical datasource whose nesting structure is not known and can go as deep as it wants. Here, also SQL servers XML capabilities seem to come short since it does not support recursions. so if our data had this kind of deep nesting, SQL Servers FOR XML queries are not helping out much and we'd need to combine XSLT to our FOR XML Query.

Because of that, and since we end up using XSL for the transformation anyway, i'm going to be using the Dataset/XSLT approach I discussed in my previous post.

First, lets create a "pages" table in Sql server with the following schema as you can see in the screen shot below :

As you can note from above, we have a parentId field which is a self related field, related to the pageId in the same table. I personally prefer to move this field out to a junction table but each approach has it's pro's and con's, and this is simpler and serves our purpose :-)

Now, let's fill it with sample data, as you can note in the screenshot below :

ohh perfect. Now it's time to put together some c# code :

protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
XmlDataSource1.Data = GetHierarchicalData();
}
string GetHierarchicalData()
{
string queryString =
"SELECT pageId, pageDisplayName, parentId FROM pages;";
DataSet ds = new DataSet("Pages");
string connectionString = ConfigurationManager.
ConnectionStrings["LocalSqlServer"].ConnectionString;
using (SqlConnection connection = new SqlConnection(
connectionString))
{
SqlDataAdapter adapter = new SqlDataAdapter();
adapter.SelectCommand = new SqlCommand(
queryString, connection);
adapter.Fill(ds);

ds.Tables[0].TableName = "PageItem";
// relate our tables
DataRelation dr = new DataRelation("FK_pageId_parentId", 
ds.Tables["PageItem"].Columns["pageId"],
ds.Tables["PageItem"].Columns["parentId"]);
// we'd like the page items nested within 
// each node for every child page.
dr.Nested = true;
ds.Relations.Add(dr);
}
return ds.GetXml();
}

The xml returned by our dataset looks like this : Dataset generated XML

Notice how every pageId that had a corresponding parentId was nested within it's parent, forming a hiearchical set of data. This is just perfect, all thanks to the dataset's DataRelation capabilities and our setting Nested=true on the DataRelation. This kind of recusive nesting didn't seem supported by SQL Servers FOR XML queries, and if it was, then it's probably trival. I did find a few implicit hints in the documentation that recursive nesting was not supported on SQL Server FOR XML Queries, however i could be wrong (so please do your homework).

Now our XSL file that does the recursion, but it's easier to make the transformation now, because the data is already structured out nicely with the proper hierarchical structure. Only thing missing and why we need to perform transformation is as i explained in the previous post, we need the fields as attributes and not as xml elements. So here is our recursive xslt that does just that :

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml"/>
<xsl:template name="Menu" match="/">
<xsl:element name="Pages">
<xsl:for-each select="Pages/PageItem">
<xsl:variable name="parentId" select="parentId/text()"/>

<xsl:element name="PageItem">
<xsl:attribute name="pageId">
<xsl:value-of select="pageId/text()" />
</xsl:attribute>
<xsl:attribute name="pageDisplayName">
<xsl:value-of select="pageDisplayName/text()" />
</xsl:attribute>

<xsl:call-template name="processChildren" />

</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
<!-- recursive template -->
<xsl:template name="processChildren">
<xsl:for-each select="PageItem">
<xsl:element name="PageItem">
<xsl:attribute name="pageId">
<xsl:value-of select="pageId/text()" />
</xsl:attribute>
<xsl:attribute name="pageDisplayName">
<xsl:value-of select="pageDisplayName/text()" />
</xsl:attribute>
<xsl:call-template name="processChildren" />
</xsl:element>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

And here is the output of this miraculous transformation : XSL Transformed XML

Ohhh what beauty :-) and to complete, here is the declarative code to bind our asp.net menu to the XmlDataSource control that consumes this data :

<form id="form1" runat="server">
<div>
<asp:Menu ID="Menu1" MaximumDynamicDisplayLevels="1000" 
Orientation="Horizontal"
DataSourceID="XmlDataSource1" runat="server">
<DataBindings>
<asp:MenuItemBinding DataMember="PageItem" 
TextField="pageDisplayName" ValueField="pageId" />
</DataBindings>
</asp:Menu>
<asp:XmlDataSource ID="XmlDataSource1" XPath="Pages/PageItem"
TransformFile="~/MenuTransform.xsl" runat="server"></asp:XmlDataSource>
</div>
</form>

One gotcha you want to watch out for is the root node showing in the menu. Since we do not want to show the starting node, we explain this to the XmlDataSource nicely by setting an XPath expression : XPath="Pages/PageItem".

And below is our menu, when previewed in the browser. Time to congratulate ourselves on a job well done :-)

Update 21 May 2008

A note i forgot to mention is that the XmlDataSource control has caching turned on by default. So in case you made a change in your xslt file and didn't see the change occuring, then you know it's using a cached copy. So make sure you disable caching during development.

Building and binding hierarchical data from the database to the ASP.NET Navigation Controls

If we need to bind our navigations controls to hierarchical data we define manually ourselves in an xml file, this is easy as pie. However, things can get rather complicated or not so obvious when we need to generate this data from a database. First off, what can we use that is already provided to us for binding hierarchical data to our navigation controls in ASP.NET ?

The already out of the box approach and ideal solution is to use the XmlDataSource control. This is quite a flexible datasource control since it not only enables us to define the path to our xml file containing the structure we need but also it allows us to define xml data to it via it's "Data" property. As you may have already guessed, because our data is going to be retrieved from our database, this is the property we shall be using :-)

But first let's look at a sample data structure we may have in our database. I'm using the classic Northwind database. Let's imagine we want to display products grouped by category. So in short, for every category node, we want to show products under it. Following is a screenshot of the categories and products table and how they relate :

The most common thing i see done is to manually loop through the records returned, create TreeNodes again manually and keep adding till you've build the TreeView or Menu, etc. Nothing wrong with this approach, since it works, however it is quite lengthy in code and time consuming too.

But that's not the main reason why I'm writing this article. The main reason is that all these navigation controls in ASP.NET know how to consume hierarchical data. Once they have this, they know how to render themselves without you needing to do anything special. This is indeed some powerful databinding support that we miss out on when we go the manual approach. Here i am going to list two different approaches :

1) DataSet and XSL Transformations, which while being clean and gives a more declarative model to work with (XSLT) versus the manual c# code approach.

2)The second approach uses SqlServer's XML generating capabilities which allows us to skip XSLT and the dataset all together.

DataSet and XSL Transformation approach:

Note below how our select statements retrieves all categories, while the second statement retrieves all products. We then relate both these tables using a key field they have in common "CategoryID". We also use a dataset since it's providing us a lot of functionality like relating the tables after data retrieval and representing the data in xml.

string GetHierarchicalData()
{
string queryString =
"SELECT CategoryID, CategoryName, Description FROM Categories AS Category;";
queryString +=
"SELECT ProductID, CategoryID, ProductName FROM Products AS Product";
DataSet ds = new DataSet("TreeView");
string connectionString = ConfigurationManager
.ConnectionStrings["LocalSqlServer"].ConnectionString;
using (SqlConnection connection = new SqlConnection(
connectionString))
{
SqlDataAdapter adapter = new SqlDataAdapter();
adapter.SelectCommand = new SqlCommand(
queryString, connection);
adapter.Fill(ds);

ds.Tables[0].TableName = "Category";
ds.Tables[1].TableName = "Product";
// relate our tables
DataRelation dr = new DataRelation("FK_Products_Categories",
ds.Tables["Category"].Columns["categoryId"],
ds.Tables["Product"].Columns["categoryId"]);
// we'd like the products nested within 
// each Category Node. Thank you :-)
dr.Nested = true;
ds.Relations.Add(dr);
}
return ds.GetXml();
}

A small sample output of the generated xml we get by calling dataset's GetXml() method is here ->  DataSet Generated XML

As you can see, we have our rootnode "TreeView", then a childNode "Category", which in turn will contain every product node within it that belongs to this category. This nesting was established when we created a relationship btw the Categories table and the Products table using a DataRelation, where we set Nested = true; on it. Enabling the Nested property did just what the name says. It nested all our products within it's specific Category node.

While this is great, it does not help much with the TreeView control. Notice how every field our select statement returned is now an xml node and the data for the field is contained as inner text in our node. The TreeNodeBinding instead expects the fields to be contained as attributes, and the data as attribute values. Following screenshot is what we get when we run our TreeView bound to XmlDatasource

Definately, not what we are after. This is because the datasets GetXml method returned :

<Category>
<CategoryID>1</CategoryID>
<CategoryName>Beverages</CategoryName>
<Description>Soft drinks, coffees, teas, beers, and ales</Description>

while, what we need instead for the TreeNodeBinding to work is :

<Category CategoryID="1" CategoryName="Beverages" 

     Description="Soft drinks, coffees, teas, beers, and ales">

Had we the above xml structure with the fields defined as attributes we could easily create a TreeNodeBinding like this :

<asp:TreeNodeBinding Depth="2" DataMember="Category" 

  TextField="CategoryName" ValueField="CategoryID" ToolTipField="Description" />

So, our next task is to transform our xml to represent fields as attributes and their data as attribute values. We can accomplish this easily using XSL Transformations. By defining some instructions in our XSL file, we can read our XML(what our dataset GetXml method output) and transform it into what the Navigation Controls expect, outputting a totally new XML document.

<?xml version="1.0" encoding="utf-8"?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml"/>
<xsl:template match="/">
<xsl:element name="TreeView">
<xsl:for-each select="TreeView/Category">
<xsl:element name="Category">
<xsl:attribute name="id">
<xsl:value-of select="CategoryID/text()" />
</xsl:attribute>
<xsl:attribute name="name">
<xsl:value-of select="CategoryName/text()" />
</xsl:attribute>
<xsl:attribute name="description">
<xsl:value-of select="Description/text()" />
</xsl:attribute>
<xsl:for-each select="Product">
<xsl:element name="Product">
<xsl:attribute name="id">
<xsl:value-of select="ProductID/text()" />
</xsl:attribute>
<xsl:attribute name="name">
<xsl:value-of select="ProductName/text()" />
</xsl:attribute>
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
</xsl:transform>

As you can see from the above XSL, we have defined two for-each loops, one that loops through category nodes and the other that loops through product nodes. Very simple but powerful stuff indeed.
The output xml after this transformation is XSL Transformed Xml output

<TreeView>
<Category>
<CategoryName name="" id="" description="" />
<Product name="" id="" />
...
</Category>
...
</TreeView>

ohh this is perfect. It was fun using XSL for the transmformation. Now, now, while it was fun, it can be a big pain in the behind if I'd have to do this all over again and again (Fortunately, i don't. Atleast now right now) :P

So, can we have made this job easier ? Surely. SQL Server and FOR XML Queries to the rescue

SQL Server and FOR XML Queries approach :

Now, what if, instead of having to do all this manual labor, we could get SQL Server to do all the xml generation for us, the way we wanted it ? Very much possible indeed. In effect this does not even need any explainations. Code speaks a thousand words, so here it is, the same xml output but this time we didn't use XSLT, nor did we use a dataset and the code is even more minimized.

string GetHierarchicalDataFromSqlServer()
{
string xml = string.Empty;
string queryString = @"
SELECT Category.categoryName as [name], Category.categoryId as id, 
Category.description as description, 
Product.productName as name, Product.productId as id
FROM categories AS Category 
INNER JOIN products AS Product
ON Category.categoryId = Product.categoryId
ORDER BY Category.categoryId                    
FOR XML Auto, ROOT('TreeView')";

string connectionString = ConfigurationManager.
ConnectionStrings["LocalSqlServer"].ConnectionString;

using (SqlConnection connection = new SqlConnection(
connectionString))
{
SqlCommand SelectCommand = new SqlCommand(
queryString, connection);
connection.Open();
XmlReader xr = SelectCommand.ExecuteXmlReader();
xr.MoveToContent();// move to the root node
xml = xr.ReadOuterXml();
}
return xml;
}

The c# code to pass the XML data to our XmlDataSource bound to a treeView :

protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
XmlDataSource1.Data = GetHierarchicalDataFromSqlServer();
}

That's it. No fuss, SQL Server's xml generation capabilities are just outstanding. And here is the declarative code i used to bind this hiearchical data to a treeview :

<form id="form1" runat="server">
<div>
<asp:TreeView ID="TreeView1" DataSourceID="XmlDataSource1" 

                 runat="server">
<DataBindings>
<asp:TreeNodeBinding Depth="1" DataMember="Category" 
TextField="name" ValueField="id" 

                                  ToolTipField="Description" />
<asp:TreeNodeBinding Depth="2" DataMember="Product" 
TextField="name" ValueField="id" />
</DataBindings>
</asp:TreeView>
</div>
<asp:XmlDataSource ID="XmlDataSource1" 

                  runat="server"></asp:XmlDataSource>
</form>

And here below is a screenshot of the treeview rendering itself. Fantastic!

Update 21 May 2008

A note i forgot to mention is that the XmlDataSource control has caching turned on by default. So in case you made a change in your xslt file and didn't see the change occuring, then you know it's using a cached copy. So make sure you disable caching during development.

Customizing the ChangePassword control and removing the required CurrentPassword field

It's very rare that what is already provided in asp.net under the Login controls fits my requirements out of the box without some tweaking. Not that any of these controls offer anything specialized, but certainly they are a big time saver if we can re-utilize their functionality.

First some background as to why i personally want to customize the ChangePassword control to suit my needs :

Password recovery is what i was after today, however i have hashed passwords, and recovery is impossible. If the user lost their password, then there is no way for me to know what their password is and send it back in clear text.

The ideal solution is to reset the password, however the autogenerated password is quite ugly and quite hard to remember. What I've decided to do is send the email during password recovery, but as part of the email, instead of telling the user their old password(which i can't).

I'm instead going to ask them to click on a tokenized link that will guarantee to me that they are indeed the ones that requested the password, send them to the page where they can provide a new password, in the background i'd be autogenerating a password first ofcourse, then updating the password with their new password because the MembershipUser.ChangePassword(oldPassword, newPassword) method requires Old password as one of it's two parameters.

This password change step, i'd like to be done using the ChangePassword control, however to my big surprise CurrentPassword Field is a required field that i cannot remove. This is also a field that I do not want asked for during the password change request(since my user has forgotten their password and are now going to provide their new pasword).

There is ofcourse no property or method in this control that removes the CurrentPassword field requirement, below is a screenshot of the ChangePassword control in designview, as you can note, the highlighted field is the CurrentPassword field i do not want.

I've done a quick look on google and in the asp.net/forums and didn't find anybody providing any proper solutions either, mostly vague replies : http://forums.asp.net/p/1189347/2038354.aspx

As you can read from the posts there, the issue seems to be two things which were also my same issues :
1) Remove the current password label/TextBox
2) Pass the new resetpassword to CurrentPassword Property which by the way is a getter only and not settable (SAD SAD)

Both of these things are not supported in this control. So let's quickly fix requirement 1 and there are a couple of ways to fix this :
a) You have to define a custom  <ChangePasswordTemplate>. This can be easily done by taking your ChangePassword control into DesignView in Visual studio, right click on the control and select "Convert to template". You can then switch to HtmlView and set the visibility of CurrentPasswordLabel, CurrentPassword and CurrentPasswordRequired controls.

b) If you prefer to do this in code, then you can find the Label and TextBox for CurrentPassword and set its visiblity to false. Since a is a nobrainer, i'm including a sample code of method (b) :

Label l = (Label)changePassword1.ChangePasswordTemplateContainer.

         FindControl("CurrentPasswordLabel");

if (l != null)

{
    l.Visible = false;
}
TextBox tb = (TextBox)changePassword1.ChangePasswordTemplateContainer.
FindControl("CurrentPassword");

if (tb != null)

{
    tb.Visible = false;
}
RequiredFieldValidator rfv = 

        (RequiredFieldValidator)changePassword1.

ChangePasswordTemplateContainer.FindControl("CurrentPasswordRequired");

if (rfv != null)
{
    rfv.Visible = false;

}

Now that we have the fields we want disabled, let's head onto fix issue 2 :
We can't pass the Autogenerated password to the CurrentPassword Property because its a getter only, however this getter returns the value from our CurrentPassword TextBox, and this job is done immidiately after ChangingPassword event fires. This is good news for us, so we can resolve issue 2 like this :

void changePassword1_ChangingPassword(object sender, 
LoginCancelEventArgs e)
{
    changePassword1.UserName = user.UserName;
    TextBox currentPassword = (TextBox)changePassword1.
    ChangePasswordTemplateContainer.FindControl("CurrentPassword");

    if (currentPassword != null)

    {
        currentPassword.Text = user.ResetPassword();

    }

}

Note that in the above code, user is a reference to a field of type MembershipUser. Ok, that's it. Now we have what were after, look at the screenshot below :

Reducing UpdatePanel bloat by utilizing UpdateMode="Conditional" and ChildrenAsTriggers="false"

Just the other day, i was playing around with my DataControls nested inside an updatepanel. While this was working well, since everypostback was being done via an ajax callback, the amount of traffic going back and forth was simply way too bloated. It's easy not to notice at first, because everything is working as expected. however imagine a simple situation as the following pseudo code below. Things could be very complex, depending on how many datacontrols you have and the level of nesting.

<asp:updatepanel id="UpdatePanel1" runat="server">
<ContentTemplate>
    <asp:GridView ID="GridView1" AutoGenerateSelectButton="true" 
runat="server" 
OnSelectedIndexChanged="GridView1_SelectedIndexChanged">
</asp:GridView>

<asp:DetailsView ID="DetailsView1" AutoGenerateEditButton="true"
runat="server" OnModeChanging="DetailsView1_ModeChanging">
</asp:DetailsView>
</ContentTemplate>
</asp:updatepanel>

As you can note from the code, this is a simple GridView, which enables a DetailsView when a row in the GridView is selected. We then have an Edit button on the DetailsView that should send the DetailsView in edit mode when clicked. All nice so far. Now, this is going to work as advertised ofcourse, all postback is done silently in the background.

But if you look closely enough, both the gridview and the DetailsView are contained within a single UpdatePanel, so obviously the postback caused from any child control nested in the updatepanel will cause the entire contents of the updatepanel to refresh and send back the collective rendered content to the client.

Below screenshots is the traffic analysed through firebug (a firefox extention). Hilighted data denotes the extra data we do not need rendered to the client.

As you can note from the screenshots above, my clicking the select button in the gridview, which should be launching the DetailsView in turn, while i'd only need the rendering of the DetailsView send back to me (since the gridview shouldn't need to change), i actually end up with both the rendering of the GridView and the DetailsView. Indeed, there is extra data(the GridView) being rendered which we do not need.


Ok, this is indeed a problem. Were doing things wrongly. So, how do we cause only the DetailsView to render back instead ? One might quickly think, let's put each into their own individual UpdatePanels ? :-)

So, let's try that. Nothing to be ashamed of. It was the first solution that came to my mind too :P

<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
     <asp:GridView ID="GridView1" AutoGenerateSelectButton="true" runat="server" 
OnSelectedIndexChanged="GridView1_SelectedIndexChanged">
     </asp:GridView>
</ContentTemplate>
</asp:UpdatePanel>

<asp:UpdatePanel ID="UpdatePanel2" UpdateMode="conditional" runat="server">
  <Triggers>
    <asp:AsyncPostBackTrigger ControlID="GridView1" EventName="RowCommand" />
  </Triggers>
<ContentTemplate>

<asp:DetailsView ID="DetailsView1" AutoGenerateEditButton="true" runat="server" 
OnModeChanging="DetailsView1_ModeChanging">
</asp:DetailsView>
</ContentTemplate>
</asp:UpdatePanel>

And here below is the screnshot of the traffic as seen through firebug. Hilighted data denotes the extra data we do not need rendered to the client.

As you can see, we ended up with the same data as before. Nothing has changed, even though we included them in two separate UpdatePanels. Strange ? Not really. If you think about it, both panels are included in the page, and by default, both panels have UpdateMode="Always" set on them, which causes both to refresh upon an async callback.

azzzz we have a problem indeed. Time to read the documentation :P

The first thing the docs hint about are two things : UpdateMode="Conditional" versus the Default which is "Always" and the second thing is  ChildrenAsTriggers="false" ; both of which are handy.

If my postback was being caused only by children in UpdatePanel2, i couldof just set UpdateMode="Conditional" on UpdatePanel1 and i'd actually achieve what i was after. Only UpdatePanel2's content will be send back to the client. However if you will note in my example above, a control in UpdatePanel1 is the one who is triggering the postback. This satisfies the "Conditional" bit and UpdatePanel1 also renders its contents. Again not what i'm after.

In effect, i've had to set both UpdateMode="Conditional" and also set ChildrenAsTriggers="false" on UpdatePanel1. This stopped the unwanted behaviour. ChildrenAsTriggers property has a proper explaination in the documentation, you can look it up. In short, it simply stops any direct children from making it refresh. This is good for us and what we are after.

That's just perfect. Using this combo, i can keep the panel i do not want updated, while letting the panel with the update trigger refresh at will. This also allows me to control who gets updated by calling the update method manually on the panel that interests me. For example if i edit a record in the detailsview and want to show the change in the gridview, i'd run the update operation and then right after that, call update on the panel that contains my gridview manually.

<asp:UpdatePanel ID="UpdatePanel1" UpdateMode="conditional" 
ChildrenAsTriggers="false" runat="server">
<ContentTemplate>
   <asp:GridView ID="GridView1" AutoGenerateSelectButton="true" runat="server" 
OnSelectedIndexChanged="GridView1_SelectedIndexChanged">
   </asp:GridView>
</ContentTemplate>

</asp:UpdatePanel>
<asp:UpdatePanel ID="UpdatePanel2" runat="server">
   <Triggers>
      <asp:AsyncPostBackTrigger ControlID="GridView1" EventName="RowCommand" />
   </Triggers>
<ContentTemplate>

<asp:DetailsView ID="DetailsView1" AutoGenerateEditButton="true" runat="server" 
OnModeChanging="DetailsView1_ModeChanging">
</asp:DetailsView>
</ContentTemplate>
</asp:UpdatePanel>

here are the screenies, you can see, only the detailsview is now present in our callback. Just perfect.

While this is a simplistic example, had you many deeply nested updatepanels you can easily workout who gets updated and whose data gets rendered reducing bloat, using the same method i've mentioned above. Don't simply include EVERYTHING in one updatepanel or multiple and depend on the default, posting back un-necessary bloat on each callback. Firebug for Firefox and Fiddler for IE are both great tools for inspecting and analysing your callback traffic. Use either. I prefer firebug :p

Ok, so that was easy(just set UpdateMode="conditional" ChildrenAsTriggers="false"), nonetheless i ended up with quite a lengthy post :x

Failed to load viewstate ? Typical problem, with an obvious solution.

  Understanding viewstate is fundamental in asp.net, especially if you had run into :

Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request.

The only way to resolve is a proper understanding of viewstate.

http://geekswithblogs.net/FrostRed/archive/2007/02/17/106547.aspx is a interesting post on viewstate that i happen to read today, pointed out to me by someone who ran into a viewstate problem about the control tree not matching and was clearly afraid of adding controls dynamically after reading some facts presented in that article. Who wouldn't ?

While the post gives us a very good understanding of viewstate and how it can fail, so i encourage you to read it first, might seem lengthy but I assure  you, it's quite interesting. However, when you're done, follow my rant here, since I feel it's important to know, that, the failure can only happen when either done deliberately as per the sample code in the post i linked to above or to *not* understanding viewstate and how it works.

So how can we easily avoid these failures ? Let's look at his first code example, and build onto that :

protected void Page_Init(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
       Button btnClickMe = new Button();
       form1.Controls.Add(btnClickMe);
       btnClickMe.Text = "Click me";
    }
    else
    {
      Label label = new Label();
      form1.Controls.Add(label);
    }
}

As you can note above, this is problematic, since the control into which viewstate is restored is matched by control index, so when the index changes, as is clear in the above code, because if btnClickMe was loaded in for example index [0], now upon postback, after the page has been recreated and rebuilt, the Label "label" is loaded in index [0] instead and takes the place of the button. So this means viewstate that was meant for the button is loaded into the label instead, and the output in the screen after clicking the button is "click me" which was clearly not provided to the label's text property.

Now that we understand the problem, how can this sample apply in real world or why would anybody want to do something like this ? Basically in short, why is viewstate being utilized, if it's not needed after postback ? Button btnClickMe is not reloaded after postback, so it's safe to turn off viewstate on this control, and problem is solved.

This is a typical situation where you deliberately want viewstate to fail, apart from that i see no real use to want to maintain viewstate, which is also bloat on a control that clearly is not utilizing it.

so a rewrite ? here :

protected void Page_Init(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        Button btnClickMe = new Button();
        // note the addition of the following line
        btnClickMe.EnableViewState = false; 
        form1.Controls.Add(btnClickMe);
        btnClickMe.Text = "Click me";
    }
    else
    {
      Label label = new Label();
      form1.Controls.Add(label);
    }
}

Otherwise, again as per the sample code above, had we been using viewstate, then the problem would resolve itself, if we recreated the control also after postback, which is one of the basic rules of dynamic controls creation. I say rules but really it's the logical thing to do since the page is destroyed after postback and asp.net will have no recollection of controls you added dynamically since memory is cleared, so it's upto you to build it up again manually.

protected void Page_Init(object sender, EventArgs e)
{
       // button will be created even after postback
       Button btnClickMe = new Button();
       btnClickMe.EnableViewState = false;
       form1.Controls.Add(btnClickMe);
       btnClickMe.Text = "Click me";
       if (IsPostBack)
       {
         Label label = new Label();
         form1.Controls.Add(label);
       }
}

So, bottom line, a proper understanding of viewstate, knowledge of the page life cycle, so you know in what phase it's safe to build your control, which will guarantee that viewstate is reloaded into the control(so you load it prior to page_load), and you got it right. For a proper understanding of the page life cycle, you can read the following document on msdn : http://msdn2.microsoft.com/en-us/library/ms178472.aspx?wt.slv=ColumnA

Update Jan/04/2008: I forgot to mention a gotcha, so here it is :  

Another gotcha you want to avoid is also the order of controls, that is, when you're loading a dynamic control, make sure the order in which you create it, has the same order when you recreate it. Confused, here let me explain better :

protected void Page_Init(object sender, EventArgs e)
{
   if (IsPostBack)
   {
      Label label = new Label();
      label.ID = "label1";
      form1.Controls.Add(label);
      label.Text = "label";

      Button btnClickMe = new Button();
      btnClickMe.ID = "button1";
      form1.Controls.Add(btnClickMe);
      btnClickMe.Text = "Click me";
   }
   else if (!IsPostBack)
   {
      //Now lets change the order 
      //during postback and we are
      //recreating the controls
      Button btnClickMe = new Button();
      btnClickMe.ID = "button1";
      form1.Controls.Add(btnClickMe);
      btnClickMe.Text = "Click me";

      Label label = new Label();
      label.ID = "label1";
      form1.Controls.Add(label);
      label.Text = "label";
   }
}

As you can note above, the order in which controls are added changes after postback. In this scenario what really happens ? The viewstate meant for the button is loaded into the label and the viewstate meant for the label is loaded into the button. So, you really want to be careful with the order in which you recreate your controls.

UpdatePanel Css StyleSheet upon partial-refresh bug in IE

The update panel seems to have a bug when registering an external stylesheet or including css styles from within the contents that will be getting partially rendered. The bug only seems to occur in IE, works nicely in firefox. Impressive indeed. My problems started when i had a control that needed to render a link to an external stylesheet, which was quite mm easy and normal.

I mean i've been there and done that plenty of times, however this time there were situations in which the stylesheet needed to be registered if my control was included in an updatepanel and kept invisible during inital load, while enabling it only upon a partial postback. TRICKY TRICKY TRICKY!

More over, there is an old bug opened and closed with a reason "this is by design". Seems awkward to me that this is by design and only effects IE :-(
The url to the bug report is here :

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=103134

I resolved by registering the css in the OnInit phase of my custom control. Since this would run and register the css even if the control was disabled or invisible, which is what i was after, since it registered the control with the page on first load instead of trying to rendering the style link as part of my rendering for the control(which obviously didn't work in IE). A simplied piece of my code of how i have worked around this problem is as follows :

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
ScriptManager sm = ScriptManager.GetCurrent(Page);
    if (!sm.IsInAsyncPostBack)
{
       string css = string.Format("<link rel=\"stylesheet\" 
        href=\"{0}\" type=\"text/css\" />", 
ResolveUrl(CssClassFile));

ScriptManager.RegisterClientScriptBlock(this, 
      typeof(MyBlahControl), "MyBlahId", css, false);
}
}

Update 01/01/2008 : Please read the first two comments below. CSS contianment from within the <body element violates xhtml specs and as such here is an update that includes the css in the <head section. Thanks to Ram Krisna for pointing out/commenting this.

protected override void OnInit(EventArgs e)
{
  base.OnInit(e);
ScriptManager sm = ScriptManager.GetCurrent(Page);
  if (!sm.IsInAsyncPostBack)
{
HtmlLink l = new HtmlLink();
l.Href = ResolveUrl(CssClassFile);
l.Attributes.Add("rel", "stylesheet");
l.Attributes.Add("type", "text/css");
Page.Header.Controls.Add(l);
}
}

A simplified test of what I feel is an open bug and should be fixed can be seen below. After clicking the button, the style applied to the label is lost and happens only in IE7, donno about previous versions since i have not tested :

<%@ Page Language="C#" %>

<script runat="server">

protected void Button1_Click(object sender, EventArgs e)
{
// do something
}

</script>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:ScriptManager ID="ScriptManager1" runat="server">
</asp:ScriptManager>
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
<!-- 
Note below that for simplicity i am not
using an external stylesheet. Anyway, even with an external style
sheet the result is the same. The style is 
not applied after partial postback 
-->
<style type="text/css">
.MakeGreen{background-color:green;}
</style>
<asp:Label ID="Label1" CssClass="MakeGreen" 
runat="server" Text="Label"></asp:Label>

<asp:Button ID="Button1" runat="server" Text="Partial refresh"
OnClick="Button1_Click" />

</ContentTemplate>
</asp:UpdatePanel>
</div>
</form>
</body>
</html>