Basic concepts of server control development

Using ASP. NET 2.0 technology to create Web custom server controls is not easy. This requires developers to understand and flexibly apply a variety of web development technologies, such as CSS style sheets, client scripting languages, and ,. NET development language, server control development technology, and even the most popular Ajax technology. Although the reality is so "difficult", this development technology is not really difficult to grasp. Everything should start from scratch. This article will

P. NET 2.0 technology, detailed introduction to basic knowledge of creating web custom server controls, including the concept, type, and lifecycle of server controls.

1. What is a web server control?

In ASP. NET 2.0, web server controls are components that execute program logic on the server. This component may generate a certain user interface, or it may not include the user interface. Each Server Control contains some Member objects for developers to call, such as attributes, events, and methods.

Generally, server controls are included in ASP. NET pages. When you run the page, the. NET execution engine performs certain functions based on the control member object and Program Logic definition. For example, the user interface is displayed on the client. At this time, the user can interact with the control. When the page is submitted by the user, the control can trigger an event on the server side, and the server side can process the event according to the relevant event processing program. Server controls are an important element of the webform programming model. They constitute the foundation of a new control-based form program. This method can simplify the development of web applications and improve the development efficiency of applications.

The extensive application of server controls simplifies application development and improves work efficiency. So when should I create and use a custom Server Control? The following lists three specific application scenarios:

(1) an existing Server Control basically meets application requirements. However, it lacks some special functions, in this case, you can customize the server control by deriving from an existing control and rewriting its properties, methods, or events.

(2) The server control to be used combines the functions of two or more existing controls, for example, encapsulating a button and a textbox compound control. In this case, you can create a server control.

(3) Existing server controls (or their combinations) do not comply with application requirements. In this case, you can create a custom Server Control by deriving from the base class.

2. Server Control Type

ASP. NET 2.0 provides multiple server controls. Server controls can be defined in the following three types: HTML server controls, ASP. NET standard server controls, and custom server controls.

(1) HTML server controls

The HTML Server Control is derived from the namespace system. Web. UI. htmlcontrols. They are converted from common HTML controls (controls defined in the HTML language, such as buttons and input). The output is basically the same as that of common HTML controls. By default, it is difficult for the server to control common HTML controls on Web pages. However, by converting common HTML controls into HTML server controls, developers can easily control programming.

It is easy to convert a common HTML control to an HTML Server Control. Generally, the conversion is completed in two steps:

(1) Add the runat = "server" attribute to the features of common HTML controls;

(2) set the ID attribute. Through conversion, the attributes, events, and methods of common HTML controls are all mapped to the HTML server controls, by programming, You can reference and control the HTML Server Control During page processing.

HTML server controls have the following important features:

1. You can use object-oriented technology to control programming on the server, which facilitates programming and development.

2. automatically maintain the view status. During the round-trip from the page form to the server, the value entered by the user in the HTML server control will be automatically maintained in the page return.

3. interact with the verification control to verify whether the user has entered the appropriate information in the control.

4. Allow custom attributes in the HTML Server Control. Developers can add any required attributes to the attribute set of the HTML server control. The page framework will read and present them without changing any other functions.

(2) ASP. NET standard server controls

ASP. NET standard server controls are defined in the namespace system. Web. UI. webcontrols. The so-called "standard" means that such server controls are embedded in the ASP. NET 2.0 Framework and are pre-defined. These controls are not mapped to HTML server controls one by one. They have richer functions and are more abstract than HTML server controls.

Compared with ASP. NET 1.x, ASP. NET 2.0 adds more than 50 standard server controls. According to the functions provided by the control, ASP. NET standard server controls can be divided into the following six types:

(1) standard controls: They mainly refer to traditional web form controls, such as Textbox, button, and panel controls. They have a set of standardized attributes, events, and methods, making development easier.
(2) Data Control: This type of control can be subdivided into two types: Data Source Control and Data Binding control. The data source control mainly implements data source connection, SQL statement/stored procedure execution, and return data sets. Including sqldatasource, accessdatasource, xmldatasource, sitemapdatasource, and objectdatasource. Data Binding controls include repeater, datalist, gridview, detailsview, and formview. These controls are used to display data, provide editing, deletion, and other user interfaces. Generally, you need to use the data source control to connect to the database and return a data set. Then, use the data binding control to display, update, and delete data. With the powerful support of Visual Studio 2005, developers can quickly implement the above functions without writing a line of code.

(3) verification controls: these are special controls that contain verification logic to test user input. These include: requiredfieldvalidator, rangevaliedator, regularexpressionvalidator, and comparevalidator. Developers can append the verification control to the input control to test the content that users enter for the input control. The verification control can be used to check input fields and test against specific values or modes of characters to verify whether a value is within a limited range or other logic.

(4) site navigation controls: these controls can be combined with site navigation data to implement site navigation. Including menu, sitemappath, and Treeview. For large websites, site navigation controls have broad application prospects.

(5) webparts control: Web components are an amazing feature that allows you to create Web applications with highly personalized features. The webparts control is required to implement the Web part function. ASP. NET 2.0 provides the following controls, such as webpartmanager, webpartzone, editorzone, catalogzone, pagecatalogpart, and appearanceeditorpart.

(6) logon controls: these controls can quickly implement user logon and related functions, such as displaying logon status, password recovery, and creating new users. Including: loginview, login, createuserwizard, and loginstatus.

ASP. NET standard server controls are officially provided, so they are provided with strong support within the system. For developers, these controls are the main force in building Web applications.

(3) custom server controls

