I've been working a bit with the ASP.NET AJAX Control Toolkit (bit of a mouthful, isn't it?) recently. The toolkit consists mostly of a set of extender controls. In ASP.NET AJAX lingo, an extender is a control that attaches AJAX-y functionality to an existing ASP.NET server control. Each instance of an ASP.NET AJAX extender control is associated with a single instance of an ASP.NET server control through its TargetControlID property.
The .NET framework supports a similarly named but orthogonal concept, the Extender Provider. An extender provider is a component that provides properties to other components. At design-time, the IDE shows those properties as belonging to the extended control rather than the extender control. The prototypical example is the Windows Forms ToolTip component, which adds a ToolTip property to each control on a form.
Even though they both have the word "extender" in them, AJAX extender controls and extender provider controls are really totally different things. The extender control base class that the ASP.NET AJAX framework provides does not identify itself as an extender provider. The sole extender control provided by the core ASP.NET AJAX team, the DragOverlayExtender (part of the futures package - the core framework provides no extender controls out of the box) is not an extender provider.
The extender controls in the ASP.NET AJAX Control Toolkit, on the other hand, are almost all extender providers. They do this by way of the ExtenderControlBaseDesigner class, which is the base class for the control designers of most of the controls in the toolkit. This means that, for example, the auto-complete properties for the AutoComplete extender show up on the extended TextBox control, not the extender control itself.
So what's the point? The point is that the developer experience working with these controls is, in my estimation, kinda sucky. Why? Because you always have to set properties on both controls to do anything useful. The process of configuring a toolkit extender control requires picking the extender control in the designer, setting the TargetControlID property, then picking the extended control in the designer and set the extended properties there. What value is there in going to two different places? It's just a hassle for the developer, as far as I can see. Why not just put all of the properties on the extender itself?
In contrast, let's look at the other extender provider controls in the framework. ToolTip, HelpProvider, ErrorProvider, they all have something in common - they add properties to ALL controls on a form. The FlowLayoutPanel and TableLayoutPanel add properties to all controls contained within themselves. You don't pick a control to extend, so you don't have this two-step configuration process (ToolTip does let you set global settings on the component itself, but it's not a required first step, and those settings affect all controls).
The current design may be a holdover from previous CTPs of the AJAX toolkit, where a single extender control could extend multiple instances of a server control. In that case, it may have made more sense to have the per-control settings configured via properties that show up on the extended control itself. But in the RTM AJAX world, it's just a hassle.
Interestingly, one of the newest controls in the Toolkit, the Calendar control, doesn't expose itself as an extender provider. Is this an indication that the toolkit authors are moving away from that model? I hope so.