Basic concepts for ASP.NET 2.0 server control development

Using ASP.net 2.0 technology, creating Web custom server controls is not an easy task. This requires developers to understand and have the flexibility to apply a variety of web development technologies, such as CSS style sheets, client-side scripting languages, and. NET development language, server control development technology, even the current most fire Ajax technology, and so on. Although the reality is so "difficult", but this kind of development technology is not really difficult to master. Everything has to be done from the beginning. This article will cover the basics of creating Web custom server controls using ASP.net 2.0 technology, including server control concepts, control types, lifecycle, and more.

ASP.net 2.0 server Control concepts: What is a Web server control

In ASP.net 2.0, a Web server control is a component that executes program logic on a server. This component may generate a certain user interface, or it may not include the user interface. Each server control contains some member objects so that developers can invoke them, such as properties, events, methods, and so on.

Typically, server controls are included in the ASP.net page. When you run the page,. The net execution engine performs certain functions based on the definition of the control member object and the program logic. For example, the user interface is rendered at the client. At this point, the user can interact with the control, and when the page is submitted by the user, the control can raise the event on the server side and the server side will handle the event according to the relevant event handlers. Server controls are an important element of the WebForm programming model, and they form the basis of a new, control-based form program. In this way, you can simplify the development of Web applications and improve the efficiency of application development.

The wide application of server control simplifies the development of application and improves the work efficiency. So when should you create and use a custom server control? The following list of three specific application scenarios:

(1) An existing server control basically conforms to the application requirements, but some special features are missing, at which point you can customize the server control by deriving from the existing control and overriding its properties, methods, or events.

(2) A server control that needs to be used combines the functionality of two or more existing controls, such as a composite control that encapsulates a button and a text box. You can do this by creating a server control at this point.

(3) The existing server control (or its combination) does not meet the requirements of the application. In this case, you can create a custom server control by deriving from the base class.

2 Type of server control

ASP.net 2.0 provides a variety of server controls. Depending on how the server control is defined, the following 3 types are available: HTML server controls, asp.net standard server controls, and custom server controls.

ASP.NET 2.0 server control HTML server control

The HTML server control derives from the namespace System.Web.UI.HtmlControls. They are converted by ordinary HTML controls (which are defined by the HTML language, such as Button, input, and so on), and their rendered output is basically consistent with the normal HTML control. By default, it is difficult for the server side to control the normal HTML controls on a Web page, but developers can easily programmatically control the normal HTML controls by converting them into HTML server controls.

Converting an ordinary HTML control to an HTML server control method is relatively straightforward. In general, the conversion is done in two steps:

(1) Add the runat= "Server" attribute to the generic HTML control attribute;

(2) Set the id attribute. By converting, the associated properties, events, methods, and so on for normal HTML controls are all mapped to HTML server controls, which enables you to programmatically reference and control the HTML server control during page processing.

HTML server controls have several important features:

1, the use of object-oriented technology on the server to control its programming, which provides a convenient program development.

2, automatic maintenance of view state. The values entered by the user in the HTML server control are automatically maintained in the page back cross during the page form to the server-side round trip.

3. Interacts with the validation controls to verify that the user has entered the appropriate information in the control.

4. Allow custom attributes in HTML server controls. Developers can add any required attributes to an HTML server control's property set, and the page framework will read and render them without changing any other features.

asp.net 2.0 server control asp.net Standard server control

Asp. NET Standard server controls are defined in the namespace System.Web.UI.WebControls. The so-called "standard" means that such server controls are placed within the ASP.net 2.0 framework, which is predefined. Such controls are not mapped to HTML server controls on a one-to-one scale, and they are richer and more abstract than HTML server controls.

Compared with ASP.net 1.x, asp.net 2.0 has added more than 50 standard server controls. The ASP.net standard server control can be grouped into the following 6 types, according to the functionality provided by the control:

(1) Standard controls: mainly refers to the traditional Web Forms controls, such as TextBox, Button, panel and other controls. They have a set of standardized properties, events, and methods that make development work simple and easy.

(2) Data controls: This class of controls can be subdivided into two types: data source controls and data-bound controls. The data source control mainly realizes the data source connection, SQL statement/stored procedure execution, returns the data collection and so on function. Specifically including SqlDataSource, AccessDataSource, XmlDataSource, SiteMapDataSource, ObjectDataSource and so on. Data-bound controls include Repeater, DataList, GridView, DetailsView, FormView, and so on. This kind of control mainly realizes the data display, provides the editing, the deletion and so on related user interface and so on. Typically, first, you need to use the data source control to connect to the database and return to the data collection, and then use the data-bound control to achieve data display, update, delete functions. With the strong support of Visual Studio 2005 design, developers can quickly implement these features without even having to write a single line of code.

