ASP.NET 4.0

ASP.NET 4 Beta 1: WebForms Routing extension methods

Scott Galloway — Tue, 19 May 2009 20:23:41 GMT

When we were adding WebForm routing to ASP.NET 4 Beta 1, we didn’t have a chance to add in a couple of methods which make working with Routes and Web Forms a lot easier!

Note: the code below is ‘similar’ to that which we’re adding ASP.NET 4 Beta 2, *that* code will be of much higher quality however, this is a sample only!

        1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq;

       4: using System.Web;

       5: using System.Web.Routing;

       6:  

       7:     public static class RouteExtensions

       8:     {

       9:         public static string GetUrlForRoute(this System.Web.UI.Page page, string routeName, RouteValueDictionary parameters)

        {

            VirtualPathData vpd= RouteTable.Routes.GetVirtualPath(null, routeName, parameters);

            return vpd.VirtualPath;

        }

        public static string GetUrlForRoute(this System.Web.UI.Page page, RouteValueDictionary parameters)

        {

            VirtualPathData vpd = RouteTable.Routes.GetVirtualPath(null, parameters);

            return vpd.VirtualPath;

        }

  

        public static void IgnoreRoute(this RouteCollection routes, string url)

        {

            routes.IgnoreRoute(url, null);

        }

  

        public static void IgnoreRoute(this RouteCollection routes, string url, object constraints)

        {

            if (routes == null)

            {

                throw new ArgumentNullException("routes");

            }

            if (url == null)

            {

                throw new ArgumentNullException("url");

            }

            IgnoreRouteInternal internal3 = new IgnoreRouteInternal(url);

            internal3.Constraints = new RouteValueDictionary(constraints);

            IgnoreRouteInternal item = internal3;

            routes.Add(item);

        }

  

        public static Route MapRoute(this RouteCollection routes, string name, string url, string physicalFile)

        {

            return routes.MapRoute(name, url, physicalFile, null, null);

        }

  

        public static Route MapRoute(this RouteCollection routes, string name, string url, string physicalFile, object defaults)

        {

            return routes.MapRoute(name, url, physicalFile, defaults, null);

        }

  

        public static Route MapRoute(this RouteCollection routes, string name, string url, string physicalFile, string[] namespaces)

        {

            return routes.MapRoute(name, url, null, null, namespaces);

        }

  

        public static Route MapRoute(this RouteCollection routes, string name, string url, string physicalFile, object defaults, object constraints)

        {

            return routes.MapRoute(name, url, physicalFile,  defaults, constraints, null);

        }

  

        public static Route MapRoute(this RouteCollection routes, string name, string url, string physicalFile, object defaults, string[] namespaces)

        {

            return routes.MapRoute(name, url, physicalFile,  defaults, null, namespaces);

        }

  

        public static Route MapRoute(this RouteCollection routes, string name, string url, string physicalFile, object defaults, object constraints, string[] namespaces)

        {

            if (routes == null)

            {

                throw new ArgumentNullException("routes");

            }

            if (url == null)

            {

                throw new ArgumentNullException("url");

            }

            if (physicalFile == null)

            {

                throw new ArgumentNullException("physicalfile");

            }

            Route route2 = new Route(url, new PageRouteHandler(physicalFile));

            route2.Defaults = new RouteValueDictionary(defaults);

            route2.Constraints = new RouteValueDictionary(constraints);

            Route item = route2;

            if ((namespaces != null) && (namespaces.Length > 0))

            {

                item.DataTokens = new RouteValueDictionary();

                item.DataTokens["Namespaces"] = namespaces;

            }

            routes.Add(name, item);

            return item;

        }

  

        // Nested Types

        private sealed class IgnoreRouteInternal : Route

        {

            // Methods

            public IgnoreRouteInternal(string url)

                : base(url, new StopRoutingHandler())

            {

            }

  

            public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary routeValues)

            {

                return null;

            }

        }

    }



So, how do you use these methods?

These extensions add a few simple methods:

MapRoute

Stolen shamelessly from MVC. These methods provide a shortcut to defining Routes for WebForms.

RouteCollection.MapRoute(string name, string url, string physicalFile);

For example to map a simple route you can now do:

RouteTable.Routes.MapRoute(“ProductDetailsRoute”, “products/{productid}”, “~/ProductDetails.aspx”);

Also has a couple of variants allowing for defining defaults etc…

RouteCollection.MapRoute(string name, string url, string physicalFile, object defaults);

RouteCollection.MapRoute(string name, string url, string physicalFile, object defaults, string[] namespaces);

GetRouteForUrl

Page.GetUrlForRoute(string routeName, RouteValueDictionary parameters);

Using a specifically named route and RouteValueDictionary containing a number of parameters will give you back a string containing the Url to use. REALLY useful in databound apps!

e.g.,

<asp:hyperlink ID="HyperLink1" runat="server"  NavigateUrl='<%# Page.GetUrlForRoute("ProductDetailsRoute",new RouteValueDictionary( new {productid= Eval("ProductID")}))%>'  Text="Details"></asp:hyperlink>

Page.GetUrlForRoute(RouteValueDictionary parameters);

Same thing, but auto-matches the RouteValueDictionary parameters against a route…

IgnoreRoute

Allows you to define urls which should not be tried for matches against routes (can be useful for upgrading WebForms apps)

RouteCollection.IgnoreRoute(string url);

RouteCollection.IgnoreRoute(string url, object constraints);

The strange case of the disappearing Feature: AdapterGroup

Scott Galloway — Mon, 27 Apr 2009 16:07:58 GMT

AdapterGroups are in Beta 1 but will (likely) not be in Beta 2 of ASP.NET 4.0

This week I have the job of removing a feature which I originally designed for ASP.NET 4.0. This feature is ‘AdapterGroups’, so what is it?

