Dan Maharry

Today's Bookmarks (Mar 11 2010)

Dan@Delicious — Thu, 11 Mar 2010 05:07:00 +0000

Improving CSS With .LESS

Scott Mitchell investigates how using .LESS (a port of the Ruby LESS library) makes using CSS that bit easier.

(tags: css asp.net c# html)

ASP.NET 4.0 Part 11, Configuring Routing Is Easier

DanM — Wed, 10 Mar 2010 01:00:00 +0000

Welcome to part 11 of my tour through ASP.NET 4.0. In this episode, we're going to take a look at how routing for webforms has been made easier to set up in ASP.NET 4.0. This will be followed up in Part 12 with a look at the new route-aware classes, methods and properties in more detail.

Routing was originally introduced in ASP.NET 3.5 SP1 as part of the foundations to enable the ASP.NET MVC template engine to work. It could also be used against the webforms engine but a certain amount of rolling-your-own-foundation coding was required to enable it properly.

In ASP.NET 4.0, that initial legwork is no longer necessary as routing for webforms is now supported as standard in System.Web, the majority of the configuration for routing is pre-set in system-wide config files, and some extra goodness has been added into various classes for ease of use as well. All in all, if you haven't had occasion to try routing with webforms before, try it with ASP.NET 4.0. It's really simple.

Why?

There are a metric / boatload / of articles introducing routing and how it works. In a nutshell, routing, like URL rewriting, is a response to two general criticisms of websites.

We humans prefer it if a page's URL is readable. For example, http://myforums.info/forum-Music is easier to read than http://myforums.info/forum.aspx?id=2. It's easier to remember too
Search engines prefer human-readable URLs as well. In particular, they like URLs with no querystring parameters at the end. And, the more search engine friendly a site's URLs are, the better indexed they may be by a search engine and the higher they may appear in search rankings. (Obviously, URLs aren't the only thing indexing robots look at when they come to your site - Descriptions and Keywords are up there with a host of other things too - but they certainly help.)

So then, the major consequence of routing as far as webforms is concerned are URLs which are more readable for humans and search robots alike with no reduction of information to the page itself.

How?

Routes are initialized as named, regular expressions (using a subset of the standard .NET RegEx syntax) and given an order in which they will be matched against the currently requested URL. For example,

user-{username}
forum-{forumname}
forum-{forumname}/thread-{threadid}

Let's say a request comes to the server for http://myforums.info/forum-Music.

If the request is for a page that actually exists on the site, no routing actually occurs and that page is loaded and runs as normal.
If the page doesn't exist, the requested URL is matched against each initialized route in the order you've specified. In this example, user-{username} doesn't match the requested URL, so the next route is tried.
When a route matching the requested URL is found, the request is routed to the page that deals with that route. Any named sections of the route are then made available to the handling page within the RouteData collection. For example, http://myforums.info/forum-Music matches forum-{forumname}, so control for the request would be passed to the page for that route along with a RouteData collection containing one KeyValuePair where forumname is the Key and Music is its value.
If no route is found to match the incoming request, it is passed to the standard ASP.NET 404 page or a custom page if you've defined one.

Routing Is Neither URL Rewriting nor Redirection

Hopefully, the above description should differentiate routing from URL rewriting and page redirection. However, just in case it didn't...

Routing is not Page Redirection
Redirection can only work if the incoming URL is for a page that exist. It works by sending a response to the browser saying that the page has moved with the browser then issuing a second request for the URL it is being redirected to. Routed URLs on the other hand do not necessarily refer to a page that actually exists - they will often seem to refer to directories for example - and are dealt with in one request. Browsers will not issue a second request for the actual page which handles the route.
Routing is not URL Rewriting
URL rewriting occurs very early on in the asp.net request pipeline, literally as request processing is beginning. When the rewritten URL is resolved, IIS then sends it down the pipeline to find a handler to deal with it. It has no control over what handler deals with the request. Routing, on the other hand, occurs further down the pipeline, once the request has been authorised, at which point the routing module dispatches the request to a handler based on which route the request matches and the handler specified by you to deal with the route. (IIS team member Ruslan Yarushev goes into much more detail on the differences between the two in this article.)

Setting Up Webforms Routing In ASP.NET 3.5

Briefly, here are the steps needed to enable routing for webforms in ASP.NET 3.5.

All routing classes and namespaces are found in a new DLL, System.Web.Routing.dll to be included as a reference in your website.
The UrlRoutingModule needs to be added to the list of modules enabled for the site in web.config (as described here in MSDN)
A handler class inheriting IRouteHandler needs to be created that understands how to resolve the route into the page or handler that will actually process the request and generate the RouteData collection. Both Phil Haack and Chris Cavanagh put forward basic implementations of this handler, discussing potential security issues.
Register the routes for the site in the Application_Start handler of global.asax using your new route handler class. For example,

protected void Application_Start(object sender, EventArgs e)
{
 RegisterRoutes(RouteTable.Routes);
}

public static void RegisterRoutes(RouteCollection routes)
{
 // Route existing files (default will shortcut routing if physical file exists)
 RouteTable.Routes.RouteExistingFiles = true;

 // Add StopRoutingHandler for .axd and .asmx requests
 routes.Add(new Route("{resource}.axd/{*pathInfo}", 
              new StopRoutingHandler()));
 routes.Add(new Route("{service}.asmx/{*pathInfo}", 
              new StopRoutingHandler()));

 // Add existing routes
 routes.Add("Users", new Route("user-{username}", 
              new WebFormRouteHandler("~/users.aspx", true)));
 routes.Add("Forums", new Route("forum-{forumname}", 
              new WebFormRouteHandler("~/forum.aspx", true)));
 routes.Add("Threads", new Route("forum-{forumname}/thread-{threadid}", 
              new WebFormRouteHandler("~/thread.aspx", true)));

 // Add an unnamed handler for all unknown requests (now created in the PageRoute table)
 //routes.Add(new Route("{value}", 
                new WebFormRouteHandler("~/pages/default.aspx")));
}

Write your pages as you would normally using the RouteData collection in place of the Querystring class. You'll need to make RouteData available by passing a RequestContext object to the object that needs access to the RouteData. Again, Phil Haack suggests one way of doing this (via an IRoutableObject interface) here.
Finally, you have to configure IIS to have ASP.NET deal with requests to your routes, thus passing them on to your RouteHandler classes. If you're using IIS6 and your routes are extension-less (i.e. missing .aspx, .asmx , .ashx etc file extensions in their composition), you'll need to configure wildcard maps on a per-directory level according to where your routes point else you'll end up serving all your static files with ASP.NET as well. Full instructions for this come courtesy of Steve Sanderson (Part 1, Part 2).

Setting Up Webforms Routing In ASP.NET 4.0

By comparison, the procedure is far more straightforward in ASP.NET 4.0, thanks in large part to Microsoft being able to open up and edit System.Web and the classes inside it. Let's compare

System.Web.Routing has been folded into System.Web.dll in .NET 4.0 so there is no need for an additional reference to it in your solution.
The UrlRoutingModule is also already set up in the machine-wide web.config file which means that it works straight off the bat in IIS 6. For IIS 7 users, however, you'll need to enable it with the following addition to web.config.

<?xml version="1.0"?>
<configuration>
...
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      ...
    </modules>
  </system.webServer>
</configuration>

ASP.NET 4.0 includes an implementation of IRouteHandler for you to use - it's called PageRouteHandler. There's no reason why you can't build your own as before, but it's no longer necessary.
You still need to register routes for your application but if you're using the built-in PageRouteHandler class, you can use the MapPageRoute helper method to make route registration clearer.

protected void Application_Start(object sender, EventArgs e)
{
  RegisterRoutes(RouteTable.Routes);
}

public static void RegisterRoutes(RouteCollection routes)
{
  // Route existing files (default will shortcut routing if physical file exists)
  RouteTable.Routes.RouteExistingFiles = true;

  // Add StopRoutingHandler for .axd and .asmx requests
  routes.Add(new Route("{resource}.axd/{*pathInfo}", 
              new StopRoutingHandler()));
  routes.Add(new Route("{service}.asmx/{*pathInfo}", 
              new StopRoutingHandler()));

  // Add existing routes with MapPageRoute helper method
  routes.MapPageRoute("Users", "user-{username}", "~/users.aspx");
  routes.MapPageRoute("Forums", "forum-{forumname}", "~/forum.aspx", true);

  // MapPageRoute is equivalent to adding a Route with the PageRouteHandler like so
  routes.Add("Threads", new Route("forum-{forumname}/thread-{threadid}", 
    new PageRouteHandler("~/thread.aspx", true)));
}

Any pages you write now automatically have access to the RouteData collection as a property of the Page class itself, as well as several other route-aware additions we'll review in the next section.

protected void Page_Load(object sender, EventArgs e)
{
  lblHello.Text = 
    RouteData.Values["username"] == null ?
      "Hello Mr A. Nonymous" : 
      String.Format("Hello {0}", RouteData.Values["username"].ToString());
}

Regrettably, while integration into IIS7 Integrated Mode remains quite simple, you still need to configure IIS6 \ IIS7 in Classic mode to associate the routes used in your site with ASP.NET as you did in ASP.NET 3.5. That's a failing of IIS6 rather than ASP.NET.

As you can see, setting up routing for an ASP.NET 4.0 webforms site is somewhat simpler than for the previous version as Microsoft has taken the opportunity to refactor routing into the core ASP.NET framework. In the next episode, we'll look at several of the new route-aware features for use once in ASP.NET 4.0 sites we've set routing up. Until then, happy coding!

Filmdash 2010

DanM — Mon, 08 Mar 2010 23:00:00 +0000

This year's Filmdash event took place last weekend in anticipation of The Oscars. This is the rather manic weekend where teams of budding film makers get given the name and theme of a film to make from scratch in 48 hours and don't usually sleep that much. I've done it before but couldn't make it this year. Happily however, Messrs Squier and Eaves carried on regardless and put together the comic Silence is Gordon. And a little making of... video too. The Oscars may still be far away but damn it's fun to make films. Well done lads!

Silence Is Gordon

ASP.NET 4.0 Part 10, A Handful Of Little Things

DanM — Thu, 04 Mar 2010 22:00:00 +0000

Welcome to part 10 of my tour through ASP.NET 4.0. In this episode, we’re going to look at a few small but useful additions to the ASP.NET 4.0 webforms template engine before we head out into the wider world of the core framework – routing, caching, sessions and so on.

<asp:Chart> Now Built In

We’ve seen before how Microsoft has folded features from ASP.NET 3.x and other out-of-band releases into the core ASP.NET 4.0 DLLs before. Case in point, the ASP.NET Chart control released in November 2008. This was based on Dundas Chart source code version 5.5 via a Microsoft security, accessibility, and API review. It’s now built into the core which means no additional web.config to get it running and an entry in the Data tab of the standard toolbox set.

Check out more info on the charting control here.

Three New Redirect Methods

The HttpResponse class has been fitted with three new redirect methods, two to work nicely with routing, which we’ll cover later in this series, and the other to play nicer with search engines. Response.RedirectToRoute and Response.RedirectToRoutePermanent are the two we'll note in passing for now. As you might suspect, these allow us to redirect users to a page at the end of a route we've defined rather than the page directly. The main difference between the two is that RedirectToRoute sends a HTTP 302 Found response back to the browser while ResponseToRoutePermanent sends a HTTP 301 Moved Permanently. To a user, both methods simply redirect their browser to a new page. To a search engine spider, 302 Found implies that the page has moved temporarily, so it will index both the old and new, temporary location. 301 Moved Permanently implies that henceforth the old location is not used and it will only index the new location going forward.

The third new redirect method, Response.RedirectPermanent, also sends a 301 Move Permanently response, but redirects straight to a page rather than a route. It has two overloads like Response.Redirect.

RedirectPermanent(string url)
RedirectPermanent(string url, bool endResponse)

The first parameter is simply the URL of the page you wish to redirect to.