(3) Validation controls: They are a special set of controls that contain validation logic to test user input. Specifically include: RequiredFieldValidator, Rangevaliedator, RegularExpressionValidator, CompareValidator, etc. A developer can attach a validation control to an input control and test what the user enters into the input control. Validation controls can be used to examine input fields and to test against specific values or patterns of characters to verify that a value is within a defined range or other logic.

(4) WebParts control: Web Parts are a great feature that enables you to create Web applications with highly personalized features. Implementing the Web Parts feature requires WebParts control support, ASP.net 2.0 provides the following related controls, such as WebPartManager, WebPartZone, EditorZone, CatalogZone, PageCatalogPart, AppearanceEditorPart and so on.

(5) Login controls: Such controls can quickly implement user login and related functions, such as displaying login status, password recovery, creating new users, and so on. Specifically include: LoginView, Login, CreateUserWizard, LoginStatus, etc.

Asp. NET Standard server controls provide powerful support from within the system because they are officially available. For developers, these controls are the main force for building Web applications.

ASP.net 2.0 server control's custom server control

Custom server controls derive from namespace System.Web.UI.Control or System.Web.UI.WebControls. This server control is designed entirely by the developer and developers can customize the characteristics of UI, functionality, properties, methods, events, and so on, which is the difference between custom server controls and ASP.net standard server controls.

Common custom server controls are grouped into 4 types: Composite controls, validation controls, template controls, and data-bound controls.

(1) Composite Control: The class control contains two or more existing controls.

It uses the implementation provided by child controls for control rendering, event handling, and other functions.

(2) Validation controls: the same as the validation controls in the standard server control described above.

(3) Template controls: This class of controls provides a common feature called templates. The template control itself does not provide a user interface, but is provided through an inline template, which means that the template control allows page developers to customize the user interface of the control.

(4) Data-bound controls: the same definition as the data-bound control in the standard server control described above.

In addition, in addition to the above 4 types of controls, custom server controls have the following characteristics:

(1) Flexibility: Developers can customize the UI, functionality, properties, methods, and events for application needs.

(2) Style support: Because custom server controls may derive from System.Web.UI.WebControls, you can define styles by inheriting the style property, such as font, height, width, color, and so on.

(3) provides extended functionality for standard server controls: Custom server controls can extend or improve related properties, methods, functionality, and so on, and can even combine different server controls to form composite controls, based on the inheritance of standard server controls.

(4) Easy to deploy: with a "Plug and Play" feature, developers can use a compiled custom server control only by copying it to the relevant bin directory.

(5) Difficult to create: developing a custom server control requires a developer to be proficient in many aspects of the technology, but also requires a lot of effort and time.

3. Introduction to server Control lifecycle

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 can not be done overnight. For beginners of learning control development techniques, you don't have to be very detailed and have a general idea of the different phases of the server control's lifecycle.

In mastering the lifecycle of the server control, readers should pay special attention to relevant content about server control state. While focusing on the various phases of the lifecycle, changes to the state of the server control note the following issues: When the control's lifecycle saves controls and restores their state, when to interact with pages and other controls, when to perform important processing logic, what information is available to the control at various stages, what data is persisted, When the control renders and when the display markup text is printed, and so on

The following 11 stages of the server control lifecycle are listed below.

(1) initialization----In this phase, two main tasks are accomplished: First, initialize the settings required in the life cycle of the incoming Web request, and track view state. First, the page framework raises the Init event by default and calls the OnInit () method, which the control developer can override to provide initialization logic for the control. Thereafter, the page frame calls the TrackViewState method to track view state. It should be noted that in most cases, the TrackViewState method implementation provided by the control base class is sufficient. A developer may need to override the TrackViewState method only if the control has a complex property defined.

(2) Load view state----The primary task of this phase is to check whether the server control exists and whether it needs to revert its state to the state it was at the end of the request before processing. Therefore, the process occurs during page return rather than initialization of the request process. At this stage, the page framework automatically restores the ViewState dictionary. If the server control does not maintain its state, or if it has the ability to save all its state by default and use the ViewState dictionary, then the developer does not have to implement any logic. For situations where data types cannot be stored in the ViewState dictionary or require custom state management, developers can customize the recovery and management of the state by overriding the LoadViewState method.

(3) Processing postback data----to enable the control to check the form data that the client sends back, the LoadPostData () method of the System.Web.UI.IPostBackDataHandler interface must be implemented. Therefore, only controls that handle postback data are involved in this phase.

(4) Load----at this stage, the server control in the control tree has been created and initialized, the state has been restored, and the form control reflects the client's data. At this point, the developer can override the OnLoad () method to implement the common logic for each request.

(5) Send a postback change notification----at this stage, the server control raises the event as a signal that the control state changes as a result of the postback (so that this stage is used only for the postback process). In order to build this signal, the developer must again use the System.Web.UI.IPostBackDataHandler interface and implement another method-raisepostbackchangedevent (). The judgment process is: LoadPostData () returns True if the control state changes because of a postback, otherwise it returns false. The page frame tracks all controls that return true and invokes RaisePostDataChangedEvent () on those controls.

