ASP+ pages can be activated either as a result of a navigation request to the page (for example, following a link from another page or site), or as a result of a postback from a previously rendered instance of the same page on the client (for example, a registration form with multiple text fields that must be resubmitted and validated).
Web Forms provides a built-in event infrastructure that enables controls to capture and process postback form submits from a client. This enables you to better encapsulate functionality (for example, a calendar control could automatically handle the next month and previous month button events from the client without requiring user code to execute), and enables control consumers to more intelligently interact with the controls.
The view state services described previously enable each server control to provide enough state information at the end of each request so that the control can restore itself to its last used condition on the next request. (Although this might sound extremely expensive, it typically entails saving only a minimum amount of data). The end result is a programming model that provides page developers with the perception that they are programming against a page that remains consistent on the server across multiple client round trips.
When a postback occurs, it is important that any data modified by the user on the client is mapped back to the appropriate server control and reflected to the Web developer on the server. This is handled within the Web Forms framework by the IPostBackDataHandler interface.
When a postback occurs, the Web Forms framework searches the posted contents for all values whose names match the UniqueID of a server control that implements the IPostBackDataHandler interface. If a match is found, the framework calls the IPostBackDataHandler.LoadPostData method on the control, and supplies it with a HTTPValueCollection containing the appropriate post values. The control then consumes the values, compares them to its current state (set either from declarative initialization values or view state), and returns a Boolean value indicating whether it has changed as a result of the postback. The page framework accumulates a list of all changed controls, and after Load completes, uses the list to invoke the IPostBackDataHandler.RaisePostDataChangedEvent method on all of the controls that have changed. These controls can then optionally fire an appropriate change event to any event listeners. For example:
public class InputBox : Control, IPostBackDataHandler { private EventHandler changeHandler; private String text; public String Text { get { return State["text"] } set { State["text"] = value; } } // Register delegate to external "OnChange" event listener public void AddOnChange(EventHandler value) { changeHandler = value; } // Return true if posted value does not match value on last page request public boolean LoadPostData(HTTPValueCollection values) { text = values[this.GetUniqueID()]; return (text == State["previoustext"])); } // Raise appropriate change event to any "OnChange" listeners public void RaisePostDataChangedEvent() { if (changeHandler != null) { changeHandler(new EventArgs()); } } } <%-- An ASP+ page that consumes the InputBox class --%> <html> <script language="VB" runat=server> Sub Name_Change(ByVal Source as Object, ByVal E as EventArgs) Message.Text = Name.Text & " is " & Age.Text & " years old!" End Sub </script> <body> <form action="Postback.aspx" method="POST" runat=server> Name: <input id=Name type=text OnServerChange=Name_Change runat=server> Age: <input id=Age type=text OnServerChange=InputBox_Change runat=server> <input type=submit value="Click Me" runat=server> <br><br> <span id=Message runat=server/> </form> </body> </html>
Note The data postback process is deliberately split over two methods, LoadPostData and RaisePostDataChangedEvent. This ensures that developers are always working against a consistent model of the page when the OnChange event fires. If the controls fired the OnChange events from within LoadPostData instead, it would be possible for a page developer responding to an OnChange event from one input box to use an old value pulled from another input box whose LoadPostData method had not yet been called.