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!