The custom Server Control is derived from the namespace system. Web. UI. control or system. Web. UI. webcontrols. This type of server control is completely designed and developed by developers. developers can customize the UI, functions, attributes, methods, events, and other features. This is a custom Server Control and ASP. net standard server controls.

Common Custom server controls include composite controls, validation controls, template controls, and data binding controls.

(1) composite controls: these controls contain two or more existing controls. It reuse the implementation provided by sub-controls for control rendering, event processing, and other functions.

(2) verification control: the verification control definition is the same as that in the Standard Server Control described above.

(3) template control: This type of control provides a common function called template. The template control does not provide a user interface, but is provided through an inline template. This means that the template control allows page developers to customize the user interface of the control.

(4) data binding control: the definition is the same as that of the data binding control in the Standard Server Control described above.

In addition to the preceding four types of controls, custom server controls have the following features:

(1) high flexibility: developers can customize the UI, functions, attributes, methods, and events based on application needs.

(2) style support: the custom server control may be derived from system. web. UI. webcontrols. Therefore, you can use the inherited style attributes to define a style, such as font, height, width, and color.

(3) provides extended functions for standard server controls: Custom server controls can be used to extend or improve related properties, methods, and functions on the basis of inheriting standard server controls, you can even combine different server controls to form a composite control.

(4) Ease of deployment: with the "plug-and-play" feature, developers only need to copy the compiled custom server control to the relevant bin directory.

(5) difficult to create: developing custom server controls requires developers to be proficient in many aspects of technology. At the same time, it also requires a lot of energy and time.
3. Server Control lifecycle Overview

The lifecycle of a server control is the most important concept for creating a server control. As a developer, you must have a deep understanding of the server control lifecycle. Of course, this cannot be done overnight. For beginners who want to learn the control development technology, they do not have to have a very detailed understanding of the different stages of the server control lifecycle.

In the process of mastering the lifecycle of server controls

Readers should pay special attention to the content related to the server control status. While focusing on the various stages of the lifecycle, you must pay attention to the following issues when to save and restore the status of the control during its lifecycle; when to interact with pages and other controls; when to execute important processing logic; at each stage, the information that can be used by the control, the data that can be maintained, the status in which the control is rendered, and the display tag text when. The following lists the 11 stages of the server control lifecycle.

(1) initialization-in this phase, two tasks are completed: 1. initialization of the settings required during the lifecycle of incoming Web requests; 2. Tracking of view status. First, the page framework triggers the init event by default and calls the oninit () method. The control developer can override this method to provide the initialization logic for the control. Then, the page Framework calls the trackviewstate method to track the view status. Note that the trackviewstate method provided by the control base class is sufficient in most cases. Developers can override the trackviewstate method only when the control defines complex attributes.

(2) Load view status-the main task of this phase is to check whether the server control exists and whether it needs to restore its status to the end state of the request before processing. Therefore, this process occurs in the page return process, rather than the request initialization process. In this phase, the page framework automatically restores the viewstate dictionary. If the server control does not maintain its state, or it has the ability to save all its States by default and uses the viewstate dictionary, developers do not have to implement any logic. For data types that cannot be stored in the viewstate dictionary or custom State management, developers can rewrite the loadviewstate method to customize state recovery and management.

(3) process the returned data-to enable the control to check the form data sent back by the client, you must implement the loadpostdata () method of the system. Web. UI. ipostbackdatahandler interface. Therefore, only the controls that process the returned data participate in this phase.

(4) Load ---- at this stage, the server control in the control tree has been created and initialized, the status has been restored, and the Form Control reflects the client data. In this case, developers can rewrite the onload () method to implement the common logic of each request.

(5) Send a change notification-in this phase, the server control uses an event as a signal, indicates that the status of the control changes due to sending back (so this stage is only used for sending back ). To establish this signal, developers must use the system. Web. UI. ipostbackdatahandler interface again and implement another method-raisepostbackchangedevent (). The determination process is as follows: if the control status is changed due to sending back, loadpostdata () returns true; otherwise, false. The page framework tracks all controls that return true and calls raisepostdatachangedevent () on these controls ().

(6) process the send-back event-process the client events that cause the send-back event in this phase. To map client events to server events for processing, developers can implement this logic by implementing the raisepostbackevent () method of the system. Web. UI. ipostbackeventhandler interface at this stage. In this way, the server control will successfully capture and send back client events for corresponding processing on the server side.

(7) pre-rendering-this stage completes any work required before the control is generated. Generally, the onprerender () method is rewritten to complete the task. Note that changes made to the control status in the pre-rendering phase can be saved in this phase, and changes made in the rendering phase will be lost.

(8) Save status-if the server control is not in the maintained status or has the ability to save all its statuses by default and use the viewstate dictionary, developers do not have to implement any logic at this stage. Because the process of saving the status is automatic. If the server control needs to save the custom state, or the control cannot store special data types in the viewstate dictionary, you must rewrite the saveviewstate () method to save the state.
(9) Rendering ---- indicates the process of writing markup text to the HTTP output stream. Developers can rewrite the render () method to customize the markup text on the output stream.

(10) disposal-in this phase, the dispose () method is rewritten to release references to expensive resources, such as database links.

(11) detach-the work completed is the same as that in the "dispose" phase. However, developers usually clear the work in the dispose () method without handling the unload event.

4. Summary

Server controls play an important role in the ASP. NET 2.0 Framework and are the most critical and important component element for building Web applications. It is very important for a good developer to master the basic knowledge of server controls. This article introduces the concept, type, and lifecycle of server controls. It is hoped that the readers will be able to master these contents and lay a good foundation for writing wonderful server controls.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/zj1103/archive/2009/04/05/4049982.aspx