It seems to many that the days of ASP.NET Web Form Server Controls have just about come to an end. The problem many people have with Server Controls is that they have a pretty high 'concept count' in their construction. The arrival of ASP.NET MVC with it's deliberate decision to eschew Server Controls in favor of very simple 'HTML Helpers' and simple inline markup generation seemed to put the final nail in the coffin of these old war-horses of ASP.NET.
Whilst writing a chapter in a book I'm working on about ASP.NET 4, I got to thinking about a Server Control prototype I worked on last year...the ServerControlWithSprinklesAndBacon. In essence the SCWSB (as it will hereon be called) was a vastly over engineered attempt to answer a simple requirement:
Is it possible for a Server Control to change it's design & run time behaviors based on the adapter the user has selected.
Why on earth would I want to do this? Well, one of the changes we made for ASP.NET 4 is in improving the CSS and Rendering behaviors of a number of our Server Controls which ship with ASP.NET. In an earlier incarnation of this work, we looked at doing this using Control Adapters; a feature which switches out the runtime code used to generate the HTML for a control. As it turned out, we decided to go in a different direction for achieving this (which does not use control adapters) as it was felt that Control Adapters introduced too much complexity into the mix.
Originally, you would have been able to specify the Control Adapter to use for a specific control within a page at runtime (in fact, you could use another feature called 'Adapter Groups' to define them at almost any level from app right through to control...but I digress). The main use for Control Adapters was to be in allowing you to use alternate rendering behaviors, think, more CSS Friendly HTML or even totally different markup.... A problem with this was that one of the most fundamental features of Server Controls, Designer support would be lost when taking this approach. In fact in ASP.NET 4, you *do* lose a lot of designer functionality when using the controlRenderingCompatabilityVersion="4.0" setting, for example, AutoFormats no longer work for most controls.
Anyway, this lack of designer support for changing control adapters on a specific control bugged me to no end...and I spent a number of sleepless nights working on the problem. In the end here's what I wanted to achieve:
- Add support for 'designer' control adapters, so rather than just runtime, control adapters also changed design time HTML.
- Work out how to change the items in the Property Grid for a control based on the selected control adapter (so, hide some that no longer apply and add some new ones)
- Make them easy to use...
In looking at these requirements, I needed to plumb the (relatively unexplored) depths of the ASP.NET Server Control framework, use some features in ways they were never really supposed to be used and discover way more about how Server Controls interact with the VS.NET design surface than anyone really should...in Part 2 I'll take you on that journey and show you how I came up with the ServerControlWithSprinklesAndBacon...Â