Dan Maharry

ASP.NET 4.0 Part 12, Routing Helper Functions

DanM — Sun, 14 Mar 2010 21:00:00 +0000

Welcome to part 12 of my tour through ASP.NET 4.0. In the last episode, we saw how improvements in ASP.NET 4.0 have made it much simpler to get routing for webforms set up and working. In this one, we’ll look in more detail at the new routing-friendly classes, properties and methods you can start to use once routing is set up.

Defining Routes

Let’s start by defining a couple of routes and using them as examples throughout this post.

routes.MapPageRoute("Users", "user-{username}", "~/users.aspx");
routes.MapPageRoute("Forums", "forum-{forumname}", "~/forum.aspx");
routes.MapPageRoute("Threads", "forum-{forumname}/thread-{threadid}", "~/thread.aspx");

We'll also create another one with default values for each of the route parameters, using another of MapPageRoute's overloads.

routes.MapPageRoute("Posts", "post/{forumname}/{threadid}/{postid}", 
  "~/thread.aspx", false,
  new RouteValueDictionary { 
    { "forumname", "Fishing" }, { "threadid", "12" }, { "postid", "1" } 
  });

Should we now visit ~/post/, thread.aspx will load and be passed in "Fishing", "12" and "1" as the values for the forumname, threadid and postid route parameters respectively. Should we visit ~/post/art, the default values for the threadid and postid parameters will passed in along with "art" as the forumname.

MapPageRoute has a couple of other tricks up its sleeve as well. An overload with five parameters allows you to define a basic validation for legal values for each of the route parameters. For example, let's say we wanted forumname to contain only lower-case letters. Then we would define the route like this.

routes.MapPageRoute("Posts", "post/{forumname}/{threadid}/{postid}", 
  "~/thread.aspx", false,
  new RouteValueDictionary { 
    { "forumname", "Fishing" }, { "threadid", "12" }, { "postid", "1" } 
  },
  new RouteValueDictionary { { "forumname", "^[a-z]*$" } }
);

Don't forget as well that MapPageRoute is just a quick route to registering a route that is handled by the built-in PageRouteHandler class. If you want to handle the request using your own handler, you can make the equivalent call to routes.Add.

routes.Add("Posts",
  new Route("post/{forumname}/{threadid}/{postid}",
    new RouteValueDictionary { 
      { "forumname", "Fishing" }, { "threadid", "12" }, { "postid", "1" } },
    new RouteValueDictionary { { "forumname", "^[a-z]*$" } }, null,
    new PageRouteHandler("~/thread.aspx", false)));

Hyperlinks

With our routes defined, we can now set up hyperlinks between routes. All we need are the name of the route and the values of any route parameters. If we need to do it inline in the code (perhaps because it's part of a databinding operation) we can use the new <%$RouteUrl %> syntax. For example.

Go to <a runat="server" 
  href='<%$RouteUrl:RouteName=Users, UserName=Dan  %>'>dan's page</a><br />
Go to <a runat="server" 
  href='<%$RouteUrl:RouteName=Forums, ForumName=Coding  %>'>coding forum</a><br />
Go to <a runat="server" 
  href='<%$RouteUrl:RouteName=Posts %>'>the default post</a><br />

If we need to set the hyperlink in code-behind, it's easiest to use GetRouteUrl(), a new method on System.Web.UI.Control and therefore the Page class. (This actually calls RouteCollection.GetVirtualPath() to get the required URL if you'd prefer to use that instead).

GetRouteUrl() has four overloads, broadly taking the following form

GetRouteUrl([string routeName], routeParameters);

Where specifying the routeName is optional and the routeParameters can be added as either an object of anonymous type or as a RouteValueDictionary. For example,

// Named route, parameters in anonymous type object
hypUsers.NavigateUrl = Page.GetRouteUrl("users", new {username = "Dan" });

// Named route, parameters in RouteValueDictionary
hypForums.NavigateUrl = Page.GetRouteUrl("forums", 
  new RouteValueDictionary { { "forumname", "Fishing" } );

// Named route, no parameters set, so defaults used
hypPosts.NavigateUrl = Page.GetRouteUrl("posts", new {} );

// No route named
hypNoName.NavigateUrl = Page.GetRouteUrl(new { forumname = "Gaming" });

In the last example here, we've not named a route to use a basis for a URL, but we have specified a route parameter called forumname, which appears in three of our declared routes. Which route will it use as a basis to generate the URL? Simply, the first route defined that contains the named parameter. In this case, that's "forums".

Redirection

If you need to redirect a user's browser to a given address, you'll need to call one of the three new redirect methods we mentioned briefly in part 10: either Response.RedirectToRoute() or Response.RedirectToRoutePermanent(). Both have the same five overloads with the only difference that RedirectToRoute() sends an HTTP 302 temporary redirect to the browser and RedirectToRoutePermanent() sends a HTTP 301.

// No Route Named, Parameters In Anonymous Type object
Response.RedirectToRoute( new { username = "Dan" });

// No Route Named, Parameters In RouteValueDictionary
Response.RedirectToRoute( 
  new RouteValueDictionary { { "forumname", "Fishing" } ););

// Only route named, so default parameter values used
Response.RedirectToRoute("posts"); 

// Named route, parameters in anonymous type object
Response.RedirectToRoute("users", new {username = "Dan" });

// Named route, parameters in RouteValueDictionary
Response.RedirectToRoute("forums", 
  new RouteValueDictionary { { "forumname", "Fishing" } );

Note that both these methods are equivalent to calling Response.Redirect(url, stopProcessing) with stopProcessing set to false. Again, more on that here in part 10.

RouteParameters

Last but not least, DataSource users will be interested to know that Microsoft have added a new RouteParameter object to ASP.NET 4.0 which you can use in exactly the same way as, for instance, a QueryStringParameter or a ControlParameter. If you use the Configure DataSource wizard you'll see it added to the bottom of the Source list when you need to add a WHERE clause to the data source.

If you do select Route from the Source list, you'll need to set the name of the route parameter you want to use and also give a default value for the parameter if it isn't available for some reason.

These are the only differences between using a RouteParameter and any other parameter object you use with your DataSources. If you prefer to write the code yourself, the net result of the screesnshots above is the following markup.

<asp:SqlDataSource ID="SqlDataSource1" runat="server" 
  ConnectionString="<%$ ConnectionStrings:UsersDB %>" 
  SelectCommand="SELECT [UserId], [Username] FROM [Users] WHERE ([Username] = @Username)">
  <SelectParameters>
    <asp:RouteParameter DefaultValue="Dan" Name="Username" RouteKey="username" 
         Type="String" />
  </SelectParameters>
</asp:SqlDataSource>

So then, in this article, we've looked at the new methods and objects you'll likely use most often when working with webforms and routing. Until the next time, happy coding.

Today's Bookmarks (Mar 13 2010)

Dan@Delicious — Sat, 13 Mar 2010 05:02:00 +0000

FluentPath: a fluent wrapper around System.IO

Bertrand LeRoy presents an LINQ-based fluent API style around Path.

(tags: c# .net35 linq)
IIS URL Rewrite 2.0

Details and release notes for v2 of the IIS URL Rewrite module and accompanying samples

(tags: iis7)

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)