![]()
VJs Mega Tip Of The Day
Reply
![]() |
|
From:
![]() ![]() VishalRJoshi
|
Today marks the completion of second season of VJs Tip Of The Day series. I
shall be back with the third season in new year 2005... Till then wish you
best luck and a wonderful festive season...
ASP.Net 2.0 Page Life Cycle
Abstract
This article talks about the way ASP.Net 2.0 page life cycle works, it
discusses the way ASP.Net page is created and displayed.
More Information
It is important for ASP.Net programmers to understand how their page is
created/processed and displayed by ASP.Net framework. Sometimes many
unexpected behaviors are seen in case incorrect data is accessed before or
after certain page events. Below is the information on how
System.Web.UI.Page methods execute. For keeping the article more users
friendly and also to avoid incorrect method calls for not-recommended
methods, I have discussed only those methods which I felt a user should know
about.
Without further delay let us start from the html source that is written for
the page. First of all the html source needs to be parsed to process the
page. This is done by a method in the Page called AddParsedSubObject().
Unless you override it, this method will automatically add Literal controls
to page's control collection. This is done by first creating a control
collection by calling CreateControlCollection() method.
As the child controls are parsed in the page the method AddedControl() is
called which is usually triggered when a control is added to another
control's control collection. As ASP.Net pages can be viewed on various
devices the method ResolveAdapter() returns the control adapter which is
responsible for rendering the control on the specific device or browser
requesting the ASP.Net page.
DeterminePostBackMode() is then invoked to find out what is the post back
mode used for the request. If the POST method is used for postback the web
form information is returned from the Context object. If the GET method is
used for postback, the information from query string is returned. If the
page is being requested for the first time, null is returned, many of us are
used to writing code in which we check the postback property and execute
specific logic, this is the method that helps the framework to get our this
specific code running correctly.
More granular control on the page life cycle is available in ASP.Net 2.0.
Now we have got additional events like "PreX" and "XComplete" to insert our
logic before and after the usual "X" events, which we have been working
with. The first such event to fire is PreInit(). This is the very beginning
of page's initialization and after the completion of this personalization
information is loaded and if there is any page theme then it is initialized.
I have talked more about these concepts earlier on the blog. Click Here for
more information.
After the PreInit() of the page, ResolveAdapter() for individual child
controls is called and then each of the control's Init event is fired. What
is interesting to note is that Init event of the child control is fired
before the Init event of the page and many a times in developing complex
ASP.Net applications if user plays with these events, without enough
information, then unexpected behavior might resulted.
After the Init event of the control, the TrackViewState() method is
triggered which will track the view state changes posted to server. It is
important to know that when control's view state data is being tracked with
the state bag, page's Init event and TrackViewState() are not yet fired.
This also results into unexpected behavior in case users are writing custom
controls or probably their own base page.
After the TrackViewState() of the child controls, the Init event of the page
is fired. This event initializes the page and then TrackViewState() of the
page is fired which tracks the changes to the page's state bag
After the TrackViewState() for the page is called InitComplete() event is
fired. This is the signal that initialization of the page and its child
control is done. Though what a user should know is that ViewState for the
page or the controls is not yet restored, if user tries to do anything
before this data is restored the required changes in the data from the
client which expected may not appear.
The view state is restored in the method LoadViewState() after whose
completion ViewState data is available for a user to work on.. There is then
EnsureChildControls() method which is invoked which makes sure that the
page's child controls get created.
In ASP.Net 2.0 a PreLoad() event available which would probably be the right
place for user to play around with objects before the universally used load
event is fired. For people who are writing base page classes and who want to
perform certain tasks before standard page load event this is the right
place to put their custom logic into.
After PreLoad() event, the Load() event of the page is fired. There is no
need to explain what one can do with this event, isn't it. But what should
be known is that page load event is fired before the control load event
unlike Init event which is fired first for the child controls and then for
the page. This also many times takes custom control writers by surprise as
they are expecting the control load to occur before actually the user logic
on page load is executed.
So after the page Load() event, control Load() event is triggered and then
the custom events like button clicks and others are fired. Many a times
users want some specific functionality to be executed in their base pages,
just after these postback events but also before PreRender when the pre
rendering logic starts. This kind of development methodology has created
issues when the derived classes call base methods before or after their
custom logic when otherwise was expected. That is the place where
LoadComplete() event of the page will come to use. The LoadComplete() will
be called after the custom event execution for the child control is over but
PreRender is not started.
After the LoadComplete() event PreRender() event of page is triggered
followed by the PreRendering of each child controls. PreRender() event has
always been the right place to put in the last logic before ViewState is
saved. But now there is a PreRenderComplete() event which is fired after all
the PreRender events of the child controls are fired, this will now be the
last chance to change the data before SaveViewState() of the page is fired.
After the SaveViewState of the page; the control SaveViewState() is fired.
SaveViewState() will save the changes that have happened to the data till
that point and then the page will be ready to be rendered.
LoadPageStateFromPersistenceMedium() and SavePageStateToPersistenceMedium()
are called before LoadViewState() and after SaveViewState() respectively. As
the name indicates the ViewState is persisted so that it can be used later
in the next call. I will talk in detail about how these methods work later,
but as of now it is just good to know what they do.
After the SavePageStateToPersistenceMedium(), SaveStateComplete() is fired,
which indicates that saving the state of the page is now complete.
After this the rendering of the page begins. First the
CreateHtmlTextWriter() is fired to create the HTML text writer and then page
and control Render are called. If the user wishes to change the look and
feel of the way their control is rendered this is the event to do it. When
the Render method completes Unload() for each child control is called and
then each child control's Dispose() is called. After disposing all the child
controls, the page Unload() event is fired and then the Page's Dispose() is
called.
In case of error, the execution directly jumps to the error handling and
then to unload and dispose events skipping the events in-between. This thus
covers the major execution of ASP.Net page life cycle.
Below is a quick summary of the methods in their invocation order:
System.Web.UI.Page.AddParsedSubObject
System.Web.UI.Page.CreateControlCollection
System.Web.UI.Page.AddedControl
System.Web.UI.Page.ResolveAdapter
System.Web.UI.Page.DeterminePostBackMode
System.Web.UI.Page.PreInit
System.Web.UI.WebControl.ResolveAdapter
System.Web.UI.WebControl.Init
System.Web.UI.WebControl.TrackViewState
System.Web.UI.Page.Init
System.Web.UI.Page.TrackViewState
System.Web.UI.Page.InitComplete
System.Web.UI.Page.LoadPageStateFromPersistenceMedium
System.Web.UI.WebControl.LoadViewState
System.Web.UI.Page.EnsureChildControls
System.Web.UI.Page.LoadViewState
System.Web.UI.Page.PreLoad
System.Web.UI.Page.Load
System.Web.UI.WebControl.Load
System.Web.UI.WebControl.OnClick
System.Web.UI.Page.LoadComplete
System.Web.UI.Page.PreRender
System.Web.UI.WebControl.PreRender
System.Web.UI.Page.PreRenderComplete
System.Web.UI.Page.SaveViewState
System.Web.UI.WebControl.SaveViewState
System.Web.UI.Page.SaveViewState
System.Web.UI.Page.SavePageStateToPersistenceMedium
System.Web.UI.Page.SaveStateComplete
System.Web.UI.Page.CreateHtmlTextWriter
System.Web.UI.Page.Render
System.Web.UI.Page.RenderChildren
System.Web.UI.WebControl.RenderControl
System.Web.UI.Page.CreateHtmlTextWriter
System.Web.UI.WebControl.Unload
System.Web.UI.WebControl.Dispose
System.Web.UI.Page.Unload
System.Web.UI.Page.Dispose
There are many methods which I have skipped and many methods which we
discussed are called multiple times on the basis of the existing conditions,
I have intentionally not discussed them, though what I have tried is to make
the user understand the things that happen in the background for a page to
work.
So this is how a single ASP.Net page's HTML comes on to our browser. Indeed
quite a bit amount of work behind the scenes right!! I hope you will be able
to unleash the potential of all these additional options available to you in
Whidbey timeframe. These are some of the reasons why I am so passionate
about Microsoft Technologies; they just keep getting better with every new
release.
PS: The above is my understanding of the Whidbey (ASP.Net 2.0) page life
cycle, if you think I have missed something or something is incorrectly
mentioned then please do drop in a mail at [EMAIL PROTECTED] so that I
can make the necessary corrections.
Vishal Joshi
Microsoft MVP .Net
If You Think YOU CAN... You Can...
http://VishalJoshi.Blogspot.com
http://www.microsoft.com/india/mvp/indiamvp.aspx
http://groups.msn.com/ChennaiNetUserGroup
http://groups.msn.com/CNUG-DAM
http://groups.msn.com/NetBloomingtonUserGroup
|
|
View other groups in this category.
![Click here!]()
![]() |
To stop getting this e-mail, or change how often it arrives, go to your E-mail Settings.
Need help? If you've forgotten your password, please go to Passport Member Services.
For other questions or feedback, go to our Contact Us page.
If you do not want to receive future e-mail from this MSN group, or if you received this message by mistake, please click the "Remove" link below. On the pre-addressed e-mail message that opens, simply click "Send". Your e-mail address will be deleted from this group's mailing list.
Remove my e-mail address from dotNET User Group Hyd.
|
|
