All ASP.NET controls from version 2.0 can be associated with a
control adapter. A
control adapter is a class that inherits from ControlAdapter and it has
the chance to interact with
the control(s) it is targeting so as to change some of its properties or alter its output. I talked about
control adapters before and they really a cool feature.
The ControlAdapter class exposes virtual methods for some well known lifecycle
events, OnInit, OnLoad, OnPreRender and OnUnload that closely match their
Control counterparts, but are fired before them. Because
the control adapter has a reference to its target
Control, it can cast it to its concrete class and do something with it before its lifecycle
events are actually fired.
The adapter is also notified before
the control is rendered (BeginRender), after their children are renderes (RenderChildren) and after itself is rendered (Render): this way
the adapter can modify
the control’s output.
Control adapters may be specified for
any class inheriting from
Control, including abstract classes, web server controls and even pages. You can, for example, specify a
control adapter for
the WebControl and UserControl classes, but, curiously, not for
Control itself. When specifying a
control adapter for a page, it must inherit from PageAdapter instead of ControlAdapter.
The adapter for a
control, if specified, can be found on
the protected Adapter property, and for a page, on
the PageAdapter property.
The first use of
control adapters that came to my attention was for changing
the output of standard ASP.NET web controls so that they were more based on CSS and less on HTML tables: it was
the CSS Friendly
Control Adapters project, now available at http://code.google.com/p/aspnetcontroladapters/. They are interesting because you specify them in one location and they apply anywhere a
control of
the target type is created. Mind you, it applies to controls declared on markup as well as controls created by code with
the new operator. So, how do you use
control adapters?
The most usual way is through a browser definition file. In it, you specify a set of
control adapters and their target controls, for a given browser. This browser definition file is a XML file with extension .Browser, and can either be global (%WINDIR%\Microsoft.NET\Framework64\vXXXX\Config\Browsers) or local to
the web application, in which case, it must be placed inside
the App_Browsers folder at
the root of
the web site. It looks like this: 1: <browsers>
2: <browser refID="Default">
3: <controlAdapters>
4: <adapter controlType="System.Web.UI.WebControls.TextBox" adapterType="MyNamespace.TextBoxAdapter, MyAssembly" />
5: </controlAdapters>
6: </browser>
7: </browsers>
A browser definition file targets a specific browser, so you can have different definitions for Chrome, IE, Firefox, Opera, as well as for specific version of each of those (like IE8, Firefox3). Alternatively, if you set
the target to Default, it will apply to all.
The reason to pick a specific browser and version might be, for example, in order to circumvent some limitation present in that specific version, so that on markup you don’t need to be concerned with that.
Another option is through
the the current Browser object of
the request:
1: this.Context.Request.Browser.Adapters.Add(typeof(TextBox).FullName, typeof(TextBoxAdapter).FullName);
This must go very early on
the page lifecycle, for example, on
the OnPreInit event, or even on Application_Start. You have to specify
the full class name for both
the target
control and
the adapter. Of course, you have to do this for every request, because it won’t be persisted.
As an example, you may know that
the classic TextBox
control renders an HTML input tag if its TextMode is set to SingleLine and a textarea if set to MultiLine. Because
the textarea has no notion of maximum length, unlike
the input, something must be done in order to enforce this. Here’s a simple suggestion:
1: public class TextBoxControlAdapter : ControlAdapter
2: {
3: protected TextBox Target
4: {
5: get
6: {
7: return (this.
Control as TextBox);
8: }
9: }
10:
11: protected override void OnLoad(EventArgs e)
12: {
13: if ((this.Target.MaxLength > 0) && (this.Target.TextMode == TextBoxMode.MultiLine))
14: {
15: if (this.Target.Page.ClientScript.IsClientScriptBlockRegistered("TextBox_KeyUp") == false)
16: {
17: if (this.Target.Page.ClientScript.IsClientScriptBlockRegistered(this.Target.Page.GetType(), "TextBox_KeyUp") == false)
18: {
19: String script = String.Concat("function TextBox_KeyUp(sender) { if (sender.value.length > ", this.Target.MaxLength, ") { sender.value = sender.value.substr(0, ", this.Target.MaxLength, "); } }\n");
20:
21: this.Target.Page.ClientScript.RegisterClientScriptBlock(this.Target.Page.GetType(), "TextBox_KeyUp", script, true);
22: }
23:
24: this.Target.Attributes["onkeyup"] = "TextBox_KeyUp(this)";
25: }
26: }
27:
28: base.OnLoad(e);
29: }
30: }
What it
does is, for every TextBox
control, if it is set for multi line and has a defined maximum length, it injects some JavaScript that will filter out
any content that exceeds this maximum length. This will occur for
any TextBox that you may have on your site, or
any class that inherits from it. You can use
any of
the previous options to register this adapter.
Stay tuned for more ASP.NET Web Forms extensibility tips!
