I have been thinking about the detailed plumbing of calling an ASP.NET web page lately due to some weird things that have happened at work. So I thought it wise to refresh myself and my five two faithful readers about what actually goes into displaying a page.
I briefly described the HTTP traverse from browser to server, and will not delve in at that level. However, when a page request is sent to the Web server it is cycles through a series of events during its creation and disposal. Being able to understand the events (and the order) is critical for any potential ASP.NET developer. Everyone knows we start with an aspx page and end up with a beautifully rendered HTML page, however, we need to know what happens in between.
1. Object Initialization
Controls on a given page are initialized, by declaring the objects in the constructor of the C# code-behind file. If objects are created from within the aspx file they have no attributes or properties available in the code-behind and there is no reliable way to verify the order the controls will be created or if they will be created at all. The initialization event can be overridden using the OnInit method.
2. Load Viewstate Data
After the Init event, controls can be referenced using their IDs only. During LoadViewState event, the initialized controls receive their first properties from the viewstate information (handled by ASP.NET) that was persisted back to the server on the last submission. The event is overridden using the LoadViewState method and is used to modify the data received by the control.
3. LoadPostData, Processes Postback Data
When a page submits a form, the framework will implement the IPostBackDataHandler interface on each control that updated its data. The page then triggers the LoadPostData event and goes through the page to find each control that implements the applied interface and updates the control state with the correct postback data. ASP.NET checks each control by verifying the control's unique ID with the stored name/value pair.
4. Object Load
All object are arranged in the Control Tree (formerly known as the DOM) and can be referenced easily in code. Objects are now at liberty to apply the client-side properties set in the HTML, such as height, visibility, etc. This is generally considered the hardest working event in the process. This event can be overridden by calling OnLoad.
5. Raise PostBack Change Events
This event occurs immediately after all controls that implement the IPostBackDataHandler interface have been updated with the current postback data. This operation flags each control with a true\false based on if it was changed since the last post. ASP.NET looks for this flag and raises RaisePostDataChanged event.
6. Process Client-Side PostBack Event
The object which initiated the postback is handled by the RaisePostBackEvent event. The object is usually a control that posted the page back to the server (autopostback) or a submit from a button. The RaisePostBackEvent is last in the series of postbacks.
7. Prerender the Objects
This event is a critical one, as it marks the last chance the developer has to make any persistable changes to the objects. Immediately after the PreRender event changes to objects are locked and can no longer be saved to the viewstate. This event can be overridden using OnPreRender.
8. ViewState Saved
The viewstate is saved after all changes to the page have finalized. At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not persisted.
9. Render To HTML
During the Render event, the page coerces each object into rendering itself into HTML. The page collects the HTML for transport to the client browser. When the Render event is overridden, the developer can write their own HTML to the browser that will actually override the HTML gathered by the page. The Render method uses the HtmlTextWriter to create HTML that will be streamed to the client browser. Changes can still technically be made here, but they will only show up at client browser.
10. Disposal
The Dispose event is the opportunity to destroy any objects or references you have created during the creation of the page.
Phew that is a lot of steps ... Monorail anyone. I think at some point I should also go over HTTPModules and HTTPHandlers. They provide really slick ways of jumping in the middle of a page cycle without necessarily touching every page! During the MCP test I noticed they really flogged the server and user control horse to death. It is a wonder to me that HTTPModules\Handlers were not covered with equal passion.
"Nothing contributes so much to tranquilizing the mind as a steady purpose - a point on which the soul may fix its intellectual eye." - Mary Shelley