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>