hen designing the new version of ASP, Microsoft put a lot of effort into the individuation of a powerful and effective extensibility model. The Extensible Stylesheet Language (XSL) was the first option considered. For some time, the XML/XSL pair looked like the natural way to extend and improve ASP. You describe the page content using XML and render it to a potentially infinite number of target devices using XSL transformations (XSLT). Clearly in this way the core of your code would have been expressed with XSLT instructions, thus making the throughput of the XSLT layer an extremely critical factor capable of affecting the response time and the performance of the server.
Planned for use on a large scale, the problems with XSLT can be narrowed down to two areas. The first area deals with the quirkiness of XSLT syntax. Maintenance certainly becomes a major issue if not a nightmare as soon as you base your code all on XSLT. Secondly, the inability for users to control exactly what the XSLT processor is doing is another problem.
As a result, Microsoft discarded the XSLT option. Instead, they redesigned the ASP environment making it completely component-based. In doing so, they killed two birds with one stone. For one thing, they integrated ASP.NET with the surrounding .NET environment and framework. In addition, they came up with a stable and consolidated model for extending applications?using inheritance and other object-oriented programming techniques. Enter ASP.NET and its families of controls!
| Fast Facts |
| The extensibility model is key to the success and the rapid adoption of a software technology. In ASP.NET, the extensibility model, as well as the programming model, is totally based on components. ASP.NET components and applications are fully integrated with the .NET platform and benefit from a number of OOP-related facilities. Code-behind and user controls are just some of the smartest. |
New Controls in ASP.NET
At the highest level of abstraction, ASP.NET provides two ways to create new and custom controls. You can create a new control class inheriting from a base class (i.e., WebControl) or you can group a few controls together in a sort of embeddable child page. Although the second approach can appear not particularly object-oriented at first, the class you come up with is built atop the base UserControl class. The first approach is referred to as building custom controls. The second type of controls are said to be user controls or pagelets.
A custom control is primarily a class built to behave like a control and provide a given set of functionalities, such as a textbox or drop-down list. A user control is a form made of any combination of server and client controls sewn together with server and client script code. A user control has a rich user interface but is programmable as a monolithic component. In other words, like a Visual Basic ActiveX control, all of its constituent controls are protected and inaccessible if not through a public programming interface.
An embeddable Web form is the definition that best fits what a user control actually is. You create a user control in much the same way you create a Web form. When you’re done with code and layout, you give the resulting file an .ascx extension. This enables you to use the control with any ASP.NET page. Pages see it as a monolithic component and work with it as with any other system Web control. If you are familiar with Dynamic HTML (DHTML) Scriptlets, you can see that user controls are just their ASP.NET counterpart. (See sidebar “Cascading Stylesheet Support”.)
Let’s see what a user control is all about with an example (You can download the source code for this article here). The idea is to build an input control that takes a date and splits it into its constituent elements: year, month and day. These date elements are then displayed as individual textboxes. Just as an ASP.NET page, a user control file is made of three main sections: directives, script and layout.
<%@ Control ClassName="DateBox" Language="C#"%>
The @Control directive is very similar to @Page and lets you set general-purpose directives for the control. The most important difference with @Page is that you cannot set the Trace and the Debug attributes, whose values are inherited from the host page (see the sidebar “Tracing the Pagelet Output”). In @Control, you normally set the language of the control (attribute Language) and the public name of the class you’re developing (attribute ClassName).
Another interesting directive you might want to set for user controls is @OutputCache to control the caching features of a portion of the page.
The