(6) Handling postback events----This phase handles the client event that causes the postback. To facilitate processing of client events on a server-side event, 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 the client events of the postback for server-side processing.

(7) Pre-rendering----This phase completes any work required before the control is built. Typically, you do this by overriding the OnPreRender () method. Note that at this stage, you can save changes made to the state of the control at the present stage, and changes made during the rendering phase are lost.

(8) Save state----If the server control is not maintained, or if it has the ability to save all of its state by default and use the ViewState dictionary, then the developer does not have to implement any logic at that stage. Because the process of saving the state is automatic. If a server control requires a custom state save, or a control cannot store a particular data type in a ViewState dictionary, you need to override the SaveViewState () method to implement state saving.

(9) Rendering----represents the process of writing markup text to an HTTP output stream.

The developer customizes the markup text on the output stream by overriding the render () method.

(10) Disposal----In this phase, the release of references to expensive resources, such as database links, is accomplished by overriding the Dispose () method.

(11) The unload----completes the same work as the "dispose" phase, but the developer typically performs a purge in the Dispose () method instead of handling the Unload event.

4. Summary

Server controls play a pivotal role in the ASP.net 2.0 framework and are the most critical and important elements of building Web applications. For a good developer, it is important to master the basics of server controls. This paper introduces the concept, type, lifecycle and other key contents of server control. I hope readers will be able to firmly grasp these content, in order to write wonderful server control to lay a good foundation.

The following 11 stages of the server control lifecycle are listed below.

(1) initialization----In this phase, two main tasks are accomplished: First, initialize the settings required in the life cycle of the incoming Web request, and track view state. First, the page framework raises the Init event by default and calls the OnInit () method, which the control developer can override to provide initialization logic for the control. Thereafter, the page frame calls the TrackViewState method to track view state. It should be noted that in most cases, the TrackViewState method implementation provided by the control base class is sufficient. A developer may need to override the TrackViewState method only if the control has a complex property defined.

(2) Load view state----The primary task of this phase is to check whether the server control exists and whether it needs to revert its state to the state it was at the end of the request before processing. Therefore, the process occurs during page return rather than initialization of the request process. At this stage, the page framework automatically restores the ViewState dictionary. If the server control does not maintain its state, or if it has the ability to save all its state by default and use the ViewState dictionary, then the developer does not have to implement any logic. For situations where data types cannot be stored in the ViewState dictionary or require custom state management, developers can customize the recovery and management of the state by overriding the LoadViewState method.

(3) Processing postback data----to enable the control to check the form data that the client sends back, the LoadPostData () method of the System.Web.UI.IPostBackDataHandler interface must be implemented. Therefore, only controls that handle postback data are involved in this phase.

(4) Load----at this stage, the server control in the control tree has been created and initialized, the state has been restored, and the form control reflects the client's data. At this point, the developer can override the OnLoad () method to implement the common logic for each request.

(5) Send a postback change notification----at this stage, the server control raises the event as a signal that the control state changes as a result of the postback (so that this stage is used only for the postback process). In order to build this signal, the developer must again use the System.Web.UI.IPostBackDataHandler interface and implement another method-raisepostbackchangedevent (). The judgment process is: LoadPostData () returns True if the control state changes because of a postback, otherwise it returns false. The page frame tracks all controls that return true and invokes RaisePostDataChangedEvent () on those controls.

(6) Handling postback events----This phase handles the client event that causes the postback. To facilitate processing of client events on a server-side event, 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 the client events of the postback for server-side processing.

(7) Pre-rendering----This phase completes any work required before the control is built. Typically, you do this by overriding the OnPreRender () method. Note that at this stage, you can save changes made to the state of the control at the present stage, and changes made during the rendering phase are lost.

(8) Save state----If the server control is not maintained, or if it has the ability to save all of its state by default and use the ViewState dictionary, then the developer does not have to implement any logic at that stage. Because the process of saving the state is automatic. If a server control requires a custom state save, or a control cannot store a particular data type in a ViewState dictionary, you need to override the SaveViewState () method to implement state saving.

(9) Rendering----represents the process of writing markup text to an HTTP output stream.

The developer customizes the markup text on the output stream by overriding the render () method.

(10) Disposal----In this phase, the release of references to expensive resources, such as database links, is accomplished by overriding the Dispose () method.

(11) The unload----completes the same work as the "dispose" phase, but the developer typically performs a purge in the Dispose () method instead of handling the Unload event.

4. Summary

Server controls play a pivotal role in the ASP.net 2.0 framework and are the most critical and important elements of building Web applications. For a good developer, it is important to master the basics of server controls. This paper introduces the concept, type, lifecycle and other key contents of server control. I hope readers will be able to firmly grasp these content, in order to write wonderful server control to lay a good foundation.