In my previous post I mentioned the steps involved in the process of an ASP.NET page. As promised, here are the details on the slide that was covered in Chris Mazzanti’s presentation at this months Rockville WinProteam user group meeting.
Firstly, all ASPX and ASCX pages are just serialized control trees – object structures. If you turn on tracing for your ASPX page (see image below) you can see the control tree, server side controls are listed and HTML controls are listed as literal controls. This is helpful to understand the steps outlined below.
Before I start with the steps, a quick mention of what the View State is. The View State is a property bag used to stored object / key pairs. The View State persists objects between server postbacks, which can then be accessed using a key from the a pair. View State persists the changed state of all controls on a page, as well as any objects added to the View State by the page developer, during the postback. This marvel is achieved by encoding the property bag as a base 64 encoded string into a hidden form variable, which is a transmitted along with rendered HTML to the client browser and later posted back to the server when the win form is submitted.
When the ASP.NET framework loads an ASPX or ASCX serialized page it immediately deserializes the page into a control tree. The following operations are executed using this object model:
Instantiate – Instantiation of the control tree, described.
Initialize – The Init event is fired and preliminary initialization of controls is started. Dynamic child controls of the page are typically loaded here.
Begin Tracking View State – ASP.NET starts monitoring changes to objects in the view state. Only objects in the View State that change (dirty objects) have their new state saved to the View State encoded output.
Load View State (Postback only) – The View State encoded string is loaded from the post data in the HTTP request.
Load Postback Data (Postback only) – Postback data for all controls loaded.
Load – The Load event is fired. Most developers know this step as the Page_Load method.
Raise Changed Events (Postback only) – Control events fired as a result of some data changed in the control on the client.
Raise Postback Events (Postback only) – Postback events fired (see Chris’s note on control events and postback events at the bottom of this post).
Prerender – The Prerender event is fired. Called before controls are rendered.
Save View State – The View State is saved as a base 64 encoded string.
Render – The RenderControl method of each control in the control tree is called and the output HTML is captured and packaged into the HTTP response, which is sent to the client browser.
Unload – The Unload event is fired.
Dispose – The control tree structure is released from memory and page execution is complete.
The above steps make it easier for developers to understand why certainly functionality is not possible in ASP.NET. For example, how many of us have tried to access the View State information for a control during the initialization step? Since the View State has not let been loaded yet, all controls still have their default value. Another hole that developers fall into (I did) is to attempt to manipulate the View State of a server control within the render step. The View State is already saved at this point, so any changes are pointless.
I want to thank Chris for presenting the above information in his presentation yesterday, it certainly cleared up some confusion with ASP.NET for me.
Here is Chris’s comments on the changed events and postback events steps:
In terms of PostBack events and Changed events, the differences are subtle. A “change” event is an event that a server control will raise during the postback phase if its data has changed while it was on the client. For example, you can have a TextBox generate a change event, and if the user changes the data in that control, the control will raise a data changed event during the postback phase.
It is important to keep in mind that these server side events are not the same as the event that generated the postback itself. For example, if you have a change event setup on a textbox control, simply changing the text will not (necessarily) cause the page to post back. However, if the user clicks the save button, the page will be posted to the server, the textbox will see that it’s data has changed, and fire a changed event. After all the changed events have fired, the “post back” event will fire. This is the event that is raise by the control that actually caused the page to the be sent back to the server in the first place.