ASP.NET server controls are designed to accept property values from hosting pages and generate a chunk of markup to be incorporated in the HTTP response. As a page developer, though, you have no way to override such a hard-coded behavior. All that you can do — and it is not minor after all — is deriving a custom control and override the rendering engine to match your expectations. Deriving a custom control, though, may require a different skill set that not all Web page authors have.
Overall, deriving a new control from an existing one prefigures a relatively advanced approach to customization. You need to have a good reason to derive and use a custom control. There's some complexity involved with custom controls — deployment of a new assembly, maintenance of the related source code, testing.
What if you want to change the output of a built-in ASP.NET control on a page basis, that is without deriving a new control? Admittedly, this is not a task you face every day. However, it is still a question that guru developers can expect to be asked eventually. So what's the answer?
The System.Web.UI.Control class in ASP.NET supplies a method name SetRenderMethodDelegate which has the following prototype:
public void SetRenderMethodDelegate (RenderMethod renderMethod)
The method takes one argument representing the method that renders the specified control to the specified HTML text writer. The class RenderMethod is a delegate expressed as below:
public delegate void RenderMethod ( HtmlTextWriter output, Control container )
As the naming in the prototype may suggest, this approach won't work with just any control. Only container controls can take advantage of this hook technique. What are container controls? This is a hard question to answer. In general, a container control is just any control that happens to have children. In particular, as far as render delegates are concerned, being a container is a status that depends on the internal implementation of individual controls. For example, a Button and Label control is not a container per se; but what if you add child controls programmatically?
Label1.Controls.Add(new Control()); Button1.Controls.Add(new Control());
According to the previous definition, both Label1 and Button1 are containers. Nevertheless, only the Label control will successfully handle a render delegate. On the other hand, the SetRenderMethodDelegate method is considered an internal implementation detail and is not officially part of the public ASP.NET API open to developers. Still, the method is public, and you can use it — but at your own risk and provided that you know how to handle it.
The key fact is that ASP.NET controls are not consistent about how they support render delegates. The Control.Render method checks render delegates and invokes them if any. However, most ASP.NET controls override the Render method and some of them omit calling base.Render. For this reason, even though the support for rendering delegates is part of the framework, it is not supported by all controls. This is what happens with the Button control. The Label control, instead, does override the Render method. It doesn't call into the Control's implementation of the method, but still checks personally if any render delegate is registered. However, it does this only if child controls are found.
There's just one scenario in which the SetRenderMethodDelegate method is helpful — when you need to hook up the page rendering. The render delegate is used to handle ASP-style code blocks <% ... %> and in ASP.NET Ajax to implement page methods. If you're looking for a technique that lets you modify the output of a production page — without touching the source code — then render delegates are your best friends.