As you may be aware ASP.NET has a capability which allows switching how a control is rendered based on the capabilities of the browser the user makes the request for an ASPX page using. One of the ways this using a feature called Control Adapters. Even though these were originally designed to support mobile browsers, one of the most common uses for them right now is to ‘fix up’ the markup which many of our controls render using the CSS Control Adapters, these in essence modify the code which specific controls (those with adapters) use to render their output. See Scott Guthrie’s post as well as the original whitepaper on how these work; oh, and of course Fritz Onion’s great article on the topic.
So, by now you should see that Control Adapters can be pretty handy when you need to replace the default rendering which our controls provide to be more CSS compliant (or, whatever else you have an adapter for…). One of our big pushes in ASP.NET 4.0 is to improve how controls by default work with CSS; and we’re making a number of changes to the controls themselves to make this happen.
Originally the plan was to use the CSS Control Adapters for this, but they had some problems:

1. They’re potentially hard to configure. You have to understand how to use browser files (remember, the original use was for switching markup for mobile devices)

For example, to change a single adapter on a specific control type, you’d have to create an App_Browsers directory in your app then create a new *.browser file and enter it’s contents, pointing to the adapter you have created (or dropped the dll ofg into your bin directory). This sample is taken from Fritz Onion’s MSDN article

   1: <browsers>

   2:   <browser refID="Default">

   3:     <controlAdapters>

   4:       <adapter

   5:         controlType="System.Web.UI.WebControls.BulletedList"

   6:         adapterType="MsdnMagazine.BulletedListControlAdapter"

   7:       />

   8:     </controlAdapters>

   9:   </browser>

  10: </browsers>

2. you can only configure these by control for a whole site at a time (want to change just the one you have problems with, well…tough!)
Number two is where AdapterGroup came in…the idea being that if you wanted to use one of the CSS Control Adapters for just one specific page / one specific control with which you were having problems, well you could just do this:

   1: <%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" AdapterGroup="CSSAdapterGroup" %>

Notice in the above snippet that I’ve just set the AdapterGroup property for this page. This corresponds to a group defined in a *.browser file as follows:

   1: <browsers>

   2:   <browser refID="Default">

   3:     <controlAdapters>

   4:         <adapterGroup name="CSSAdapterGroup" >

   5:               <adapter

   6:                 controlType="System.Web.UI.WebControls.BulletedList"

   7:                 adapterType="MsdnMagazine.BulletedListControlAdapter"

   8:               />

   9:             </controlAdapters>

  10:         </adapterGroup>

  11:   </browser>

  12: </browsers>

Notice, that we’ve identified a specific set (well, one in this case!) of Control Adapters as belonging to this specific adapter group. It’s also possible to set this at site (by specifying the defaultAdapterGroup attribute in the Page config element), as well as just for individual controls, e.g.,

   1: <asp:Menu ID="Menu1" runat="server" adapterGroup="CSSAdapterGroup">

   2: ...

   3: </asp:Menu>

Again, the idea being that if you wanted just to fix up a page / control at a time to use specific adapters then this became possible.

However, as the owner of the feature I was never able to sell the rest of the team on this concept. So, my task in the next few days is to have this feature removed before Beta 2 ships…well, I liked it :-)

Thus ends the story of the disappearing feature…

Back to life…

Scott Galloway — Fri, 27 Mar 2009 17:11:25 GMT

TechDays MVC 4.0 Overview

TechDays MVC Presentation

Well, I’ve been back in the US for 5 days now, still really jet lagged but getting there; also managed to pick up a stomach bug at some point…Yes, I’m a hypochondriac!

The three weeks I spend travelling round Europe were really fun, I got to head home and see family for a couple of days as well as spend time in Helsinki, Finland, Antwerp, Belgium and Vasteras, Sweden.

The picture below is Peli de Halleux and myself standing on the frozen Baltic Sea…which a few minutes before we’d been swimming in!

