Overview of composite controls for ASP.net 2.0 server controls

In the previous article, we introduced the basic concepts and basic theories of server controls, which are the cornerstones for building all custom server controls. However, relying on this knowledge alone is not enough to create a good server control. Because different types of server controls have different methods of creation, developers must master the basic concepts and theories and learn how to develop different types of server controls. This article and subsequent articles will detail the content associated with creating a composite control. This article focuses on the concepts of composite controls, how to create them, and then, through a typical example, deepens the reader's understanding of the method of creating a composite control.

Composite Control Overview

The word "composite" in a composite control indicates that the type control is essentially composed of multiple components. Also, the externally exposed member objects of a composite control are usually provided by the methods and properties that make up the component, and some new members may be added. A composite control can also implement custom events and handle and raise events caused by child controls. In terms of functionality, the function of a composite control is much more powerful than a simple combination of several controls, and many times it has a certain degree of special nature. For example, the new login control for ASP.net 2.0 is a typical composite control. The control user interface is composed of multiple separate controls and is set up and accessed using a single API. In addition, the login control has the ability to quickly implement a user login because of its integration with functions such as membership.

Perhaps some of the experienced readers will be puzzled when they understand the basic concepts of the composite Control: The composite controls seem very similar to the user controls, so what's the difference between them? When do you create a composite control and when do you create a user control? To answer this question, we must start with the basic concept of user control.

In simple terms, a user control is defined in a project, because the same function modules in many references, such as navigation menu, you can make this piece of code into a user control, and then, in the need to refer to the page to register, directly in the way the control used to refer to, eliminating the duplication of writing the same code work. The difference between a composite control and a user control can be summed up in the following points:

One, the shortest design-time support for composite control authoring, full design-time support for user control authoring. In a visual designer, there is no difference between authoring a user control and authoring a asp.net page.

Second, composite controls are object-oriented programming languages targeting the common language runtime, such as C #, which are authored programmatically using ASP.net page syntax and script blocks for declarative authoring.

Three, composite controls are compiled and persisted as assemblies (. dll). A user control is a text file with an. ascx extension.

Composite controls are ideal for authoring generic, republishing controls that are appropriate for application-specific functionality.

You can add a composite control to the toolbox of the visual designer and drag and drop it onto the page, which can be designed in the property box and can be written only in HTML.

Through the above, I believe that the reader can have a basic understanding of the composite control. Here's how to create a composite control. In this process, developers must grasp the following key points:

First, in general, a composite control class must derive from the System.Web.UI.WebControls.CompositeControl class. This is somewhat different from developing composite controls in the ASP.net 1.x environment. In ASP.net 1.x, the composite control must implement the System.Web.UI.INamingContainer interface. However, under ASP.net 2.0, the base class of the composite control class has changed. Here is a brief introduction to the CompositeControl class.

The CompositeControl class is an abstract class that provides naming containers and control designer functionality for custom controls, and can contain all child controls or use other control features. The Declaration code for the CompositeControl class looks like this:

Public abstract class Compositecontrol:webcontrol, INamingContainer, Icompositecontroldesigneraccessor

As shown in the code above, the CompositeControl class base is WebControl base class and implements the INamingContainer and Icompositecontroldesigneraccessor interfaces. INamingContainer is a markup interface with no methods. When a control implements INamingContainer, the page framework can create a new named range under the control, so you can ensure that child controls have unique names in the control's hierarchical tree. This is important when a composite control exposes template properties, provides data binding, or needs to transfer events to child controls. The Icompositecontroldesigneraccessor interface enables the composite control designer to re-create the child controls of its associated control at design time. The interface contains a method that needs to be implemented Recreatechildcontrols. This method enables the designer of a composite control to re-create the child controls of the control at design time.

Also, if you are creating a data-bound composite control, the base class for the custom control class should be CompositeDataBoundControl. For specific content of this category, please refer to the relevant information.