Each ASP.NET server control generates its own markup through a well-known and rigorously defined rendering engine. How can you modify the output of a control? By creating your own version of a given control—say, MyGridView—you can override every single method and property that is declared overridable as well as shadow existing members and replace them with your own ones. Put another way, when you derive a new control from an existing one you have the power of doing virtually everything that the base control doesn't explicitly and strictly prohibit. Can you therefore consider yourself happy and satisfied and start right away duplicating all controls in the ASP.NET toolbox? Not necessarily.
All ASP.NET controls have their entry point in the rendering engine in the Render method. Here's the method's signature as defined by the System.Web.Control class—the parent of all ASP.NET control classes.
protected virtual void Render(HtmlTextWriter writer)
{
:
}
ASP.NET controls are partitioned in sub-groups such as data-bound controls, Web controls, HTML controls, validation controls. Each group defines a root class that typically overrides the Render method to supply more specific overridable methods for the derived controls. In the end, the first option that springs to mind when you need to modify the returned markup of a control is creating a custom control and overriding its rendering engine.
While this solution delivers a great deal of flexibility, it is far from perfect. What's its biggest drawback? It forces you, as a developer, to improve your control development skills and create custom controls to use in lieu of the original ones. Starting with version 2.0, ASP.NET supports the concept of an adapter component to do the job of rendering the markup. Nicely enough, a control adapter is a configurable component that you can unplug in any application to roll your own. The aforementioned Render method available for all controls ends up calling the RenderControl method—another protected and overridable method. The default implementation is nearly identical to the following pseudo-code:
void RenderControlInternal(HtmlTextWriter writer,
ControlAdapter adapter)
{
if (adapter != null)
{
adapter.BeginRender(writer);
adapter.Render(writer);
adapter.EndRender(writer);
}
else
{
this.Render(writer);
}
}
Where does it take us? Quite simply, it means that if a control adapter is defined, it will be used to generate the markup for the control. The adapter can be declaratively specified and is an external component that can be made to measure for your needs.
Using an adapter to alter the markup of a given class of controls is an unobtrusive option that doesn't require any changes to existing pages using that control. It only requires you to add a configuration file with a .browser extension.
Browser definition files have a .browser extension and contain definitions that apply to a specific browser. At run time, ASP.NET determines the browser being used, uses the configuration file to determine the capabilities of the browser, and based on that figures out how to render markup to that browser. Here's how to register a control adapter for the Menu control that works with any browser:
<browsers>
<browser refID="Default">
<controlAdapters>
<adapter controlType="System.Web.UI.WebControls.Menu"
adapterType="Samples.YourMenuAdapter" />
:
<controlAdapters>
</browser>
</browsers>
This configuration script must be saved to a .browser file deployed to the App_Browsers folder of an ASP.NET application version 2.0 or superior. What's an adapter class, anyway? It looks like this:
public class MenuAdapter :
System.Web.UI.WebControls.Adapters.MenuAdapter
{
:
}
The class commonly overrides methods like Init, RenderBeginTag, RenderEndTag, and RenderContents.
Adapters are an excellent way to modify the output of system and custom controls without touching the pages that use them and without altering the public interface of the control. To write an adapter, though, the developer must reasonably know a lot of details about the internal working of the control he or she is going to hook up. For more information on the architecture of control adapters, take a look at Architectural Overview of Adaptive Control Behavior .
