Shulou(Shulou.com)06/02 Report--

What are the principles and key points of ASP.NET composite control? aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Brief introduction of ASP.NET Composite Control

Composite controls are just ordinary ASP.NET controls and do not belong to another type of ASP.NET server control to be discussed. In that case, why is there always a special chapter in books and documents to discuss composite controls? What's so special about ASP.NET composite controls?

As the name implies, a composite control is a control that aggregates multiple other controls under a single top and a single API. If a custom control consists of a label and a text box, it can be said to be a composite control. The word "composite" indicates that the control is essentially composed of other constituent components at run time. The set of methods and properties exposed by a composite control is usually (but not necessary) provided by the methods and properties that make up the component, with some new members added. Composite controls can also raise custom events and handle and raise events caused by child controls.

Composite controls are not so special in ASP.NET because they are likely to represent a new type of server control. More specifically, it is supported by the ASP.NET runtime at render time.

Composite controls are a powerful tool for generating rich and complex components that are generated from the interaction of active objects rather than the markup output of some string generator objects. Composite controls are rendered in the form of a tree of controls, each with its own life cycle and events, and all constituent controls are combined to form a new API that is as abstract as possible as needed.

In this article, I'll discuss the internal architecture of composite controls to illustrate the benefits it brings to you in a variety of situations. Next, I will generate a composite list control that has a richer feature set than the one I described in the previous article.

What are the main points of the ASP.NET composite control?

Some time ago, I tried to do it myself in ASP.NET. Study composite controls in the. I learned theory and practice from MSDN documentation, and also designed some good controls. However, it was only when I saw the following example by accident that I really realized the main points (and advantages) of composite controls. Imagine the simplest (and most common) control generated by a combination of two other controls (Label and TextBox). Here is a possible way to write such a control. We call it LabelTextBox.

Public class LabelTextBox: WebControl, INamingContainer {public string Text {get {object o = ViewState ["Text"]; if (o = = null) return String.Empty; return (string) o;} set {ViewState ["Text"] = value;}} public string Title {get {object o = ViewState ["Title"]; if (o = null) return String.Empty; return (string) o;} set {ViewState ["Title"] = value } protected override void CreateChildControls () {Controls.Clear (); CreateControlHierarchy (); ClearChildViewState ();} protected virtual void CreateControlHierarchy () {TextBox t = new TextBox (); Label l = new Label (); t.Text = Text; l.Text = Title; Controls.Add (l); Controls.Add (t);}}

The control has two common properties (Text and Title) and a rendering engine. These two properties are saved in view state and represent the contents of TextBox and Label, respectively. The control has no replacement method for the Render method and uses the CreateChildControls replacement method to generate its own markup. I will elaborate on the routine of the presentation phase in a moment. The code for CreateChildControls first clears the collection of child controls and then generates a control tree for the constituent controls that the current control outputs. CreateControlHierarchy is a control-specific method that does not require it to be marked as protected and virtual. Note, however, that most native composite controls, such as DataGrid, simply expose the logic used to build the control tree through a similar virtual method.

The CreateControlHierarchy method instantiates multiple constituent components as needed, and then synthesizes the final output. When finished, each control is added to the Controls collection of the current control. If you want the output of the control to be a HTML table, you can create a Table control and add rows and cells containing their respective contents accordingly. All rows, cells, and contained controls are children of the outermost table. At this point, you just need to add the Table control to the Controls collection. In the above code, Label and TextBox are direct children of the LabelTextBox control and added directly to the collection. The rendering state and running state of the control are normal.

From a purely performance point of view, creating transient instances of controls is not as efficient as rendering some plain text. Let's consider an alternative way to write the above controls without the need for child controls. This time let's name it TextBoxLabel.

Public class LabelTextBox: WebControl, INamingContainer {: protected override void Render (HtmlTextWriter writer) {string markup = String.Format ("

{0}

", Title, Text); writer.Write (markup);}}

The control has the same two properties (Text and Title) and replaces the Render method. As you can see, the implementation process is quite simple and the code runs slightly faster. You can replace this method of compositing child controls by compositing text in a string generator and outputting the final markup for the browser. Similarly, the rendering state of the control is good at this time. But can we really say that it is running just as well? Figure 1 shows the two controls running in the sample page.

Figure 1: similar controls using different rendering engines

Enable tracing on the page and run it again. When the page is displayed in the browser, scroll it down and view the control tree. It will look like this:

Figure 2: control tree generated by two controls

The ASP.NET composite control consists of the active instances that make up the component. The ASP.NET runtime discovers these child controls and can communicate directly with them when working with published data. As a result, child controls can handle view state themselves and automatically raise events.

For controls based on tag composition, the situation is different. As shown in the figure, the control is a basic unit of code with an empty Controls collection. If the tag injects interactive elements (text boxes, buttons, drop-down menus) into the page, ASP.NET cannot handle postback data and events without involving the control itself.

Try entering some text in both text boxes and clicking the Refresh button in figure 1 so that a postback can occur. * controls (that is, composite controls) will retain the assigned text correctly after a postback. The second control that uses the Render method loses new text after a postback. What causes it? There are two reasons.

The reason is that in the above mark, I am not responsible for

Tag naming. In this way, its content will not be sent back. Note that you must use the name attribute to name the element. Let's make the following changes to the Render method.

Protected override void Render (HtmlTextWriter writer) {string markup = String.Format ("

{0}

", Title, Text, ClientID); writer.Write (markup);}

Injected into the client page

Element now uses the same ID as the server control. When the page posts back, the ASP.NET runtime finds a server control that matches the ID of the published field. But it doesn't know what to do with the control. For ASP.NET to apply all client changes to a server control, the control must implement the IPostBackDataHandler interface.

Composite controls that contain TextBox do not have to worry about postback, because embedded controls automatically resolve the problem using ASP.NET. The control that renders the TextBox needs to interact with the ASP.NET to ensure that the postback value is handled correctly and events are raised properly. The following code shows how to extend the TextBoxLabel control to fully support postback.

Bool LoadPostData (string postDataKey, NameValueCollection postCollection) {string currentText = Text; string postedText = postCollection [postDataKey]; if (! currentText.Equals (postedText, StringComparison.Ordinal)) {Text = postedText; return true;} return false;} void IPostBackDataHandler.RaisePostDataChangedEvent () {return } the answers to the questions about the principles and key points of ASP.NET composite controls are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.