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!
