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

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

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.

X ITM Cloud News

Ana

Next Post

Running Assembly Reflector Add-in Updated for Reflector 5.0

Mon Nov 25 , 2019
Spread the love          For details and the download link, go here.  X ITM Cloud News
X- ITM

Cloud Computing – Consultancy – Development – Hosting – APIs – Legacy Systems

X-ITM Technology helps our customers across the entire enterprise technology stack with differentiated industry solutions. We modernize IT, optimize data architectures, and make everything secure, scalable and orchestrated across public, private and hybrid clouds.

This image has an empty alt attribute; its file name is x-itmdc.jpg

The enterprise technology stack includes ITO; Cloud and Security Services; Applications and Industry IP; Data, Analytics and Engineering Services; and Advisory.

Watch an animation of  X-ITM‘s Enterprise Technology Stack

We combine years of experience running mission-critical systems with the latest digital innovations to deliver better business outcomes and new levels of performance, competitiveness and experiences for our customers and their stakeholders.

X-ITM invests in three key drivers of growth: People, Customers and Operational Execution.

The company’s global scale, talent and innovation platforms serve 6,000 private and public-sector clients in 70 countries.

X-ITM’s extensive partner network helps drive collaboration and leverage technology independence. The company has established more than 200 industry-leading global Partner Network relationships, including 15 strategic partners: Amazon Web Services, AT&T, Dell Technologies, Google Cloud, HCL, HP, HPE, IBM, Micro Focus, Microsoft, Oracle, PwC, SAP, ServiceNow and VMware

.

X ITM