The three TechDays conferences (twitter feed) were really fun, and my first chance to present to the people who use our products. I presented sessions on MVC as well as covering a lot of the stuff that’s in ASP.NET 4.0. By the end of the 6 talks (2 at each conference) I was pretty confident (always a challenger for me) and enjoying the experience.
Meeting our users is always fun, discovering how people are using our products and the problems they’re having (the #aspnetpain hashtag is partly the result of this).

I also got a chance to spend some ‘quality time’ with our 4.0 features as well as MVC. Oddly, I don’t get to spend as much time using our stuff as I’d like (my work day is packed with toommuch other stuff). Using our new WebForm Routing feature was a lot of fun; and gave me a bunch of ideas for making things easier (for example, currently it’s not great on DataBound controls; when Beta 1 rolls around I’ll post some extension methods here to make life easier). I also got to thinking a lot more about how people will advance their apps, maybe not to full MVC but a stepping stone to aid transition; using Routing, adopting an MVP pattern etc…

Of course I also got tom play with the MVC framework; which is a really fun way to build apps (like many others I rolled my own MVC / MVP frameworks in the past). The new scaffolding functionality Phil and the team added in RC1 really moves this framework to a whole different level for beginners. Frankly if I were building an app nowadays, I’d use MVC…

Anyway, now I’m back and catching up on work, always a lot to do…

NOTE: The PPTs at the top of the post presentations from TechDays, if you want to use them for anything, feel free! (The speaker notes in the first one are kinda rough, please don’t take them as ‘the official word!’

ASP.NET 4.0: Page.MetaKeywords and Page.MetaDescription simple, but useful!

Scott Galloway — Thu, 29 Jan 2009 15:49:47 GMT

One of the smaller additions we’ve made to ASP.NET 4.0 WebForms is the addition of two properties on the Page class, Page.MetaKeywords and Page.MetaDescription.
What these two properties do is provide access to / create meta tags within your page as follows:

    <title>Untitled Page</title>
    <meta name="keywords" content="These, are, my, keywords' />
    <meta name="description" content="This is the description of my page" />
</head>

Simple, right? In fact these two properties work the same way as Page.Title works:

1. If there are no meta tags in the head element matching the property names e.g., name=”keywords” for Page.MetaKeywords and name=”description” for Page.MetaDescription then we create these tags and fill in the string you entered as the content.
2. If there are already meta tags with these names we provide get / set access to the existing tags…

Of course you can set these in code, so the content could come from a DB to describe what you particular page is for etc…

Oh, and you can also set these in the Page tag at the top of your WebForm as follows:

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" Metaeywords="Hello" MetaDescription="This is my description" %>

This will override the meta tag contents (if any) already declared in the page.

Note, that the description in these tags is only really used for improving your snippets on Google, Google and Live don’t use the Keywords for anything but other search engines may.

A simple feature but it is pretty useful (and saves you messing about with adding these manually / writing your own code to create these.

ASP.NET 4.0: ViewStateMode…giving you more control over ViewState!

Scott Galloway — Wed, 28 Jan 2009 15:55:26 GMT

ViewState is a pain…there, I’ve said it! What causes the most pain with ViewState is the fact that people misuse it a lot, leaving it enabled for every control in a page when in fact you only really need it for that one control which really needs to persist it’s contents to the next page. Dave Reed a developer on the ASP.NET team has written a truly epic post on ‘Truly Understanding ViewState’, and before you read what comes next, you really should head off and read that first…

Back?

Ok, well now you understand that you should only use ViewState for those controls that actually need it. But there’s a problem…what you’d really like to do is turn off ViewState for an entire page then just turn it on again for the controls that need it, sorry but I have some bad news, you can’t do this in any version of ASP.NET up to and including ASP.NET 3.5 SP1. I also have some good news…you will be able to do this when ASP.NET 4.0 comes out! The magic little property on all ASP.NET Controls which lets you do this is called ViewStateMode. (Incidentally, this was Dave’s idea and the samples below are a shameless rip-off from him :-))

Put very simply, ViewStateMode has 3 possible values, Enabled, Disabled and Inherit. Which are pretty obvious in their function…Enabled turns saving ViewState on for that control (or any child controls which are set as ‘Inherit’ or have nothing set), Disabled turns it off again, and Inherit says ‘use whatever my parent is set to’. That’s really all there is to it!

Here’s a very simple sample of how this actually works:

   <form id="form1" runat="server">    
<script runat=”server”>
    protected override void OnLoad(EventArgs e) {
        if (!IsPostBack) {
            label1.Text = label2.Text = "[DynamicValue]";
        }
        base.OnLoad(e);
    }
</script>
<asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled">
    Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br />
    <asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled">
        Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" />
    </asp:PlaceHolder>
</asp:PlaceHolder>
<hr />
<asp:button ID="Button1" runat="server" Text="Postback" />

As you can see in this sample we’re Disabling ViewState for the PlaceHolder1 control, the child label1 Inherits this property (as Inherit is default) and therefore saves no ViewState…In PlaceHolder2 we set ViewStateMode to ‘Enabled’, which leads to label2 inheriting this property and therefore saves ViewState…On the first page load we set both labels to the output the text [DynamicValue]…

The effect of all this is that, when the Page first loads you see the labels rendered as follows:

Disabled: [DynamicValue]

Enabled: [DynamicValue]

But, do a PostBack and you see:

Disabled: [DeclaredValue]

Enabled: [DynamicValue]

As you’d now expect, the first label hasn’t preserved the value we set into ViewState…the second label has!

What’s really cool is the fact that you can also do this:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" ViewStateMode="Disabled" %>

Remember, in WebForms Page is just another control…it acts as the parent control for every other control in the page. This means that no control will save ViewState unless you set ViewStateMode to Enabled for that control or a control further up it’s control hierarchy (so, a great use would be for ContentPlaceHolders in MasterPages…).

Told you it was simple!

ASP.NET 4.0: Browser Capabilities Providers (esoterica warning!)

Scott Galloway — Mon, 26 Jan 2009 17:47:01 GMT

ASP.NET determines the capabilities of the browser with which a user is browsing your site using a feature called ‘browser capabilities’. In ASP.NET 3.5 SP1 there are two main ways in which you can define the capabilities which a browser has:

1. To make the change for your entire machine. Go into C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers, find the browser you want to alter, find the specific capability you want to alter in the XML, change it then run aspnet_regbrowsers.exe –I from the VS Tools command line to rebuild the Browser Capabilities assembly and add it to the GAC…

2. To make a change for just a specific application. Add a *.browser file into a folder called app_browsers within your application which specifies the browser (or default) to which you want to apply these capabilities.

As so can see, both of these approaches are pretty limited, in that you really have to change XML files ; and in the first case, you have to restart your app as part of the aspnet_regbrowsers.exe process. In ASP.NET 4.0 we have added a feature called BrowserCapabilities Providers which, as the name suggests, allows you to build a provider allowing you to use your own code to determine Browser Capabilities from your own data store.

Why would you want to do this, well, browser files are notoriously hard to update (the ASP.NET team really hasn’t touched them since ASP.NET 2.0), they’re pretty complicated to work with and well…they’re a strange XML syntax. Wouldn’t it be cool if there was a common Browser Definition syntax, or a database containing a huge number of new browser definitions…or even a web service. Before you really couldn’t use any of this with ASP.NET…now you can :-)

So, how do you use the new ASP.NET 4.0 Browser Capabilities Provider feature?

There are two main possibilities here, extend the ASP.NET Browser Capabilities definition functionality or totally replace it.

To replace the ASP.NET Browser Capabilities definition functionality:

1. Create a provider by sub-classing the HttpCapabilitiesProvider:

public class CustomProvider : HttpCapabilitiesProvider

{

public override HttpBrowserCapabilities

GetBrowserCapabilities(HttpRequest request)

{

HttpBrowserCapabilities browserCaps = new

HttpBrowserCapabilities();

Hashtable values = new Hashtable(180,

StringComparer.OrdinalIgnoreCase);

values[String.Empty] = request.UserAgent;

values["browser"] = "MyCustomBrowser";

browserCaps.Capabilities = values;

return browserCaps;

}

In this example we create a new HttpBrowserCapabilities object, specifying only the capability ‘browser’ to value ‘MyCustomBrowser’.

2. Register the provider with the application.

In order to use a provider within an application, you need to add the provider attribute to the browserCaps section in Web.config or Machine.config,
note: it is also possible to define this within a <location> tag for specific directories within the app; e.g., a specific mobile directory.

<system.web>

<browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2,

Version=1.0.0.0, Culture=neutral" />

</system.web>

Another way to ‘plug in’ the new BrowserCapabilities is to use code:

void Application_Start(object sender, EventArgs e)
{
HttpCapabilitiesBase.BrowserCapabilitiesProvider =
new ClassLibrary2.CustomProvider();
..
}

Note: This must be run in the Application_Start event as changing the BrowserProvider must happen before the first executes to ensure the cache remains in a valid state for the resolved HttpCapabilitiesBase object.

Adding Caching

The previous example has one major problem; this code would run on each call to get the HttpBrowserCapabilities which can happen multiple times in each request. For the example above it’s not really a big deal as we don’t really do much, but you can imagine that if your code does some significant work then this can be a huge overhead. So, how would you prevent this happening? Cache the HttpBrowserCapabilities object!

1. Again, create a provider by sub-classing the HttpCapabilitiesProvider:

public class CustomProvider : HttpCapabilitiesProvider

{

public override HttpBrowserCapabilities

GetBrowserCapabilities(HttpRequest request)

{

string cacheKey = BuildCacheKey();

int cacheTime = GetCacheTime();

HttpBrowserCapabilities browserCaps =

HttpContext.Current.Cache[cacheKey] as

HttpBrowserCapabilities;

If (browserCaps == null)

{

HttpBrowserCapabilities browserCaps = new

HttpBrowserCapabilities();

Hashtable values = new Hashtable(180,

StringComparer.OrdinalIgnoreCase);

values[String.Empty] = request.UserAgent;

values["browser"] = "MyCustomBrowser";

browserCaps.Capabilities = values;

HttpContext.Current.Cache.Insert(cacheKey,

browserCaps, null, DateTime.MaxValue,

TimeSpan.FromSeconds(cacheTime));

}

return browserCaps;

}

In the code above, in order to improve performance for each subsequent request we generate a cache key using their own BuildCacheKey() as well as the length of time to cache returned from their own GetCacheTime() method to enter the resolved HttpBrowserCapabilities object into cache and can then reuse this object on subsequent requests with matching User Agent string.

2. Register the provider with the application. See previous example.

Extending ASP.NET’s Browser Capabilities’ functionality

Great, so now we know how to create a new HttpBrowserCapabilities object which ASP.NET 4.0 uses. What about extending ASP.NET’s Browser Capabilities functionality by adding new Browser Capabilities definitions to those ASP.NET currently ships with…WITHOUT using the XML definitions we mentioned previously?

1. To generate a Browser Capabilities Provider we create a class inheriting from the HttpCapabilitiesDefaultProvider as follows:

public class CustomProvider : HttpCapabilitiesDefaultProvider

{

public override HttpBrowserCapabilities

GetBrowserCapabilities(HttpRequest request)

{

HttpBrowserCapabilities browserCaps =

base.GetHttpBrowserCapabilities(request);

if (browserCaps.Browser == "Unknown")

{

browserCaps = MyBrowserCapabilitiesEvaulator(request);

}

return browserCaps;

}

Here we first use ASP.NET’s Browser Capabilities functionality to try and identify the browser, however if no browser was identified based on the information defined in the request. In this code, we check for the browser being unidentified by checking for the string “Unknown’ in the HttpBrowserCapabilities.Browser property and then we call into our own code (MyBrowserCapabilitiesEvaluator) to identify the correct browser using the information contained in the request.

3. Register the provider with the application. See the first example.

Adding new Capabilities to Existing Browser Capabilities Definitions

1. To generate a Browser Capabilities Provider the developer would create a class inheriting from the HttpCapabilitiesEvaluator as follows:

public class CustomProvider : HttpCapabilitiesDefaultProvider

{

public override HttpBrowserCapabilities

GetBrowserCapabilities(HttpRequest request)

{

HttpBrowserCapabilities browserCaps =

base.GetHttpBrowserCapabilities(request);

browserCaps.Frames = true;

browserCaps.Capabilities["MyCapability"] = "Bob";

return browserCaps;

}

In this case we have extended the shipped HttpCapabilitiesDefaultProvider class and obtained the HttpBrowserCapabilities object which the base method returns:

HttpBrowserCapabilities browserCaps =

base.GetHttpBrowserCapabilities(request);

By accessing the base method we are able to access the existing HttpBrowserCapabilities definition and add / modify a capability for this browser in their own code.

Note: There are two ways of specifying a browser capability:

1. The HttpCapabilitiesBase object contains an IDictionary names ‘Capabilities’, the developer can add any value to this discionary e.g, in this case adding a capability called ‘MyCapability’ with the value ‘Bob’.

2. The second is through the use of properties on the HttpCapabilitiesBase object, in the case above the developer sets the value of ‘Frames’ to ‘true’; in reality this is in fact an accessor for the Capabilities IDictionary and adds / retrieves this property from that IDictionary.

Note: This model applies to any property of HttpBrowserCapabilities, including Control Adapters.

2. Register the provider with the application. See the first example…

ASP.NET 4.0: WebForm Routing (quick ’n dirty version)

Scott Galloway — Mon, 26 Jan 2009 02:13:58 GMT

NOTE: This is a quick introduction,. I’ll drill into this more in a future post.

One of the things we’re adding in ASP.NET 4.0 is built-in support for using Routing together with WebForms. Now, I’m totally aware that this is possible to do already and that a number of people have posted ways of doing this with the Web Routing feature which shipped with ASP.NET 3.5 SP1. We’re just adding some features to make it easier to do…

So, what are we adding?

WebFormRouteHandler, this is a simple HttpHandler which you use in defining your routes…it essentially takes care of passing data into the page you’re routing to.
Adding HttpRequest.RequestContext and Page.RouteData (this is really just a proxy onto the HttpRequest.RequestContext.RouteData object). Makes it easier to access information passed from the Route.
ExpressionBuilders:
1. RouteUrl (in System.Web.Compilation.RouteUrlExpressionBuilder), a simple way to create a URL corresponding to your route URL format within an ASP.NET Server Control
2. RouteValue (again, in System.Web.Compilation.RouteValueExpressionBuilder), a simple way to extract information from the RouteContext.
RouteParameter, a DataSource parameter which lets you easily pass data contained in RouteContext into a query for a DataSource…like FormParameter.

So, how does all this fit together?

WebFormRouteHandler

First, let’s define the new WebForm route…as follows:

public class Global : System.Web.HttpApplication

{

protected void Application_Start(object sender, EventArgs e)

{

RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}", new WebFormRouteHandler("~/search.aspx")));

RouteTable.Routes.Add("UserRoute", new Route("users/{username}", new WebFormRouteHandler("~/users.aspx")));

}

As you can see, we simply map the Route onto a physical page (in the first string, “~/search.aspx”), we’ve also said that the parameter ‘searchterm’ should be extracted from the URL and passed into the page.

We also support an additional parameter for WebFormRouteHandler, the signature is as follows:

WebFormRouteHandler(string virtualPath, bool checkPhysicalUrlAccess);

The ‘checkPhysicalUrlAccess’ parameter specifies whether the RouteHandler should check the perrmissions for the physical page you’re routing to (in the case above, search.aspx) as well as the incoming Url…this defaults to ‘true’.

HttpRequest.RequestContext and Page.RouteData

Now that you’re in the physical page, how do you go about accessing the information which the Routing system has extracted from the Url (or, an object which some other object has added to the RouteData)?

As I mentioned before, we’ve added two methods…HttpRequest.RequestContext and Page.RouteData. Where Page.RouteData is just a convenience method onto HttpRequest.RequestContext.RouteData

This lets us do the following:

protected void Page_Load(object sender, EventArgs e)

{

string searchterm= Page.RouteData.Values["searchterm"] as string;

Response.Write(searchterm);

}

Here, we’re just extracting the value we passed in for ‘searchterm’ defined in the Route above.

Given the url http://localhost/search/scott/ , this would output the word ‘scott’ into the page…

So, nice…that’s how we’d do it in code…but what about Markup?

RouteUrl and RouteValue expression builders

ExpressionBuilders have been described as a ‘hidden gem of ASP.NET’, and that’s a shame…because they’re actually pretty cool. We’ve implemented two new expression builders for WebForm routing. They’re used as follows:

<asp:HyperLink ID="HyperLink1" runat="server" NavigateUrl="<%$RouteUrl:SearchTerm=Bob%>">Link to search</asp:HyperLink>

Here we’re using the RouteUrl expressionbuilder to work out our Url based on a route parameter…the reason for doing this is to save having to hard code in our Url structure into our markup…this of course lets us change the URL structure later.

Based on the route we defined previously, this would generate the Url: ‘http://localhost/search/bob’, one thing to note is that we automatically work out the correct route based on the input parameters…you can also name the route in this expressionbuilder which lets you define a specific route url definition to use.

RouteValue is used like so:

<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />

Pretty simple right? Yes, but it avoids you having to mess around with the more complex Page.RouteData[“x”] in your markup…

In this case we’d get the value ‘scott’ inserted into our label’s text element.

RouteParameter

Well, just use it like FormParameter e.g.,

<asp:sqldatasource id="SqlDataSource1" runat="server" connectionstring="<%$ ConnectionStrings:MyNorthwind %>"

selectcommand="SELECT CompanyName,ShipperID FROM Shippers where CompanyName=@companyname"

<asp:routeparameter name="companyname" RouteKey=”searchterm” />

</selectparameters>

</asp:sqldatasource>

I this case we extract the Route parameter ‘searchterm’ and pass it into the select statement.

Well, that’s it for this whistle-stop tour of our new ASP.NET 4.0 WebForm routing feature…

ASP.NET 4.0: Way too much information on Control IDs and ASP.NET 4.0 Client Id Enhancements

Scott Galloway — Mon, 03 Nov 2008 21:41:30 GMT

Of of the ASP.NET enhancements which first made an appearance in the Visual Studio 2010 PDC CTP release is the ability to set a client Id which you can be confident will be used when the control renders it’s markup.
All of the samples in this post will use the following Server Control:

using System.Web.UI;

using System.Web.UI.WebControls;

namespace TestControls

{

public class NamingPanel : Panel, INamingContainer

{ }

}

NamingPanel is very simple server control which just enables us to see the effect of ClientId without all the cruft that goes with using a more complex control (e.g, GridView).

Message from TestKing

Testking offers the featured resources for providing mcitp training , mcts courses and a+ certification materials.

How does the Control Id get defined now?

When used with a ‘nested’ NamingPanel, the following markup:

<tc:NamingPanel runat="server" id="rootPanel"> 
  <tc:NamingPanel runat="server" id="childPanel1"> 
    <asp:TextBox ID="TextBox" runat="server" Text="Hello!"></asp:TextBox> 
  </tc:NamingPanel> 
</tc:NamingPanel>

results in this rendered HTML:

<div id="Div1">  
  <div id="rootPanel_childPanel1"> 
     <input name="rootPanel$childPanel1$TextBox" type="text" value="Hello!" id="rootPanel_childPanel1_TextBox" /> 
  </div> 
</div>

As you can see the id “TextBox” defined in the original markup gets mangled to preserve ‘uniqueness’ by including the Ids of it’s parent controls within it’s own id attribute.

Whilst making the id attribute ‘unique’ does ensure that we can ensure that selecting a specific control client side using the id attribute will result in a single control, it does tend to get a bit verbose; the example above is only 2 levels deep, with more nesting; or even just using a control in Nested MasterPages can result in hugely long values for the Client Id…

The second major problem with the ‘unique’ Client Ids is that you can’t guarantee that your client Id will remain the same if you move a control from one ‘NamingContainer’ to another.

NOTE: A NamingContainer is a control which either directly or indirectly implements the INamingContainer interface. In essence it defines a ‘NameSpace’ for controls…you’d most commonly implement this interface on Composite Server Controls to ensure that any of the contained child controls are rendered with the parent ids prefixing their own Ids, ensuring they remain unique within the page.

What happens if you don’t specify an ‘id’ for one of these parent controls in markup? Given the following markup:

<tc:NamingPanel runat="server" id="rootPanel"> 
  <tc:NamingPanel runat="server"> 
    <asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox> 
  </tc:NamingPanel> 
</tc:NamingPanel>

results in this rendered HTML:

  <div id="Div2">
    <div>
        <input name="rootPanel$ctl00$TextBox" type="text" value="Hello!" id="rootPanel_ctl00_TextBox" />
    </div>
</div>

Taking a look at the id for the TextBox you can see that there’s an odd name inserted in the id attribute “ctl00”, where did this come form? Well, in the System.Web.UI.Control class there’s a declaration as follows (note, this and all other source in the post is from the ASP.NET 2.0 source using Reflector):

private static readonly string[] automaticIDs = new string[] {

"ctl00", "ctl01", "ctl02", "ctl03", "ctl04", "ctl05", "ctl06", "ctl07", "ctl08", "ctl09", "ctl10", "ctl11", "ctl12", "ctl13", "ctl14", "ctl15",

"ctl16", "ctl17", "ctl18", "ctl19", "ctl20", "ctl21", "ctl22", "ctl23", "ctl24", "ctl25", "ctl26", "ctl27", "ctl28", "ctl29", "ctl30", "ctl31",

"ctl32", "ctl33", "ctl34", "ctl35", "ctl36", "ctl37", "ctl38", "ctl39", "ctl40", "ctl41", "ctl42", "ctl43", "ctl44", "ctl45", "ctl46", "ctl47",

"ctl48", "ctl49", "ctl50", "ctl51", "ctl52", "ctl53", "ctl54", "ctl55", "ctl56", "ctl57", "ctl58", "ctl59", "ctl60", "ctl61", "ctl62", "ctl63",

"ctl64", "ctl65", "ctl66", "ctl67", "ctl68", "ctl69", "ctl70", "ctl71", "ctl72", "ctl73", "ctl74", "ctl75", "ctl76", "ctl77", "ctl78", "ctl79",

"ctl80", "ctl81", "ctl82", "ctl83", "ctl84", "ctl85", "ctl86", "ctl87", "ctl88", "ctl89", "ctl90", "ctl91", "ctl92", "ctl93", "ctl94", "ctl95",

"ctl96", "ctl97", "ctl98", "ctl99", "ctl100", "ctl101", "ctl102", "ctl103", "ctl104", "ctl105", "ctl106", "ctl107", "ctl108", "ctl109", "ctl110", "ctl111",

"ctl112", "ctl113", "ctl114", "ctl115", "ctl116", "ctl117", "ctl118", "ctl119", "ctl120", "ctl121", "ctl122", "ctl123", "ctl124", "ctl125", "ctl126", "ctl127"

};

As you can see this defines an array containing some predefined IDs to be used when no id is specified for a control; again, this retains uniqueness for control names. At runtime the ID for the control is generated by reading the ‘UniqueID’ property of the Control class.

public virtual string UniqueID

{

get

{

if (this._cachedUniqueID == null)

{

Control namingContainer = this.NamingContainer;

if (namingContainer == null)

{

return this._id;

}

if (this._id == null)

{

this.GenerateAutomaticID();

}

if (this.Page == namingContainer)

{

this._cachedUniqueID = this._id;

}

else

{

string uniqueIDPrefix = namingContainer.GetUniqueIDPrefix();

if (uniqueIDPrefix.Length == 0)

{

return this._id;

}

this._cachedUniqueID = uniqueIDPrefix + this._id;

}

return this._cachedUniqueID;

}

As you can see this code has the following check:

if (this._id == null)

{

this.GenerateAutomaticID();

}

Simply, if there’s no id already in existence for the control at render time then one is generated using a call to the following method:

private void GenerateAutomaticID()

{

this.flags.Set(0x200000);

this._namingContainer.EnsureOccasionalFields();

int index = this._namingContainer._occasionalFields.NamedControlsID++;

if (this.EnableLegacyRendering)

{

this._id = "_ctl" + index.ToString(NumberFormatInfo.InvariantInfo);

}

else if (index < 0x80)

{

this._id = automaticIDs[index];

}

else

{

this._id = "ctl" + index.ToString(NumberFormatInfo.InvariantInfo);

}

this._namingContainer.DirtyNameTable();

}

As you can see, this method simply looks at the specified array of control names for the next ’ctlXXX’ value until it runs out then it generates one. The ctlXXX ‘counter’ restarts for each NamingContainer…so it’s pretty unlikely you’ll get to the end of the static array of control names. The ‘automaticIDs’ array is used simply as a performance optimization…saving even this very simple piece of code from running on each control rendering.

So What’s With the Control’s ‘Name’

In the examples in the previous section you can see that there’s not just an Id attribute, rather there’s also a ‘name’ attribute for each control, e.g., “rootPanel$childPanel1$TextBox". You’ll see that this looks really similar to the Id property (and is in fact generated using almost an identical code-path), so why are there two different attributes. In the simplest explanation, consider the ‘name’ attribute to be the ‘server side’ name and the ‘id’ attribute to be the client side one.

When you “post’ or ‘get’ a form in HTML the ‘name’ attribute links the specific HTML control to the value which gets posted back; this is where the ‘uniqueness’ part comes in. By being unique it’s possible to hook up the posted value back to the Control on the server, in addition this also specifies the correct event to call on postback.

NOTE: While in current ASP.NET, it’s possible to translate from the name attribute to the id attribute this is not guaranteed and will most likely break when using the new ASP.NET 4.0 functionality. We will not alter the ‘name’ attribute in ASP.NET 4.0…

Client Ids in DataBound Controls

The most critical reason for ensuring rendered controls have unique id attributes is controls within Data Bound controls. As an example the following markup defines a simple ListView hooked up to the Northwind database:

<tc:namingpanel runat="server" id="rootPanel">

      <tc:NamingPanel runat="server">

          <asp:SqlDataSource ID="SqlDataSource2" runat="server" ConnectionString="<%$ ConnectionStrings:ConnectionString %>"

              SelectCommand="SELECT [ProductName] FROM [Alphabetical list of products]"></asp:SqlDataSource>

          <asp:ListView ID="ListView2" runat="server" DataSourceID="SqlDataSource1"

              onselectedindexchanged="ListView1_SelectedIndexChanged">

              <ItemTemplate>

                  <tr style="">

                      <td>

                          <asp:Label ID="ProductNameLabel" runat="server"

                              Text='<%# Eval("ProductName") %>' />

                      </td>

                  </tr>

              </ItemTemplate>

                  <LayoutTemplate>

                  <table id="Table2" runat="server">

                      <tr id="Tr4" runat="server">

                          <td id="Td3" runat="server">

                              <table ID="itemPlaceholderContainer" runat="server" border="0" style="">

                                  <tr id="Tr5" runat="server" style="">

                                      <th id="Th2" runat="server">

                                          ProductName</th>

                                  </tr>

                                  <tr ID="itemPlaceholder" runat="server">

                                  </tr>

                              </table>

                          </td>

                      </tr>

                      <tr id="Tr6" runat="server">

                          <td id="Td4" runat="server" style="">

                          </td>

                      </tr>

                  </table>

              </LayoutTemplate>

          </asp:ListView>

      </tc:NamingPanel>

</tc:namingpanel>

The markup above has the ListView inside the NamingPanels we had previously. This markup generates the following HTML (or a snippet of it…)

<table id="rootPanel_ctl00_ListView1_itemPlaceholderContainer" border="0" style="">

       <tr style="">

          <th>

               ProductName

          </th>

       </tr>

       <tr style="">

          <td>

            <span id="rootPanel_ctl00_ListView1_ctrl0_ProductNameLabel">Chai</span>

          </td>

       </tr>

</table>


As you can see, the controls in the ListView are rendered using a mix of user-defined as well as auto-generated ids…this is great for ensuring the names are unique but pretty useless if you need to know the ids of the controls at render time…As an example it’s really difficult to ensure that client side code such as Javascript can easily identify a specific control within the page without mixing in the classic <%=Control.ClientId%> server side markup into the JS.

NOTE: Databound controls are more difficult than usual when trying to ensure unique control Ids you only have access to some of the container controls at design-time (e.g., ctrl0 in the above html is not accessible in the designer…so you can’t change the id without hooking into backend events).

More Control over Control Ids…ASP.NET 4.0 Client Ids

So, what are we doing in ASP.NET 4.0 to let you define the ids?

NOTE: The information below is different to the Visual Studio 10 PDC CTP VPC (love those acronyms!). Following the CTP release we refactored to remove the ‘set’ on the ClientId property…this is to improve the behavior of the API, previously the value you got back from ClientId would almost certainly not match the value you set. In the new API you set the Id parameter and can then ‘get’ the ClientId property…

IMPORTANT: The new Client Id functionality has no impact on the server side name of the control, so string myString = TextBox1.Text; is completely unaffected by the Client Id changing.

In order to enable you to have more control over Client Ids we added a of property on ‘System.Web.UI.Control’:

ClientIdMode

Legacy – This is exactly equivalent to the ASP.NET 2.0 Client Id behavior. This is also the default if no ClientIdMode property is set in the current control’s hierarchy.

Static – You set it, you get it…most controllable but potentially the least ‘safe’. If a control is set to ‘static’ ClientIdMode then exactly what you set for Id is used as the client id, no matter what naming container the control sits in.

Predictable – Mostly for use in DataBound controls, only uses ‘set’ Id attributes of parent Naming Containers (so, no automatic id generation using ‘ctlXXX’ names). This also works in conjunction with the DataBound control property RowClientIdSuffix to allow you to define the ‘uniquefying’ item for the specific row. Previously, the auto-generated name ctrl0…ctrl1…ctrl2…etc…was used to provide this uniqueifying function for controls in the rows of DataBound controls.

Inherit - Essentially the ‘default’ behavior for controls, explicitly setting ClientIdMode = ‘Inherit’ essentially clears the ClientIdMode for the current control and allows this and any child controls (which have either ‘Inherit’ as ClientIdMode or ClientIdMode not set) will take the ClientIdMode of any parent control (including Page and Config…see below)

Page

You can also set the ClientIdMode at Page level, this defines the default ClientIdMode for all controls within the current page…

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" ClientIdMode="Static"%>

Config

It’s also possible to set the ClientIdMode in the config section at either machine or application level…this defines the default ClientIdMode for all controls within all pages in the application.

<system.web>
<pages clientIdMode="Predictable"></pages>
</system.web>

So what can I do with that?
Restarting Control Naming
As mentioned earlier the client id for a control is derived from the NamingContainers in which the control sits in the Control Hierarchy, normally this is only the actual controls within the page (e.g., in DataBound controls), however when using MasterPages you can end up with ids as found in the following HTML:

    <div id="ctl00_ContentPlaceHolder1_ParentPanel">
        <div id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1">
            <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" type="text" value="Hello!" id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1" />
    </div>

Even though the TextBox shown in the HTML is only within two NamingContainers within the page, due to the way MasterPages hook together you wind up with a control id like the following: ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1

Obviously this is a pretty long id…guaranteed unique within the page but unnecessarily long for most purposed. In this example we now want to reduce the length of the rendered id and make it more user defined (so, shortened, no ctlXXX etc…). The easiest way to achieve this is the following

<tc:NamingPanel runat="server" ID="ParentPanel" ClientIdMode="Static">
    <tc:NamingPanel runat="server" ID="NamingPanel1" ClientIdMode=”Predictable">
        <asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox>
    </tc:NamingPanel>
</tc:NamingPanel>

In this sample (identical to earlier markup) we’ve set the ClientIdMode to ‘Static’ on the outermost NamingPanel as well as setting the next ‘Child’ control to ‘Predictable’. This results in this markup (note, the rest of the page, MasterPages etc,…is identical to the previous example)

            <div id="ParentPanel">
        <div id="ParentPanel_NamingPanel1">
            <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" />
    </div>
Here we’ve essentially restarted the naming hierarchy for Controls to the outermost NamingPanel , eliminating the ContentPlaceHolder and MasterPage names from the id (note: the ‘name’ attribute is unaffected…meaning we retain the normal ASP.NET functionality for events, ViewState etc…). A nice side-effect of restarting the naming hierarchy is that even if the markup defining the NamingPanels is moved to a different ContentPlaceholder, the rendered Client Ids remain the same.

NOTE: The developer does now take more responsibility for ensuring that rendered Control Ids are unique…not doing so can break functionality which expect to find unique HTML elements for each Id (e.g., Javascript’s GetElementById()).

Predictable DataBound Client Ids
As we showed previously, the Client Ids generated for Controls within DataBound list controls are pretty messy and not really predictable…How does the new Client Id functionality help?

We want to achieve the following:

Shorten the Client Ids for Controls
Make the Client Id predictable
Make the Client Id unique across pages (rather than ‘within’ pages)
So, how do we do this?

<tc:NamingPanel runat="server" id="rootPanel">

      <tc:NamingPanel runat="server">

          <asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="<%$ ConnectionStrings:ConnectionString %>"

              SelectCommand="SELECT [ProductName], [ProductID] FROM [Alphabetical list of products]"></asp:SqlDataSource>

          <asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1"

              onselectedindexchanged="ListView1_SelectedIndexChanged" ClientIdMode=”Predictable” ClientIdRowSuffix=”ProductID”>

              <ItemTemplate>

                  <tr style="">

                      <td>

                          <asp:Label ID="ProductNameLabel" runat="server"

                              Text='<%# Eval("ProductName") %>' />

                      </td>

                  </tr>

              </ItemTemplate>

                  <LayoutTemplate>

                  <table id="Table1" runat="server">

                      <tr id="Tr1" runat="server">

                          <td id="Td1" runat="server">

                              <table ID="itemPlaceholderContainer" runat="server" border="0" style="">

                                  <tr id="Tr2" runat="server" style="">

                                      <th id="Th1" runat="server">

                                          ProductName</th>

                                  </tr>

                                  <tr ID="itemPlaceholder" runat="server">

                                  </tr>

                              </table>

                          </td>

                      </tr>

                      <tr id="Tr3" runat="server">

                          <td id="Td2" runat="server" style="">

                          </td>

                      </tr>

                  </table>

              </LayoutTemplate>

          </asp:ListView>

      </tc:NamingPanel>

</tc:NamingPanel>

In the markup above, we have used the ClientIdMode and ClientIdRowSuffix properties. ClientIdRowSuffix is a property which can only be used in DataBound controls and actually differs based on the DataBound control it’s used with:

GridView: You can specify the name of a column in the DataSource or multiple columns which are then combined at runtime. As an example if you specified ClientIdRowSuffix as “ProductName, ProductId” in a GridView then the rendered control Id would be "rootPanel_GridView1_ProductNameLabel_Chai_1”.

ListView: You can specify a single column in the DataSource which will be appended to the Client Id. As an example if you specified ClientIdRowSuffix as “ProductName” in a ListViewthen the rendered control Id would be "rootPanel_ListView1_ProductNameLabel_1”. In this case the last ‘1’ comes from the ProductId of the DataItem.

Repeater: No ClientIdRowSuffix property is allowed. In a Repeater the index of the Row is used. In the case above, you would wind up with "rootPanel_Repeater1_ProductNameLabel_0”. The ‘0’ is simply the index of the current row.

Note: FormView, DetailsView do not have multiple rows so do not have a ClientIdRowSuffix property.

Conclusion

So, there you have it…I dare say I’ll post again in future about this topic, we have a sample app which will find it’s way onto Codeplex in the near future!

Matthew Osborn from our QA team has also posted on this stuff…

NOTE: In current CTP builds you cannot use UpdatePanels with controls when you use the new Client Id functionality. This is fixed internally and will work correctly in future public releases.