Response.RedirectPermanent(http://www.danmaharry.com);

The second parameter lets you specify whether or not ASP.NET should stop processing the page and move straight to processing the Application_EndRequest method in global.asax.cs if you have one.

Side note: There has always been an issue with Response.Redirect because it calls Response.End internally which can lead to ASP.NET silently throwing ThreadAbortExceptions. A good thread on this problem can be found here. The same is likely true of Response.RedirectPermanent, so the upshot is you might want to use these lines of code to avoid the exception being thrown although there are more thorough solutions on offer.

Response.RedirectPermanent("http://www.danmaharry.com", false);
HttpContext.Current.ApplicationInstance.CompleteRequest();

Your mileage may vary with each approach.

Inline HTML Encoded Strings

Script injection is one of those attack vectors on a website which is easily missed if you're not careful and has the potential for a great deal of grief if you do forget. A first guard against this is to HTMLEncode any user input before being stored in the database or shown on screen. Typically this all done in the code-behind, but the latter can now also be achieved inline using the new <%: message %> syntax, which will automatically HTML encode the given message string. For example,

<p>Unencoded : <script type='text/javascript'>alert('hello');</script></p>
<p>Encoded : <%:"<script type='text/javascript'>alert('hello');</script>" %></p>

The top line will have the browser running the javascript in the script tags. The bottom line will HTMLEncode the script tags and produce the following code (on one line - the line returns are for clarity).

<p>Encoded : 
  &lt;script type=&#39;text/javascript&#39;&gt;alert(&#39;hello&#39;);&lt;/script&gt; 
</p>

Take care not to HTMLEncode a string in code-behind and then also inline with this syntax. ASP.NET will simply HTMLEncode it twice - probably not what you need.

Side note: Two other items of import with respect to ASP.NET security have happened recently.

The Anti Cross-Site Scripting library v3.1 was released back in November 2009. Just after that, the Security Tools team announced they are to incorporate it and several other web security tools into a single amalgam, currently known as the Web Protection Library. The first CTP of WPL is now available on the MS Connect site and there's a video on Channel 9 where the contents of WPL are explained.
Wrox Press has published the rather splendid Beginning ASP.NET Security, which quite thoroughly covers how to write your websites and web services securely and safely. It's a great little book for beginner to intermediate programmers. Author Barry Dorrans (a newly-minted member of the MS Security Tools team) is also publishing any errata found in the book on his blog as well which is handy. You can get it from Amazon US and Amazon UK.

That's all for today. In the next episode, we'll take a look at Routing for Webforms. Happy coding!

UK Events Of Interest (March\April 2010)

obiwan — Wed, 03 Mar 2010 17:00:00 +0000

Scott Guthrie is coming to the UK for two days. He’ll be in Glasgow and Birmingham on March 25 and 26 respectively. Registration opened today, so click quickly for Glasgow and Birmingham tickets before they are sold out. Both events are free.

If you can’t make either of those, Microsoft are running a week of tech days in London to mark the launch of Visual Studio 2010 and to promote the new Windows 7 Phone platform. They are all in the Vue 6 Cinema Broadway in Fulham. [ Twitter tweme: #TechDays ]

April 12 : Visual Studio 2010 – A Path to Big Ideas (for Heads of Development, Dev Managers and Software Architects
April 13 : Getting started with .NET Framework 4 and Visual Studio 2010 (for developers : wait list only)
April 14 : The Essential MIX – Highlights from MIX ‘10 with sessions on ASP.NET 4.0, Silverlight 4 and Azure (for developers)
April 15 : Best of Breed Client Applications on Windows 7 – Windows 7 API, Building Rich Clients with .NET 4 and a bit of Azure (for developers)
April 16 : Windows Phone – Developing for the Windows 7 Phones Series (for developers : registration not up yet)

If you’re a Silverlight fan, then Microsoft’s Silverlight Geek Jesse Liberty is doing a 9 day tour of UK with an extra in Dublin for those in Eire.

April 12: The .NET Developer Network in Bristol.
April 13 and 14: Microsoft Tech Days, London.
Tuesday April 13: Silverlight User Group /London .NET User Group.
Wednesday April 14: The Next Generation User Group, Cambridge.
Thursday April 15: Black Marble User Group, Leeds
Friday April 16: NEBytes, Newcastle Upon Tyne
Monday April 19 Scottish Developer’s User Group, Edinburgh
Tuesday April 20 Scottish Developer’s User Group, Glasgow
Thursday April 21 Belfast: tbc
Friday April 22 Dublin: tbc

Overviews of the talks he’ll be giving can be found here on his blog.

Of course, if you’re in the US then you’ve also got MIX 10 (March 15-17), An Event Apart (April 5-7), the IA Summit 2010 (April 7-11), and Chirp : The Twitter Dev Conference (April 14 –15) to attend, so it’s not all bad really, is it?

Today's Bookmarks (March 3 2010)

Dan@Delicious — Wed, 03 Mar 2010 05:03:00 +0000

20 Impressive jQuery Button Plugins

Nice article about different things you can do with a button and some jQuery

(tags: javascript jquery tutorial ui)
How to Search For, Hire, and Work With a Web Developer

Neat article for designers outlining a few simple guidelines for finding a developer to implement your designs

(tags: freelance jobs)

ASP.NET, Part 9: Rendering Cleaner HTML

DanM — Wed, 03 Mar 2010 02:00:00 +0000

Welcome to part 9 of my tour through ASP.NET 4.0. In this episode, we’ll conclude our look at the ways that ASP.NET has been tweaked in v4.0 to produce cleaner, leaner HTML that we can turn to our purpose without having to deal with some of the inconveniences of previous versions – control IDs and injected HTML we can’t control being two. More control over viewstate being a third.

ASP.NET 2.0: Only Technically Standards Compliant…

Even in 2005, the idea of producing pure HTML\CSS websites had gained quite a foothold. XHTML had been a W3C Recommendation since 2001 and CSS was evolving and being used more prevalently. Sites like CSS Zen Garden had been championing cross-browser sites and advanced layouts with this approach for a couple of years. All it required was control over the HTML generated by your site and some reasoned application of CSS.

Regrettably, ASP.NET 1.1 didn’t produce standards-compliant HTML at all, so ASP.NET 2.0 created a new setting in web.config called xhtmlConformance that would determine how its server controls were to be rendered as HTML. By default, controls would render markup compatible with the XHTML 1.0 Transitional standard (Transitional). Alternatively, the setting could be changed to have ASP.NET render markup compatible with XHTML 1.0 Strict (Strict) or as v1.1 (Legacy) has rendered it before. Websites upgraded from v1.1 to v2.0 were set to this Legacy mode.

Unfortunately, sites running in Legacy mode didn’t work with ASP.NET AJAX and while Transitional and Strict modes were technically compliant with the XHTML 1.0 standard, they could equally have been described as CSS-intolerant.

Menus were rendered as tables rather than lists (not only harder to work with in CSS, but semantically wrong too)
Several properties like border=0 or disabled=disabled were mandatorily added to various elements without a way to remove them.
For templated controls, you had full control over the templates themselves, but not over the outer table that surrounded the templates.

Technically correct, but not a good foundation to build standards compliant sites upon. The introduction of the ListView & DataPager controls in ASP.NET 3.5 and the out of band CSS Control Adapters release helped somewhat but it’s only because they’ve been able to go into System.Web for .NET 4.0 that Microsoft have been able to make ASP.NET (mostly) CSS-friendly. Indeed, emitting cleaner markup was one of the main goals for ASP.NET 4.0

ControlRenderingCompatibilityVersion

Like xhtmlConformance in ASP.NET 2.0, a new setting is now available in web.config to control how controls render HTML. It is called ControlRenderingCompatibilityVersion.

<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation debug="false" targetFramework="4.0" />

    <pages controlRenderingCompatibilityVersion="3.5" />

  </system.web>
</configuration>

CRCV, as we’ll call it, takes one of two values. Set it to 3.5 (the default for sites upgraded from ASP.NET 3.5) and all server controls will render as they did in ASP.NET 3.5. Set it to 4.0 (the default for new web site and web application projects) and the following happens

xhtmlConformance is set to Strict.
Menus are rendered as lists rather than tables
Extraneous properties like border=0 are removed from the emitted markup. Even the error text on validation controls is no longer set to red.
The rendering of the outer table for templated controls can now be controlled with the new RenderOuterTable property.

Let’s look at these changes in detail.

Menus

Let’s consider a very simple menu control with three items.

<asp:Menu runat="server" ID="testMenu">
  <Items>
    <asp:MenuItem Text="Menu Item 1" NavigateUrl="#"></asp:MenuItem>
    <asp:MenuItem Text="Menu Item 2" NavigateUrl="#"></asp:MenuItem>
    <asp:MenuItem Text="Menu Item 3" NavigateUrl="#"></asp:MenuItem>
  </Items>
</asp:Menu>

With CRCV set to 3.5, we get three CSS styles for the menu added to the HTML <head>, 53KB of script files added in by two calls to WebResource.axd (21KB for the standard script to handle postbacks, 32KB for a menu-specific script file), and the following HTML for the menu itself.

<body>
  <div>
  <a href="#testMenu_SkipLink">
    <img alt="Skip Navigation Links" width="0" height="0" style="border-width:0px;"
      src="/CleanHtml/WebResource.axd?d=y4UEb5xFzNnwyKsjxERYdw2&amp;t=634013486901596851" />
  </a>
  <table id="testMenu" class="testMenu_2" cellpadding="0" cellspacing="0" border="0">
    <tr onmouseover="Menu_HoverStatic(this)" onmouseout="Menu_Unhover(this)" 
      onkeyup="Menu_Key(this)" id="testMenun0">
      <td>
        <table cellpadding="0" cellspacing="0" border="0" width="100%">
          <tr>
            <td style="white-space:nowrap;width:100%;">
              <a class="testMenu_1" href="#">Menu Item 1</a>
            </td>
          </tr>
        </table>
      </td>
    </tr>
    <tr onmouseover="Menu_HoverStatic(this)" onmouseout="Menu_Unhover(this)" 
      onkeyup="Menu_Key(this)" id="testMenun0">
      <td>
        <table cellpadding="0" cellspacing="0" border="0" width="100%">
          <tr>
            <td style="white-space:nowrap;width:100%;">
              <a class="testMenu_1" href="#">Menu Item 2</a>
            </td>
          </tr>
        </table>
      </td>
    </tr>
    <tr onmouseover="Menu_HoverStatic(this)" onmouseout="Menu_Unhover(this)" 
      onkeyup="Menu_Key(this)" id="testMenun0">
      <td>
        <table cellpadding="0" cellspacing="0" border="0" width="100%">
          <tr>
            <td style="white-space:nowrap;width:100%;">
              <a class="testMenu_1" href="#">Menu Item 3</a>
            </td>
          </tr>
        </table>
      </td>
    </tr>
  </table>
  <a id="testMenu_SkipLink"></a>
  </div> 
  <script type="text/javascript"> 
    //<![CDATA[
    var testMenu_Data = new Object();
    testMenu_Data.disappearAfter = 500;
    testMenu_Data.horizontalOffset = 0;
    testMenu_Data.verticalOffset = 0;
    //]]>
  </script>
</body>

With CRCV set to 4.0, we get six CSS styles added to the <head> element, a single 27KB script file downloaded to the browser (a completely refactored version of the menu script) and the following HTML for the menu.

<body>
  <div>
    <a href="#testMenu_SkipLink">
    <img alt="Skip Navigation Links" width="0" height="0" style="border-width:0px;" 
      src="/CleanHtml/WebResource.axd?d=y4UEb5xFzNnwyKsjxERYdw2&amp;t=634013486901596851" />
    </a>
    <div id="testMenu">
    <ul class="level1">
      <li><a class="level1" href="#">Menu Item 1</a></li>
      <li><a class="level1" href="#">Menu Item 2</a></li>
      <li><a class="level1" href="#">Menu Item 3</a></li>
    </ul>
    </div>
    <a id="testMenu_SkipLink"></a>
  </div>
  <script type='text/javascript'>
    new Sys.WebForms.Menu({ 
      element: 'testMenu', 
      disappearAfter: 500, 
      orientation: 'vertical', 
      tabIndex: 0, 
      disabled: false });
  </script>
</body>

As you can see, not only is the rendered HTML semantically correct, the overall payload is smaller as well. Indeed you can reduce it further by setting the Menu control’s IncludeStyleBlock property to false. This will remove the six styles added to the <head> element for you to include in your own CSS files. Finally, note that you can set the Menu control’s RenderingMode property to either List, Table or Default. This will override the CRCV setting and render the menu as either List or Table as you’ve set it.

Extraneous HTML

The Image control is a good example of a control that in ASP.NET 3.5 added a property to the emitted HTML that wasn’t asked for and couldn’t be overridden. Take a very simple declaration

<asp:Image runat="server" ID="imgMorgan" ImageUrl="~/morgan.jpg" />

With CRCV set to 3.5, ASP.NET sets the image’s border-width to 0px.

<img id="imgMorgan" src="morgan.jpg" style="border-width:0px;" />

With CRCV set to 4.0, there’s no sign of the style property at all.

<img id="imgMorgan" src="morgan.jpg" />

Other controls, such as Table and GridView are similarly shed of their extraneous properties.

Removing The Outer Table From Some Composite Controls

For the most part, ASP.NET controls will render the HTML you want them to, but it looks like some of the more complex, composite controls haven’t been ‘sanitized’ in the same way as more commonly used controls such as the Image or DropDownList. However, it is worth noting that some of these controls now have a new property called RenderOuterTable which does address one particular markup issue. These are

FormView
Login
ChangePassword
PasswordRecovery

Take for example the Login control.

<asp:Login runat="server" ID="loginTest" />

Whether CRCV is set to 3.5 or 4.0, the default markup is the same.

<table cellspacing="0" cellpadding="1" border="0" 
  id="loginTest" style="border-collapse:collapse;">
  <tr>
    <td>
      <table cellpadding="0" border="0">
        <tr>
          <td align="center" colspan="2">Log In</td>
        </tr>
        <tr>
          <td align="right">
            <label for="loginTest_UserName">User Name:</label>
          </td>
          <td>
            <input name="loginTest$UserName" type="text" id="loginTest_UserName" />
            <span id="loginTest_UserNameRequired" title="User Name is required." 
              style="color:Red;visibility:hidden;">*</span>
          </td>
        </tr>
        <tr>
          <td align="right">
            <label for="loginTest_Password">Password:</label>
          </td>
          <td>
            <input name="loginTest$Password" type="password" id="loginTest_Password" />
            <span id="loginTest_PasswordRequired" title="Password is required." 
              style="color:Red;visibility:hidden;">*</span>
          </td>
        </tr>
        <tr>
          <td colspan="2">
            <input id="loginTest_RememberMe" type="checkbox" name="loginTest$RememberMe" />
            <label for="loginTest_RememberMe">Remember me next time.</label>
          </td>
        </tr>
        <tr>
          <td align="right" colspan="2">
            <input type="submit" name="loginTest$LoginButton" value="Log In" 
              onclick="…" id="loginTest_LoginButton" />
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

A CSS-related issue with this in earlier versions of ASP.NET is the outer table which you haven’t previously been able to remove (but which ironically was added as a wrapper in to give you better control over your styles). Set the Login control’s RenderOuterTable property to false and this will lose that table no matter what CVCR is set to.

<table cellpadding="0" border="0">
  <tr>
    <td align="center" colspan="2">Log In</td>
  </tr>
  <tr>
    <td align="right">
      <label for="loginTest_UserName">User Name:</label>
    </td>
    <td>
      <input name="loginTest$UserName" type="text" id="loginTest_UserName" />
      <span id="loginTest_UserNameRequired" title="User Name is required." 
        style="color:Red;visibility:hidden;">*</span>
    </td>
  </tr>
  <tr>
    <td align="right">
      <label for="loginTest_Password">Password:</label>
    </td>
    <td>
      <input name="loginTest$Password" type="password" id="loginTest_Password" />
      <span id="loginTest_PasswordRequired" title="Password is required." 
        style="color:Red;visibility:hidden;">*</span>
    </td>
  </tr>
  <tr>
    <td colspan="2">
      <input id="loginTest_RememberMe" type="checkbox" name="loginTest$RememberMe" />
      <label for="loginTest_RememberMe">Remember me next time.</label>
    </td>
  </tr>
  <tr>
    <td align="right" colspan="2">
      <input type="submit" name="loginTest$LoginButton" value="Log In" 
        onclick="…" id="loginTest_LoginButton" />
    </td>
  </tr>
</table>

Not ground-shattering certainly, but definitely handy.

What We’ve Learnt

In today’s episode, we’ve learnt that Microsoft has taken the opportunity in ASP.NET 4.0 to clean up a great deal of the HTML emitted by its server controls, thus making it CSS-friendlier. A new setting in web.config called ControlRenderingCompatibilityVersion indicates whether controls should render as cleaner HTML or as they did in 3.5. We saw two example of the cleaner HTML in effect in the Menu and Image control and noted that while some of the more complex controls have not had their markup cleaned up, a subset of those now have a RenderOuterTable property which allows you to remove some of it manually.

Incidentally, for those of you with sites that you can’t upgrade to .NET 4.0, a group of enterprising souls are continuing to work on the CSS Friendly Adapters mentioned earlier. You’ll find this revitalization here on Google Code. Happy coding!

Today's Bookmarks (25 Feb 2010)

Dan@Delicious — Thu, 25 Feb 2010 05:04:00 +0000

ASP.NET Topics on MSDN – The Top 10 List

Links pointing to the most popular ASP.NET topics on MSDN over the last year (02/2009 to 02/2010).

(tags: asp.net documentation)
Microsoft Web App Toolkits

List of currently available web app toolkits on MSDN Code Gallery. Full docs as well

(tags: asp.net tools rest c# tutorial documentation)

ASP.NET, Part 8: Introducing ClientIDMode

DanM — Thu, 25 Feb 2010 02:00:00 +0000

Welcome to part 8 of my tour through ASP.NET 4.0. In this episode, we’ll look at a new feature that directly affects two things: page size (and thus scalability and perceived performance) and the use of JavaScript APIs such jQuery. It’s called ClientIDMode.

The Problem

Consider a typical development situation. You’re building a page which inherits its structure from a master page or two. The page itself contains a custom user control which its own set of server-side controls in it. In this particular example, let’s have a simple table.

<%@ Control Language="C#" AutoEventWireup="true" 
    CodeFile="UserControl.ascx.cs" Inherits="UserControl" %>
<asp:Table runat="server" ID="tblInfo">
  <asp:TableRow runat="server" ID="tblTopRow">
    <asp:TableCell runat="server" ID="tdTopLeft">
      <asp:Label runat="server" ID="lblChoices" Text="Choices" />
    </asp:TableCell>
    <asp:TableCell runat="server" ID="tdTopRight">
      <asp:DropDownList runat="server" ID="ddlChoiceList">
        <asp:ListItem Text="Choice One" />
        <asp:ListItem Text="Choice Two" />
        <asp:ListItem Text="Choice Three" />
      </asp:DropDownList>
    </asp:TableCell>
  </asp:TableRow>
</asp:Table>

On running this page, we’ll see that the generated HTML for the table is perhaps not as succinct as we might otherwise wish. (Note that main and submain are the names of ContentPlaceholder controls in the master pages that the page containing the table is based on.)

<table id="ctl00_ctl00_main_submain_uc1Control_tblInfo" border="0"> 
  <tr id="ctl00_ctl00_main_submain_uc1Control_tblTopRow"> 
    <td id="ctl00_ctl00_main_submain_uc1Control_tdTopLeft">
      <span id="ctl00_ctl00_main_submain_uc1Control_lblChoices">Choices</span>
    </td>
    <td id="ctl00_ctl00_main_submain_uc1Control_tdTopRight">
      <select name="ctl00$ctl00$main$submain$uc1Control$ddlChoiceList" 
              id="ctl00_ctl00_main_submain_uc1Control_ddlChoiceList"> 
        <option value="Choice One">Choice One</option> 
        <option value="Choice Two">Choice Two</option> 
        <option value="Choice Three">Choice Three</option> 
      </select>
    </td> 
  </tr> 
</table>

When ASP.NET was first created, it was decided that it should autogenerate IDs for each element on the page based on the chain of their parent naming containers. This would mean that you would not be able to generate an HTML page where two elements had the same ID. As you can see above, the IDs generated in this way are neither particularly short nor semantically meaningful, but they are unique.

The length and meaning of client-side IDs didn’t matter back in 2000, but the invention and subsequent mass adoption of AJAX a few years ago has repopularised client-side scripting on the page. Scripting libraries like jQuery have only sped this tide of JavaScript up further thanks to the ease with which quite complex, cross-browser functionality can be achieved. And if there’s one thing that JavaScript uses a lot, it’s the ID of elements on a page to identify them.

The problem with ASP.NET up to v3.5 then is that there is no way to dictate the client-side ID of an HTML element and it’s hard to know exactly what the ‘AutoID’ will be for use in your scripts. A fairly complex page with several dozen controls on it will also be significantly larger than it needs to be because of AutoIDs and on high-volume sites, that means extra bandwidth used unnecessarily (and so more cost) and a perceived performance hit on the site from users with slower connections waiting for the page to download.

The Solution

It is possible to work around this issue in several ways, but with the new ClientIDMode property in ASP.NET 4.0, we’re presented with a way to instruct ASP.NET to generate element IDs in one of three ways. This new property can be set for any webform control, page, or master page. It can also be set as a property of the <system.web>/<pages> element in web.config.

ClientIDMode has four possible values

AutoID has ASP.NET generate IDs as it does in v3.5 and earlier versions.
Static has ASP.NET use exactly the same ID given to the server control for its client-side ID.
Predictable has ASP.NET try to generate IDs that are guessable from looking at the structure of the page. It tries to strike a happy medium between AutoID and Static. It is also the default value for ClientIDMode in ASP.NET 4.0.
Inherit has ASP.NET generate a client-side ID for the page or control using the same method as its parent.

Let’s taking the example code above, and see how the <table> element is rendered in each ClientIDMode. First, let’s set the <asp:Table> control’s ClientIDMode to Predictable. As noted, this is the default in ASP.NET 4.0, so we need add no extra property. The resultant HTML looks like this:

<table id="main_submain_uc1Control_tblInfo">
  <tr id="main_submain_uc1Control_tblTopRow">
    <td id="main_submain_uc1Control_tdTopLeft">
      <span id="main_submain_uc1Control_lblChoices">Choices</span>
    </td>
    <td id="main_submain_uc1Control_tdTopRight">
      <select name="ctl00$ctl00$main$submain$uc1Control$ddlChoiceList" 
              id="main_submain_uc1Control_ddlChoiceList">
        <option value="Choice One">Choice One</option>
        <option value="Choice Two">Choice Two</option>
        <option value="Choice Three">Choice Three</option>
      </select>
    </td>
  </tr>
</table>

As you can see, the resultant IDs are mostly the same as the v3.5 ones but are no longer prepended with a (random) number of ctl00_ strings. Now let’s set ClientIDMode on the table to AutoID.

<asp:Table runat="server" ID="tblInfo" ClientIDMode="AutoID">

This should generate old-style IDs for everything again as would happen in v3.5, but actually something different happens.

<table id="ctl00_ctl00_main_submain_uc1Control_tblInfo">
  <tr id="main_submain_uc1Control_tblTopRow">
    <td id="main_submain_uc1Control_tdTopLeft">
      <span id="main_submain_uc1Control_lblChoices">Choices</span>
    </td>
    <td id="main_submain_uc1Control_tdTopRight">
      <select name="ctl00$ctl00$main$submain$uc1Control$ddlChoiceList" 
              id="main_submain_uc1Control_ddlChoiceList">
        <option value="Choice One">Choice One</option>
        <option value="Choice Two">Choice Two</option>
        <option value="Choice Three">Choice Three</option>
      </select>
    </td>
  </tr>
</table>

As you can see, only the ID for the table itself has been generated in the v3.5 way. Every other ID is still generated using the ‘Predictable Mode’ algorithm. Now try setting ClientIDMode to AutoID as an attribute of the @Master, @Page, or @Control directive. For example

<%@ Control Language="C#" AutoEventWireup="true" 
    CodeFile="UserControl.ascx.cs" Inherits="UserControl" 
    ClientIDMode="AutoID" %>

Sure enough, all the IDs for the table and its children have changed back to the v3.5 naming style as seen earlier. Try setting ClientIDMode to Static.

<%@ Control Language="C#" AutoEventWireup="true" 
    CodeFile="UserControl.ascx.cs" Inherits="UserControl" 
    ClientIDMode="Static" %>

Straight to the mark, the HTML element IDs now match their respective server-side control IDs exactly (but their name attributes are still generated as in v3.5-)

<table id="tblInfo">
  <tr id="tblTopRow">
    <td id="tdTopLeft">
      <span id="lblChoices">Choices</span>
    </td>
    <td id="tdTopRight">
      <select name="ctl00$ctl00$main$submain$uc1Control$ddlChoiceList" 
              id="ddlChoiceList">
        <option value="Choice One">Choice One</option>
        <option value="Choice Two">Choice Two</option>
        <option value="Choice Three">Choice Three</option>
      </select>
    </td>
  </tr>
</table>

Move the ClientIDMode attribute back from the @Control directive to the <asp:Table> element and you’ll see only the <table> element return its shorter ID with the rest returning to their ‘predictable’ form.

The rule then is that ClientIDMode only changes the ID generation mode for the control on which it is set. It does not affect the ID generation mode for its child controls. The only way to change the default ClientIDMode for more than one control at a time is to set it in the @Control, @Page, or @Master directives or in web.config. The only exception to this is when setting ClientIDMode on templated list controls as we’ll see later.

If you already use jQuery in your v3.5 sites and want to upgrade them to use the v4 Framework, you would be well may need to default the ClientIDMode for the site to AutoID in web.config until you’ve checked your code works against predictable mode.

<configuration>
  <system.web>
    ...
    <pages clientIDMode="AutoID" />
    ...
  </system.web>
</configuration>

In general however, a good approach to using ClientIDMode is to leave 'Predictable' as the default and for those few controls which are targeted by JQuery, set ClientIDMode to Static. ASP.NET will not interfere with an ID set as static so if you inadvertently set two or more identical IDs in a page, you’ll have to identify and disambiguate them yourself.

Using ClientIDRowSuffix With Templated List Controls

Consider the case where you’re binding some data into a Templated List control. For example a ListView.

<%@ Page Language="C#" AutoEventWireup="true" 
    CodeFile="DataBoundControls.aspx.cs" Inherits="DataBoundControls" %>
...
<body>
  <form id="form1" runat="server">
  <div>
    <asp:ListView runat="server" ID="lvwDemo">
      <LayoutTemplate>
        <table>
          <asp:PlaceHolder runat="server" ID="itemPlaceholder" />
        </table>
      </LayoutTemplate>
      <ItemTemplate>
        <tr>
          <td>
            <asp:Label runat="server" ID="lblItemName" Text='<%#Eval("Name") %>' />
          </td>
        </tr>
      </ItemTemplate>
    </asp:ListView>
  </div>
  </form>
</body>
</html>

And in the code-behind, a simple List is bound to the ListView.

protected void Page_Load(object sender, EventArgs e)
{
  List<Item> items = new List<Item> {
    new Item { Id = 11, Name = "Cat" },
    new Item { Id = 12, Name = "Dog" },
    new Item { Id = 13, Name = "Dragon" }
  };

  lvwDemo.DataSource = items;
  lvwDemo.DataBind();
}

With all defaults left on, a ClientIDMode of ‘Predictable’ produces the following HTML for the table templated in the ListView.

<table>
  <tr><td><span id="lvwDemo_lblItemName_0">Cat</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_1">Dog</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_2">Dragon</span></td></tr>
</table>

Note that an auto-incremented number is used to make the id for the span unique. You can replace that auto-incremented number with something more meaningful using the new ClientIDRowSuffix property on the ListView. The defines the data field (typically the primary key) whose value is suffixed to the row ID to make it unique. If we set it to Id on the ListView…

<asp:ListView runat="server" ID="lvwDemo" ClientIDRowSuffix="Id">

the Id for each Item object in the list is used in the span ids.

<table>
  <tr><td><span id="lvwDemo_lblItemName_11">Cat</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_12">Dog</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_13">Dragon</span></td></tr>
</table>

We could set it to Name instead of Id, as long as we can guarantee that Name is a unique field and get the following HTML.

<table>
  <tr><td><span id="lvwDemo_lblItemName_Cat">Cat</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_Dog">Dog</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_Dragon">Dragon</span></td></tr>
</table>

ClientIDRowSuffix actually takes a string[], so you can set multiple fields to this property should you wish. FOr example,

<asp:ListView runat="server" ID="lvwDemo" ClientIDRowSuffix="Id, Name">

will generate the following.

<table>
  <tr><td><span id="lvwDemo_lblItemName_11_Cat">Cat</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_12_Dog">Dog</span></td></tr>
  <tr><td><span id="lvwDemo_lblItemName_13_Dragon">Dragon</span></td></tr>
</table>

A second new property – ClientIDRowSuffixDataKeys – will return the values used to generate the client ID for a given row.

ClientIDRowSuffix and Static\AutoID Modes Don’t Mix

Be aware that ClientIDRowSuffix has no effect on either AutoID or Static ID modes and also that server-side controls placed within templates DO inherit the ClientIDMode of their parent control – in this case, the ListView or GridView in whose templates they are placed. For example, should you set ClientIDMode to Static on the ListView control in the current example…

<asp:ListView runat="server" ID="lvwDemo" ClientIDRowSuffix="Id" ClientIDMode="Static">

every span id will remain identical despite the presence of ClientIDRowSuffix.

<table>
  <tr><td><span id="lblItemName">Cat</span></td></tr>
  <tr><td><span id="lblItemName">Dog</span></td></tr>
  <tr><td><span id="lblItemName">Dragon</span></td></tr>
</table>

If you set it AutoID rather than Static, this is not a problem as AutoIDs are unique by design but there’s no influence on them via ClientIDRowSuffix either.

<table>
  <tr><td><span id="lvwDemo_ctrl0_lblItemName">Cat</span></td></tr>
  <tr><td><span id="lvwDemo_ctrl1_lblItemName">Dog</span></td></tr>
  <tr><td><span id="lvwDemo_ctrl2_lblItemName">Dragon</span></td></tr>
</table>

You could set the ClientIDMode to Predictable on the Label control in your template

<asp:ListView runat="server" ID="lvwDemo" ClientIdRowSuffix="Id" ClientIDMode="Static">
  ...
  <ItemTemplate>
    <tr>
      <td>
        <asp:Label ClientIDMode="Predictable"
          runat="server" ID="lblItemName" Text='<%#Eval("Name") %>' />
      </td>
    </tr>
  </ItemTemplate>
</asp:ListView>

but then you’ll notice that the span ids become slightly less predictable than you might like.

<table>
  <tr><td><span id="ctrl0_lblItemName_11">Cat</span></td></tr>
  <tr><td><span id="ctrl1_lblItemName_12">Dog</span></td></tr>
  <tr><td><span id="ctrl2_lblItemName_13">Dragon</span></td></tr>
</table>

What We’ve Learnt

In this episode, we’ve seen that the new ClientIDMode property gives us more control over the client-side IDs generated by server-side controls. This helps both with keeping the overall size of the page down and for referencing the correct client-side IDs in our Javascript code. We’ve seen when ClientIDMode affects or does not affect the child controls of the one on which it is set and also how ClientIDRowSuffix augments predictable mode when it comes to generating IDs for controls within the templates of a databound list control. We also noted that ClientIDRowSuffixDataKeys returns the values of the keys set in ClientIDRowSuffix used to generate a unique ID for a given row.

ASP.NET, Part 7: A New Viewstate Opt-in Model

DanM — Wed, 24 Feb 2010 01:00:00 +0000

Welcome to part 7 of my tour through ASP.NET 4.0. Today we’re going to look at what in hindsight was one of the larger design mistakes that Microsoft made when creating ASP.NET – The View State Opt-Out Model for Web Forms – and how they’ve approached a solution.

[Updated Feb 24: Added link to more in-depth tutorial on View State at end of article].

HTTP is Stateless

One of the first things you learn as a web developer is that HTTP is a stateless protocol. Requests sent over HTTP are independent of any that have gone before and retain no information about the user sending them or the state of the page (where the state is defined as the property values of the controls that make up the page’s control hierarchy.)

The issue then is how to retain such information between requests and, more significantly in this discussion, between postbacks on the same page. The standard solutions are to

Put it in session state
Put it in the URL
Put it in a cookie

Enter View State

Back in 2000, View State was created by Microsoft so we fledgling web developers didn’t have to worry about persisting this state information onto the next page. It was just another great feature whereby this information was base64-encoded on the server and stored in a hidden form element on the page named __VIEWSTATE. When the page was posted back, View State would be sent back with it and hey presto, instant state.

Ten years later, the benefit of using View State is still apparent but, as any ASP.NET MVC developer will tell you, it is not a necessary part of a web page. (To whit, MVC doesn’t use View State at all.) There are two main issues with View State

All pages take a performance hit as the server must deal with decrypting, reading, rebuilding and re-encrypting view state with each post back of a page to the server. The exact process is described here. Pages which dynamically add controls to the page may also cause exceptions when the server cannot match the control tree in the view state to that on the page.
The value in the __VIEWSTATE hidden form field can grow quite large quite quickly. Without you realising it, it could add several dozen kilobytes to your page resulting in slower transmission times to your users and back to the server when it is sent back to the server in the HTTP POST headers.

The solution to both these problems for Web Forms developers is to make sure that only the controls which need their state persisted across postbacks are included in View State and herein lies the main problem with View State that is being addressed in ASP.NET 4.0.

Opt-Out Mode vs. Opt-In Mode

From ASP.NET v1.0 to v3.5 SP1, there has only been an opt-out model for View State on a Web Forms page. This means that View State is switched on for every control on every page by default, unless you opt to disable it by setting the Page or Control’s EnableViewState property to false. The problem is that once EnableViewState is set to false for a Page for example, it is also set to false for every child control of that page, and there is no facility to override that further down the tree and have View State switched on for a control on that page.

Consider the scenario where I have several dozen form controls on a page and wish to maintain view state for just one DropDownList. I cannot set EnableViewState to false for the whole Page and then set it to True for the DropDownList. Instead I must leave EnableViewState set to true on the page and explicitly set it to false for every other control on the page as long as it isn’t a parent control for the DropDownList.

Which isn’t too great.

Fortunately, Microsoft has heeded our cries and added an opt-in model for View State in ASP.NET 4.0. Addressing the same scenario using the opt-in model, I can indeed switch off View State for the whole Page and then re-enable it explicitly on the one DropDownList I need to maintain state for. However, I do it with a new property called ViewStateMode rather than EnableViewState.

Introducing ViewStateMode

The switch between opt-out and opt-in models is made using the new ViewStateMode property. This has three possible values.

Enabled (the default for a Page) : sets the page \ control to the old school opt-out mode
Disabled : sets the page \ control to use the new opt-in mode.
Inherit (the default for a user control) : sets the control to inherit the setting from its parent page \ control.

It can be set both code-behind and declaratively in markup as an attribute of a control or of the @Page directive.

<%@Page ... ViewStateMode="Disabled" %>

Let’s take an example. In the code below, we have a normal WebForms page with EnableViewState set to true by default.

<%@ Page Language="C#" 
    AutoEventWireup="true" CodeFile="ViewStateDemo.aspx.cs"
    Inherits="ViewStateDemo" %>

<!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>View State Demo</title>
</head>
<body>
<form id="form1" runat="server">
<div>
  <asp:PlaceHolder runat="server" ID="plhOuter">
    <asp:Label runat="server" ID="lblOne" Text="My Initial Value" /><br />
    <asp:Panel runat="server" ID="pnlInner">
      <asp:Label runat="server" ID="lblTwo" Text="My Initial Value" />
    </asp:Panel>
  </asp:PlaceHolder>
  <br />
  <asp:Button runat="server" ID="btnGo" Text="View State Is Off" />
</div>
</form>
</body>
</html>

In the code-behind for this page, we re-set the Text properties for the two Labels and Button if the page has not posted back.

protected void Page_Load(object sender, EventArgs e)
{
  if (!IsPostBack)
  {
    lblOne.Text = "My set value";
    lblTwo.Text = "My set value";
    btnGo.Text = "View State Is On";
  }
}

When it loads, the page will load and the new Text values displayed. With View State enabled, those text values will stay the same when you click the button and post the page back to the server.

Now set ViewStateMode to Disabled for on the plhOuter PlaceHolder control.

<asp:PlaceHolder runat="server" ID="plhOuter" ViewStateMode="Disabled">

Now when you run the page and click the button, you’ll see that the two Labels lose their value as it is not persisted in View State. However, the Button control, which is outside the PlaceHolder still uses View State.

So far, this is nothing new. We could replace the ViewStateMode property with EnableViewState set to false and get the same result. However, we could not then also set ViewStateMode to Enabled on the pnlInner Panel control and restore ViewState to the lblTwo Label control.

<asp:Panel runat="server" ID="pnlInner" ViewStateMode="Enabled">

Now run the page and click the button again to confirm that View State is now on for lblTwo. If you did try and replace ViewStateMode property with EnableViewState set to false on the plhOuter control now and hit the button, you’ll see that EnableViewState overrides ViewStateMode and produces the results in the screenshot above rather than the one below.

The ViewStateMode property can be set on any control or on the Page itself and not just invisible container controls as we’ve seen so far. Move ViewStateMode=”Disabled” from the plhOuter control to the @Page directive.

<%@ Page ViewStateMode="Disabled" Language="C#" 
    AutoEventWireup="true" CodeFile="ViewStateDemo.aspx.cs"
    Inherits="ViewStateDemo" %>

Run the page again and you’ll see how the Button control now also loses state across a post back while lblTwo continues to retain it as ViewStateMode is still enabled on it.

Remember : View State is not Control State

While this demo adequately shows you how ViewStateMode is inherited through the Control hierarchy of a page, it would have failed had I tried to use TextBox or DropDownList controls instead of Labels with the code-behind setting their selected value or text. The DropDownList would have retained its SelectedIndex and the TextBox its Text whether View State was enabled or not because those particular properties are stored in control state. Control state is designed for storing a control's essential data (such as a TextBox's text) that must be available on postback to enable the control to function even when view state has been disabled. Thus control state is always maintained even if EnableViewState is set to false and ViewStateMode is set to Disabled.

What We’ve Learnt

In today’s episode, we’ve seen that ASP.NET 4.0 presents a new opt-in mode for View State on a page via the new ViewStateMode property. However, we’ve also seen that setting the EnableViewState property to false will disable View State for any child control or page regardless of whether one has had ViewStateMode set to Enabled on it. Thus for any control’s state to be saved in a page’s View State, the following must be true.

EnableViewState must be set to true for both the Page and the Control (which is the default setting)
ViewStateMode must be set to Enabled on the Control.

We also noted that the setting of ViewStateMode has no influence over the workings of a Control’s Control State.

For a really good, in-depth look at how View State works, you can look at both of these:

Happy Coding!