A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
Using ASP. NET 2.0 technology, creating Web custom server controls is not an easy task. Because, this requires developers to understand and be able to apply a variety of web development techniques, such as CSS stylesheets, client-side scripting language,. NET development language, server control development technology, even the hottest AJAX technology, and so on. Although the reality is so "difficult", but this development technology is not really difficult to grasp. Everything has to be done from scratch. This article provides a detailed overview of the basics of creating Web custom server controls using ASP. NET 2.0 technology, including server control concepts, control types, life cycles, and more.
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 member objects that developers can invoke, 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 will perform certain functions according to the control member object and the program logic definition. For example, the client renders the user interface. At this point, the user interacts with the control, and when the page is submitted by the user, the control raises an event on the server side and is handled by the server side according to the relevant event handler. Server controls are an important element of the WebForm programming model, and they form the basis for a new, control-based form program. This way, you can simplify the development of Web applications and improve the efficiency of application development.
The wide application of server controls simplifies application development and improves productivity. So when should you create and use a custom server control? The following are examples of three specific application scenarios:
(1) An existing server control basically conforms to the application requirements, but without some special functionality, you can customize the server control by deriving from an existing control and overriding its properties, methods, or events.
(2) The server control you need to use 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 at this point by creating a server control.
(3) Existing server controls (or their combinations) do not meet the requirements of the application. In this case, you can create a custom server control in a way that derives from the base class.
ASP. NET 2.0 provides a variety of server controls. Depending on the way server controls are defined, there are 3 types ofHTML server controls, ASP. NETStandard server Controls , and custom server controls .
HTML server Controls for ASP. NET 2.0 server controls
HTML server controls derive from namespace System.Web.UI.HtmlControls. They are converted by ordinary HTML controls (that is, the HTML language has defined controls, such as Button, input, and so on), and its rendered output is basically consistent with ordinary HTML controls. By default, it is difficult for the server side to control ordinary HTML controls on a Web page, but by converting ordinary HTML controls to HTML server controls, developers can easily control them programmatically.
Converting a normal 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 normal HTML control attribute;
(2) Set the ID property. With transformations, the related properties, events, methods, and so on, of the normal HTML control are all mapped to the HTML server control, which allows you to programmatically reference and control the HTML server control during page processing.
The HTML server control has several important features:
1. It can be programmed and controlled using object-oriented technology on the server, which facilitates the development of programming.
2. Automatic maintenance of view state. During a page form-to-server round-trip, the value entered by the user in the HTML server control is automatically maintained in the page return.
3. Interact with the validation controls to verify that the user has entered the appropriate information in the control.
4. Allows custom properties in HTML server controls. Developers can add any required properties to the property set of an HTML server control, and the page framework will read and render them without changing any of the other features.
ASP. ASP. NET 2.0 server controls
The ASP. NET Standard server controls are defined in the namespace System.Web.UI.WebControls. The so-called "standard" means that such server controls are built into the ASP. NET 2.0 framework and are pre-defined. Such controls do not map one-to-one to HTML server controls, and they are richer and more abstract than HTML server controls.
More than 50 standard server controls have been added to ASP. NET 2.0 compared to ASP. Depending on the functionality provided by the control, the ASP. NET Standard server controls can be divided into the following 6 types:
(1) Standard control: mainly refers to traditional Web Forms controls, such as TextBox, Button, Panel, and other controls. They have a set of standardized properties, events, and methods that can make development work easy.
(2) Data control: This type of control can be subdivided into two types: data source control and data-bound control. The data source control mainly implements the functions of data source Connection, SQL statement/stored procedure execution, return data collection and so on. 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, deletes and so on related user interface and so on. Typically, first, you need to use a data source control to connect to a database and return a and then use data-bound controls to visualize, update, and delete data. Thanks to 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. Specific include: RequiredFieldValidator, Rangevaliedator, RegularExpressionValidator, CompareValidator and so on. 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, test against specific values or patterns of characters, and to verify that a value is within bounds or other logic.
(4) WebParts controls: Web Parts are a great feature that enables you to create Web applications with highly personalized features. Implementing Web Parts functionality requires WebParts control support, and ASP. NET 2.0 provides the following related controls, such as WebPartManager, WebPartZone, EditorZone, CatalogZone, PageCatalogPart, AppearanceEditorPart and so on.
(5) Login control: This type of control can quickly implement user login and related functions, such as displaying login status, password recovery, creating new user, etc. Specific include: LoginView, Login, CreateUserWizard, LoginStatus and so on.
Asp. NET Standard server controls, which are officially provided, provide strong support for them from within the system. For developers, these controls are the main force in building Web applications.
Custom server Controls for ASP. NET 2.0 server controls
Custom server controls derive from the namespace System.Web.UI.Control or System.Web.UI.WebControls. This server control is completely self-designed by developers, and developers can customize the features of the UI, features, properties, methods, events, and so on, which are the differences between custom server controls and the nature of the ASP.
There are 4 common custom server controls: Composite controls, validation controls, template controls, and data-bound controls.
(1) Composite control: A control that contains two or more existing controls.
It re-uses the implementation provided by the child controls for control rendering, event handling, and other functions.
(2) Validation control: the same as the validation control definition in the standard server control described above.
(3) Template control: This type of control provides a common function called a template. The template control itself does not provide a user interface, but is provided through an inline template, which means that the template control allows the page developer to customize the user interface of the control.
(4) Data-bound control: the same as the data-bound control definition in standard server controls 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, features, properties, methods, and events, depending on the needs of the application.
(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, functions, and so on, even by combining different server controls, to form composite controls, based on inheriting standard server controls.
(4) Easy to deploy: with "Plug and Play" features, developers can use the compiled custom server controls as long as they are copied to the relevant bin directory.
(5) Difficult to create: developing custom server controls requires a developer to be proficient in a wide range of technologies, while still consuming a lot of effort and time.
The life cycle of a server control is the most important concept for creating server controls. As a developer, you must have a deep understanding of the server control life cycle. Of course, this is not overnight can do. For beginners learning control development techniques, it is not necessary to have a thorough understanding of the different phases of the server control's life cycle.
In the process of mastering the server control lifecycle, readers should pay particular attention to the relevant content about the state of the server control. While focusing on each phase of the lifecycle, note the following issues with respect to the state of the server control: When the control's life cycle saves the control and restores its state, when to interact with the page and other controls, when to execute important processing logic, what information the control can use at each stage, what data to keep, The state in which the control renders and when the output displays markup text, etc.
The following is a list of the 11 stages of the server control life cycle.
(1) initialization ----In this phase, two main tasks are accomplished: First, initialize the settings required for the incoming Web request life cycle, and track the view state. First, the page framework raises the Init event by default and invokes the OnInit () method, which the control developer can override to provide initialization logic for the control. Thereafter, the page framework calls the TrackViewState method to track view state. It is important to note that in most cases, the TrackViewState method implementation provided by the control base class is sufficient. Developers may need to override the TrackViewState method only if the control defines a complex property.
(2) load view state ----The primary task in this phase is to check that the server control exists and that it needs to revert its state to the end of its request before it is processed. Therefore, this process occurs during the page callback process, not the initialization request process. At this stage, the page frame automatically recovers 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 uses the ViewState dictionary, then the developer does not have to implement any logic. For situations where data types that 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) handling postback data ----to enable the control to check the form data sent back by the client, the LoadPostData () method of the System.Web.UI.IPostBackDataHandler interface must be implemented. Therefore, only controls that handle postback data participate in this phase.
(4) load ----At this stage, the server control in the control tree has been created and initialized, the state is restored, and the form control reflects the client's data. At this point, developers can implement the common logic for each request by overriding the OnLoad () method.
(5) send postback change notification ----At this stage, the server control raises an event as a signal that the control state changes due to postback (so that stage is used only for postback). To establish this signal, the developer must again use the System.Web.UI.IPostBackDataHandler interface and implement another method,-raisepostbackchangedevent (). The procedure is: if the control state changes due to a postback, LoadPostData () returns True, otherwise false. The page framework tracks all controls that return true and calls RaisePostDataChangedEvent () on those controls.
(6) handling postback Events ----This phase handles client events that cause postbacks. To facilitate the process of mapping client events to server-side events, developers can implement this logic by implementing the RaisePostBackEvent () method of the System.Web.UI.IPostBackEventHandler interface at this stage. By this approach, the server control will successfully capture postback client events for server-side processing.
(7) pre-rendering ----The stage to complete any work that is required before the control is built. This work is typically done by overriding the OnPreRender () method. It is important to note that at this stage you can save changes to the state of the control at the present stage, and the changes made during the rendering phase are lost.
(8) save State ----If the server control does not maintain state, or if it has the ability to save all its state by default and uses the ViewState dictionary, then the developer does not have to implement any logic at that stage. This is because the process of saving the state is automatic. If the server control requires custom state saving, or the control cannot store special data types in the ViewState dictionary, you need to implement state saving by overriding the SaveViewState () method.
(9) The rendering ----Represents the process of writing markup text to the HTTP output stream.
The developer makes a custom markup text on the output stream by overriding the render () method.
Disposal ----At this stage, the override of the Dispose () method completes the release of a reference to an expensive resource, such as a database link.
(one) unloading ----The work done is the same as the "disposition" phase, but the developer typically performs the cleanup in the Dispose () method without handling the Unload event.
Server controls play a pivotal role in the ASP. NET 2.0 framework and are the most critical and important constituent elements of building Web applications. For a good developer, it is important to master the basics of server controls.
Basic concepts of ASP. NET 2.0 Server Control development (reprint)
Start building with 50+ products and up to 12 months usage for Elastic Compute Service