Is the design-time experience for the ASP.NET AJAX Control Toolkit all wrong?

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.

7 Comments

  • Good point, why configure 2 places to do one thing

  • Presisely, this whole thing sucks.

  • er I think it's a little bit harsh to say the whole thing sucks.

    Having created my own AJAX Extender using the vs template I'm more than happy with it, it provides a very convenient way to add "packaged" javascript functionality to my page

  • Quite right, MrTea. The toolkit is great, and ASP.NET AJAX would be far less useful without it.

  • This article makes some good points. I have found the behavior of some of controls in the ASP.NET AJAX Control Toolkit a bit inconsistent.

  • It's not just the experience that is undesirable.

    The controls specify what libraries and resources they use by having attributes on their classes.

    This means for example if you are using the Calendar control without animation and with your own CSS then tough - the threading library and provided CSS is still going to be sent along with the page.

    As for the calendar control - if you want to use more than one on a page then you have to add multiple copies of the control to the page and bloat up the HTML despite the fact that only one is ever shown at the same time and so a single one could be re-used.

    A real-case page we had here was 141KB of requests including the base AJAX library. Throw two Calendar controls on the page and the request is now 262KB.

    [)amien

  • I find the benefit of using the controls outweighed by the whole messy process of installing, loading, and configuring the controls; not to mention how it affects the performance of a webform in general.

Comments have been disabled for this content.