Implementation events for ASP.NET2.0 server control development

Asp.net| Server | control | control DEVELOPMENT

The previous articles explain what to do with using ASP.net 2.0 technology to create custom server control properties. Starting with this article, including a few subsequent articles, explores ways to create custom server control events. This article focuses on the basic concepts of implementing control events that are important to help developers create events for server controls.

　　1. Basic concepts of events

An event is a message or notification given by a class when an action occurs or changes in state. Typically, the occurrence or change of a state is initialized by a user-interface action, for example, by clicking a button, or because of other program logic. The class that generates the event or the class that sends the notification is called the event source sender, and the class that receives the event is called the event receiver receiver. The association is implemented through a delegate (delegate). A common Application event code is listed below.

declaring events
Clickcustomcontrol.click + = new EventHandler (this.customcontrol1_clicked);
Implementing an event handler
Customcontrol1_clicked (Object Sender,eventargs e) {...}

The code above enumerates the procedures for declaring events and implementing event handlers for a server control. Since the process is very simple, there will be little explanation here. In addition, in practical applications, developers can implement event mechanisms for server controls by not using the above declaration event approach, but simply listing "OnClick = customcontrol1_clicked" in the control declaration tag. In fact, the declaration of events and the implementation of specific event handlers are relatively simple and easy to use. However, implementing event mechanisms for controls is not an easy task.

From the perspective of server control development, control events, which refer only to server-side events and not to client events, can come from two aspects: one is an event inherited from a base class. For example, if a custom control inherits from the Button class, the control inherits the click event of the base class. The second is a custom event that is created based on development requirements. Each of these events is described below.

　　2. Implementing events inherited from a base class

As we all know, custom server controls are ultimately derived from System.Web.UI.Control. Some events have already been defined in the base class. Therefore, during the creation of a server control, it is likely that you will need to override the following inherited multiple events.

· DataBinding Event: This event occurs when a server control is bound to a data source, and its corresponding event handler is ondatabinding.

· Disposed Event: This event occurs when a server control resource is freed from memory and its corresponding event handler is ondisposed. This is the final stage of the server control lifecycle.

· Init Event: This event occurs when the server control initializes, and its corresponding event handler is OnInit. The Init event is the first step in the life cycle of the control.

· Load event: This event occurs when the server control is loaded into the Page object, and its corresponding event handler is onload.

· PreRender Event: This event occurs after the control object is loaded, before rendering, and its corresponding event handler is OnPreRender.

· Unload Event: This event occurs when a server control is unloaded from memory, and its corresponding event handler is onunload.

The above is a brief description of several events for the control base class. Because server controls inherit from the control base class (WebControl is also inherited from control classes), developers can completely override event handlers for events so that they can implement some customization.

To implement custom inherited events, you need to override the protected OnEventName method inherited from the base class without attaching a delegate (EventHandler). In general, an overridden event handler should call the OnEventName method of the base class to ensure that the delegate attached to the event is invoked (unless the delegates are not invoked). The following code fragment illustrates the processing of the custom control overriding inherited databinding events.

protected override void OnDataBinding (EventArgs e)
{
Add some custom logic code
Call base class method
Base. OnDataBinding (e);
}

As shown in the code above, in overriding the event handler ondatabinding, you first need to add some custom logic code that is implemented based on the application requirements, and then be sure to remember to call the base class method.

The above describes the process of overriding the corresponding event handlers for events and derived classes of the control base class. It is not noted above that custom server controls can override only the above several event handlers from the control base class event. If a custom control inherits from other base classes that originally had events, such as Button, DataList, and so on (in the final analysis, they also inherit from the control base class), the inherited event handler can still be overridden, for example, Controls that inherit from the button class naturally obtain the click event and can override the OnClick event handler.

　　3. Creating Custom server Control Events

Before you introduce a way to create custom server control events, let's start with a brief review of the relevant event model.

In a Web Forms page, the events associated with a server control are raised by the client and processed by the Web server (note that the event must be called "throw" instead of using the words "trigger" and "fire", which are both inaccurate and nonstandard). For events raised by server controls on the client computer, the ASP.net 2.0 event model collects information about the request and passes the details to the server using an HTTP POST. The page framework on the server interprets the bulletin to determine the event that occurred, and then invokes the appropriate handler method. Figure 1 below illustrates this process.

Figure 1

As shown in Figure 1, on the client computer, the user clicks the Add button on the shopping cart to try to put the selected item in the cart. After clicking, the event model collects relevant information, such as Submit = Btnaddtocart,prod3 = Gizmo, and so on, and passes the information to the server by post. After the server receives this information, it analyzes it first, and then invokes the event handler btnAddToCart (obj,event) for processing. These are the basic event-handling models.

For ordinary application developers, only the control's event handlers can be implemented, and further information is hidden for them, and there is no need for more attention. However, as a server control developer, you must carefully consider this event-handling model.

If the reader carefully ponders the above process, you will find two important issues that need to be addressed in the event-handling model. First, the server side how to capture the return of the Click event, and second, through the post way back to the server side of the data, the specific how to deal with. The above two questions are of paramount importance. If you can solve both of these problems, it becomes very easy to create custom server control events.

To address these issues, ASP.net 2.0 provides two key interfaces: IPostBackEventHandler and IPostBackDataHandler. The IPostBackEventHandler interface is used to handle events that are raised by the client for page postbacks. Implementing this interface, server controls can map the client's submission form events to server-side events and complete processing of the client event through an event handler. The IPostBackDataHandler interface is used to examine the data that is submitted to the page and to determine whether it has been modified on the client. When the control implements the interface, the control automatically has the processing power to participate in the postback data. Developers can accomplish the processing logic for the postback data by implementing the interface-related members.

In fact, most server controls in asp.net 2.0 throw a postback from the client to the server, and many server controls implemented by the reader must also raise a postback. Therefore, the above two interfaces are important for implementing control events. For them, this section is just a brief introduction. In the following article, the reader will use a typical example to learn more about implementing interface members, capturing the postback event, and handling the return data in concrete ways.

In addition, ASP.net 2.0 enhances the functionality associated with callback processing. For example, use the System.Web.UI.ICallbackEventHandler interface and the Page.getcallbackeventreference method, and so on. The application of these objects enables you to run server-side code on the client, thereby avoiding loss of client state and not causing the server to round up the processing overhead. There is some connection between these content and server control events. However, because callback applications are less applied in server controls. Therefore, there will be no excessive description.

　　4. Summary

From the perspective of technology development, ASP. NET technology from 1.x to version 2.0, there is no obvious change in server control event development. If the reader already understands the content of creating server control events under ASP.net 1.x, then you can follow the methods and ideas of the past 1.x. In the following article, the author will introduce a server control to capture the implementation of the postback event through a typical example.