Coming from a Windows application development background several years ago into the web based development world of ASP.NET took a little getting used to.
In the desktop development world I was accustomed to creating an application where when you click on a button the code that gets executed is right there in the application and there is no delay other than perhaps updating data in a database.
Over the past few months I've realized that I've taken my learning and experience for granted and what seems like common sense to me now wasn't always that easy to wrap my head around at first.
As a result this topic will be a bit of a back to the basics type of talk.
There are several challenges that need to be overcome as a web developer with the first one being that we usually have the server-side code on our development machine.
When we launch the application the browser's behavior feels somewhat like a desktop application in that responses are generally very quick.
Unfortunately, having the server-side code on your development machine gives a false sense of performance. Depending on how your web application is setup, your end user might be halfway around the world or have a really slow connection.
Also, the more trips your web application makes to the server, the slower the application will be. Some trips are unavoidable but it's important to remember this and avoid unnecessary trips where possible.
Having your server-side code on your development machine also tends to cause confusion especially if you handle events in your server-side code as well as events in the browser.
The events that happen in the browser and the events that happen in your server-side code have nothing to do with each other even though they sometimes have similar names.
When we talk about page life cycle in the rest of this discussion we are talking about the process on the web server of building up and passing the requested page back to the browser. We are not talking about the behavior of the page within the browser.
When someone requests your .aspx page from a browser, ASP.NET creates an instance of the code behind class for that page.
Once the code behind class instance is created several events are fired allowing you the opportunity to make modifications to the content of the page at different points during the page processing.
Once the page processing is complete the page content is written to an output stream and then the code behind class instance is destroyed.
Each time the browser requests the page, or posts data back, the page life cycle begins again.
The following is a simple illustration of what happens when a browser requests an .aspx page from the web server:
(click to view the image full size)
The following is a breakdown the events that get fired during the page processing:
One thing to note if you are using a System.Web.UI.Page derived class is that besides the events that fire, you can also override the base class methods.
For example, perhaps you wish to override the Validate method to make sure custom validation is handled in a specific way (some methods like the Validate method are only called during a postback).
When you override a base class method you must call the base class method from your new method to make sure the page processing continues to do what it needs to do.
In conclusion always try to remember that the server-side code does not sit in the browser and has nothing to do with the events that fire within the browser.
Each time you request data from, or pass data to, the server-side code a new page object instance needs to be created and will be destroyed once the rendered results are passed to the output stream.
This was a very quick high level discussion on the ASP.NET Page Life Cycle. If you are looking for a more comprehensive discussion on the topic you can view the following MSDN article: http://msdn.microsoft.com/en-us/library/ms178472.aspx
In the desktop development world I was accustomed to creating an application where when you click on a button the code that gets executed is right there in the application and there is no delay other than perhaps updating data in a database.
Over the past few months I've realized that I've taken my learning and experience for granted and what seems like common sense to me now wasn't always that easy to wrap my head around at first.
As a result this topic will be a bit of a back to the basics type of talk.
Several Challenges as a Web Developer...
There are several challenges that need to be overcome as a web developer with the first one being that we usually have the server-side code on our development machine.
When we launch the application the browser's behavior feels somewhat like a desktop application in that responses are generally very quick.
Unfortunately, having the server-side code on your development machine gives a false sense of performance. Depending on how your web application is setup, your end user might be halfway around the world or have a really slow connection.
Also, the more trips your web application makes to the server, the slower the application will be. Some trips are unavoidable but it's important to remember this and avoid unnecessary trips where possible.
Having your server-side code on your development machine also tends to cause confusion especially if you handle events in your server-side code as well as events in the browser.
The events that happen in the browser and the events that happen in your server-side code have nothing to do with each other even though they sometimes have similar names.
ASP.NET Page Life Cycle...
When we talk about page life cycle in the rest of this discussion we are talking about the process on the web server of building up and passing the requested page back to the browser. We are not talking about the behavior of the page within the browser.
When someone requests your .aspx page from a browser, ASP.NET creates an instance of the code behind class for that page.
Once the code behind class instance is created several events are fired allowing you the opportunity to make modifications to the content of the page at different points during the page processing.
Once the page processing is complete the page content is written to an output stream and then the code behind class instance is destroyed.
Each time the browser requests the page, or posts data back, the page life cycle begins again.
The following is a simple illustration of what happens when a browser requests an .aspx page from the web server:
(click to view the image full size)
The following is a breakdown the events that get fired during the page processing:
- PreInit
- Create/recreate dynamic controls
- Apply master page or theme dynamically
- Read or set profile property values
- Init
-
Controls receive an Init event before this event is called on the page
It is now safe to read or initialize control properties
-
Controls receive an Init event before this event is called on the page
- InitComplete
-
ViewState has now been turned on
At this point you can add changes to ViewState that you would like persisted after the next postback
-
ViewState has now been turned on
- PreLoad
- Page has finished loading in ViewState data for itself and all controls after it has processed postback data
- Load
- This event happens before the OnLoad events of the controls
- LoadComplete
-
Control events have now completed (e.g. Maybe the postback was due to a drop-down selection change event. The drop-down selection change event will fire after the Load event and before this LoadComplete event)
All controls on the page have now been loaded
-
Control events have now completed (e.g. Maybe the postback was due to a drop-down selection change event. The drop-down selection change event will fire after the Load event and before this LoadComplete event)
- PreRender
-
All controls, including child controls of composite controls, have been created
The PreRender event fires for the page first and then for each control
Make any final changes to the page or the controls now before the rendering starts
-
All controls, including child controls of composite controls, have been created
- PreRenderComplete
- Raised after each data bound control, whose DataSourceID property is set, calls its DataBind method
- SaveStateComplete
-
Raised after view state and control state have been saved for the page and for all controls
Changes to the page or controls at this point can affect rendering but will not be retrieved on the next postback.
-
Raised after view state and control state have been saved for the page and for all controls
- Render
-
(This is not an event)
The Render method of each control is called at this point to stream out the markup needed to send to the browser
-
(This is not an event)
- Unload
-
Raised for each control first
This event allows the controls and page to do final clean up like closing files and database connections.
-
Raised for each control first
One thing to note if you are using a System.Web.UI.Page derived class is that besides the events that fire, you can also override the base class methods.
For example, perhaps you wish to override the Validate method to make sure custom validation is handled in a specific way (some methods like the Validate method are only called during a postback).
When you override a base class method you must call the base class method from your new method to make sure the page processing continues to do what it needs to do.
In Conclusion...
In conclusion always try to remember that the server-side code does not sit in the browser and has nothing to do with the events that fire within the browser.
Each time you request data from, or pass data to, the server-side code a new page object instance needs to be created and will be destroyed once the rendered results are passed to the output stream.
This was a very quick high level discussion on the ASP.NET Page Life Cycle. If you are looking for a more comprehensive discussion on the topic you can view the following MSDN article: http://msdn.microsoft.com/en-us/library/ms178472.aspx