In classic ASP, there was only one stage to the life cycle of the execution in the page. Basically, the page's life would start at the top of a script file (after IIS got all the server include files) and end at the bottom of the script file.
Because .NET is object orientated, there is a thing called events. With the aid of these events, the page/control life cycle is a bit more "eventful". Here is the basic order of events (without post back):
-
Initialize (in your code, it is called the Init event) – Initialize settings needed during the lifetime of the incoming web request. If the server control is a composite control, this will load the default items based in the CreateChildControls method.
-
Load – Perform actions common to all requests. This is the usual event that the page developer does his/her processing.
-
PreRender – Perform any updates before the output is rendered. This is the usual event that control developers does his/her processing. This event is the last one that can do the last major modifications by the developer.
-
Save View State - The ViewState property of a control is automatically persisted to a string object after this stage. Normally, this is stored to a hidden field on the page but can be persisted to another medium if need be.
-
Render – Generates output to be rendered to the client. Note that not much functionality is able to be done here.
-
Dispose – Perform any final clean-up before the control is torn down. Database connections, files and such should be closed at this point.
-
Unload – Perform any final clean-up before the control is torn down.
This is the life cycle or order of events that the page undergoes during post back (note that some of these events do not have a description due to the fact that it was described in the above listing):
-
Initialize – After the normal initializing is done, as described above, it will then do the following:
-
Load View State – Loads the ViewState from the persistent medium. It then searches for the controls to load its ViewState.
-
Process Post Back Data – Processes incoming data. This will only fire on controls that implement the IPostBackDataHandler interface.
-
Load – After the normal Load event is done, as described above, it will then do the following.
-
Sends post back notifications – Raise change events in response to state changes between the current and previous postbacks. This will only fire on controls that implement the IPostBackDataHandler interface.
-
Handle Post Events – Raises the event that the client-side triggered the post back for. First, it searches for the control that the event was targeted for. Once found, it determines if the control implements IPostBackEventHandler interface. If the interface is implemented, the RaisePostBackEvent method is called with a string argument which will then determine what event to raise.
-
PreRender
-
Save View State
-
Render
-
Dispose
-
Unload
There is some behaviour that some of us is not consciously aware of but we use it to our advantage. The one behaviour is the first control to be alive will be the Page. Then its children starts to live, and their children starts to live and so on down until all the descendants are alive. The last control(s) that become alive is the first control(s) to die; therefore, we can conclude the page is the last one to die. To exagurate on this fact, we will then talk in lame-man's terms:
When the page begins its life, it would start with the Init event. Once the page has lived through the Init event, it will call the child(rens) Init event. Once those childrens' Init event has fired, their child(rens) starts to live through Init event and so it carries on down the hierarchy chain; for every, individual event as well. Therefore, the page starts life earlier (the parent control will live first).
I mentioned that the first control to live is the last to die. The reason is that all the controls in the page will execute the Unload event. When the Unload event is finished on the control that is located the furthest down the hierarchy, the control is finished. Its parent will then do the final finishing ups and then will finish its self. This bubble effect will continue until the Page gets the go ahead to do the finishing touches - therefore, the page is the last to die (the last control to "die").
Although many of us do not notice the following described behaviour now, whenever a control is dynamically added to a control collection, it will be given life... a rather speedy one! The control that was dynamically added plays catch up with the life cycle to the current point of the parent's point in its life cycle. For example, if the parent control is in its PreRender event and a control is dynamically added to the control collection of this parent, the child control will catch up to, and including the PreRender event.