Programming Microsoft ASP.NET 4 - Dino Esposito [113]
Detecting Control State Changes
The whole ASP.NET machinery works around an implicit assumption: there must be a one-to-one correspondence between some HTML input tags that operate in the browser and some other ASP.NET controls that live and thrive in the Web server. The canonical example of this correspondence is between and TextBox controls. To be more technically precise, the link is given by a common ID name. When the user types some new text into an input element and then posts it, the corresponding TextBox control—that is, a server control with the same ID as the input tag—is called to handle the posted value. I described this step in the Processing Posted Data section earlier in the chapter.
For all controls that had the LoadPostData method return true, it’s now time to execute the second method of the IPostBackDataHandler interface: the RaisePostDataChangedEvent method. The method signals the control to notify the ASP.NET application that the state of the control has changed. The implementation of the method is up to each control. However, most controls do the same thing: raise a server event and give page authors a way to kick in and execute code to handle the situation. For example, if the Text property of a TextBox changes over a postback, the TextBox raises the TextChanged event to the host page.
Executing the Server-Side Postback Event
Any page postback starts with some client action that intends to trigger a server-side action. For example, clicking a client button posts the current contents of the displayed form to the server, thus requiring some action and a new, refreshed page output. The client button control—typically, a hyperlink or a submit button—is associated with a server control that implements the IPostBackEventHandler interface.
The page processor looks at the posted data and determines the control that caused the postback. If this control implements the IPostBackEventHandler interface, the processor invokes the RaisePostBackEvent method. The implementation of this method is left to the control and can vary quite a bit, at least in theory. In practice, though, any posting control raises a server event letting page authors write code in response to the postback. For example, the Button control raises the onclick event.
There are two ways a page can post back to the server—by using a submit button (that is, ) or through script. A submit HTML button is generated through the Button server control. The LinkButton control, along with a few other postback controls, inserts some script code in the client page to bind an HTML event (for example, onclick) to the form’s submit method in the browser’s HTML object model. We’ll return to this topic in the next chapter.
Note
The UseSubmitBehavior property exists on the Button class to let page developers control the client behavior of the corresponding HTML element as far as form submission is concerned. By default, a Button control behaves like a submit button. By setting UseSubmitBehavior to false, you change the output to , but at the same time the onclick property of the client element is bound to predefined script code that just posts back. In the end, the output of a Button control remains a piece of markup that ultimately posts back; through UseSubmitBehavior, you can gain some more control over that.
The LoadComplete Event
The page-only LoadComplete event signals the end of the page-preparation phase. Note that no child controls will ever receive this event. After firing LoadComplete, the page enters its rendering stage.
Page Finalization
After handling the postback event, the page is ready for generating the output for the browser. The rendering stage is divided in two parts: pre-rendering and markup generation. The pre-rendering substage is in turn characterized by two events for pre-processing and post-processing.