Sunding asp.net3.5 Control and Component development technology series-events and data postback mechanism (i)

Content of this chapter

5.1 Control events and data postbacks overview

Implementation of the 5.2 event and data postback mechanism

5.3 Event handling mechanisms for composite controls

5.1 Control events and data postbacks overview

Before you can explain the implementation of control events and data postback, it is important to understand the basic concepts involved.

5.1.1 Event and its significance

To customize an event for a control, you must first use the control's event. First, take the classic button control's OnClick event as an example to describe the usage model of the event.

1. Registering events

<asp:button id= "Button1" runat= "Server" onclick= "Button1_Click" text= "button"/>

or register in Page_Load:

protected　void　Page_Load(object　sender,　EventArgs　e)
{
　　 this.Button1.Click　+=new　EventHandler(Button1_Click);
}

2. Event Method Body

protected　void　Button1_Click(object　sender,　EventArgs　e)
{
}

The event is understood first from the functional perspective that the event is to implement. We think of the button as an object and the page as an object.

Forward understanding: If we want to modify the button's behavior in the Page object, we can pass this directly. Button1 Direct access to the button object's properties or methods to modify the button, you can understand that the page class can access the button code functionality. The reason is that Button1 is an object inside the page class, and the class can certainly access its internal objects directly.

Reverse understanding: What if we need to access the page code in the button? Pass this directly as above. The form of a page is not acceptable because the Button is an internal object of the page class, but the page is not an internal object of the Button class, and the Class (Button) cannot access its external object (page) from an object-oriented perspective. That is, it is not possible to access the Page object in the button in this.page form. Using the event mechanism solves this problem, that is, the event mechanism solves the problem of not allowing class to access class external code in object-oriented programming. The application of the event is explained later in this chapter, and it only describes its function here.

A deeper look at the button's event: If we do not register the click event on the button, the button executes its internal click-related logic and does not have any effect on the Page object If we define the click event (such as the code fragment above) for the button, the button still executes its internal click-related logic. The difference is that in the execution of its own internal logic it also executes some of the code functions in the Page object (that is, the button's event body Button1_Click method), to achieve the functionality we want to implement. By touching an object button affects the behavior of another object page, and the button itself can be modified in the event body of the button (through sender or this.) Button1), you can also modify other controls on the page Page object or perform any desired code functionality.

Second, from the asp.net work mechanism to say how it works, unlike the events in desktop applications, ASP.net server control events are raised and processed on the server. When a Web request sends a client operation to the server, the control can raise events on the server to respond to client actions. The page or its child controls handle the event, and then ASP.net sends the response back to the client. In this way, users feel like they are using a desktop application. However, a control developer must understand that only one client event is sent to the server, that is, a postback event.

Some events performed at the client (such as JavaScript-defined client events) are not sent to the server and cannot be processed by the service side, such events are not the events of our chapter, this chapter is about server control events, the events that are handled by the server.