Introduction to ASP. NET internal mechanism (III)

As you know, when developing an ASP. NET Website, each server control has its own ID. For better expansion in the future, let's take a simple look at this scenario: When we click a server control in the browser, such as a Button, the page is sent back to the server, the server then triggers the Click and other events of the control. This scenario is simple and cannot be simplified. Let's look at it further. We know that not all controls will trigger events on the server side, such as the submit button. This button can also upload form data to the server, however, this control cannot trigger events on the server side. In fact, after a page is submitted to the server, the server will check which control caused the Page Submission, then find the control ID, and then on the page we requested, such as Default. aspx (if we click the button, the request is Default. aspx) to check whether the server Control ID is the same as the ID of the submitted page at this time. If yes, an event is triggered when the page lifecycle is appropriate, return the processing result; if not, the server will not perform any special processing.

 

Note that the Page (such as Default. aspx) has been compiled into a class inherited from the Page when you look for the Control ID.

Of course, the above is just a rough process. I hope you will have a general understanding. The following is a detailed explanation.

 

I will explain through a process:

1. First, we request a Server Page, such as http: // localhost/Demo/Default. aspx. For ease of interpretation, assume that the page has only three server controls: TextBox, DropDowmList, And Button.

Definition:

 

 

In the browser, we can see the following in "Source:

 

 

"Http://www.w3.org/tr/xhtml1/dtd/xhtml1-transitional.dtd"

 

 

Indeed, the above HTML code does not have much, but you should take a look at TextBox and DropDownList. Their IDs are the same on the server-side aspx page and in the local source.

2. Input "xiaoyang" in the TextBox of the browser, select "Text2" in DropDowList, and click the button to submit. In this case, the submitted data is included in the form and saved in the format "TextBox1 = xiaoyang & DropDownList1 = Value2". Needless to say, form data is separated by "&", and each separator string contains two parts: ID and value, that is, "key-Value Pair ".

3. ASP. NET instantiate an HttpRequest class. This class has two attributes: Forms and QueryString. Their types are NameValueCollection (key-value pair, you can regard it as a HashTable), and then ASP.. NET parses form data and form data is parsed into key-value pairs, and then stored in Forms (POST submission) or QueryString (GET submission ). We used POST submission as an example.

4. Previous events occurred before the lifecycle of the page. When the page calls its ProcessRequest method, it enters the page lifecycle. At this time, the page will check all the controls on the page to see which of the following interfaces have implemented IPostBackDataHandler, then, add the controls that implement these interfaces to an ArrayList, and then check which controls implement IPostBackEventHandler. If they are in another set, then, the collection of IPostBackDataHandler controls is developed and traversed, And the IPostBackDataHandler method is called: LoadPostData (string postdatakey, NameValueCollection value ).

As mentioned before, the values of the submitted Forms are stored in Forms (NameValueCollection type). Therefore, these values are passed in to this method, then check whether these values are the same as those before. We still remember that when we see the page in the browser, the TextBox in the page has no value at the beginning, in addition, the DropDownList selects Text2, and now our value is changed to "xiaoyang" and "Text2 ". so the result of this method check is: the value has changed and true is returned. if true is returned, the next method of IPostBackDataHandler will call RaisePostDataChangeEvent (); this method has registered the event and will be triggered after the page lifecycle.

5. Therefore, if the custom control we developed wants to trigger an event when data changes, we must implement the IPostBackDataHandler interface. For example, you can refer to my other articles on control development.

6. Now we have talked about data changes. Next, let's take a look at how events are triggered. When the RaisePostbackEvent method is executed during page development, the page will traverse the set of controls that implement IPostBackEventHandler and check whether there is a control in the page: This control must implement IPostBackEventHandler, and the ID is the same as the ID of the control that submitted the page to the server. If the RaisePostBackEvent method of IPostBackEventHandler is used to trigger an event (different controls implement this method differently), such as a Click event.

Therefore, if you want to trigger an event in a custom control, you must implement the IPostBackEventHandler interface. See my control development series.