posts - 897, comments - 685, trackbacks - 11

My Links



Post Categories

Misc. Coding

The strange case of the disappearing Feature: AdapterGroup

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…

Print | posted on Monday, April 27, 2009 9:07 AM | Filed Under [ ASP.NET 4.0 ]


# re: The strange case of the disappearing Feature: AdapterGroup

That's too bad!

This would have been very useful in SharePoint to enable Adapters for the content but not for the administration part.
4/28/2009 8:26 AM | Mel

# re: The strange case of the disappearing Feature: AdapterGroup

Thanks for your post.

That would have been a very useful feature. Too bad they decideded to remove it.

I am guessing we can still use Adapters in 4.0, just AdapterGroup feature will not provided, right?
4/28/2009 11:07 AM | Sonny

# re: The strange case of the disappearing Feature: AdapterGroup

too bad. will be very usefull to brand wss v3 website.... maybe in 5 :-)
5/15/2009 9:52 AM | Ludovic Lefort

Post Comment

Please add 7 and 3 and type the answer here:

Powered by: