Geeks With Blogs
Geekette Mai Blog

 

Creates standard web pages that are derived from the ASP.NET Page class.  When an ASP.NET web page is requested from the web server, the code-behind class for the page goes through a sequence of steps to initialize and load the user interface controls, read the data from the database and display the page.

This sequence of steps is called the page lifecycle as shown below:

  • Initialization:  During this stage the page and all of the controls within the page (control hierarchy) are instantiated.  This includes any tables, textboxes and buttons.  Any event handlers to handle click events for buttons, sorting hyperlinks, and text changed events for filters are initialized at this stage.

  • Loading: The data being displayed or edited on this page is loaded from the data-source and “bound” to each of the user interface controls.  The binding process involves formatting the information as well as loading any additional information needed such as the contents of drop-down lists.  Most of the work is performed during this step.

  • Event Handling: Post-back events caused by server controls will be handled. These event handlers include events such as button clicks, SelectedIndexChanged of a dropdown list, TextChanged of a textbox and sorting hyperlink events, Note that when button clicks happen, the Init and Load event handlers will be executed as well.  Iron Speed Designer generates code for the Init and Load handlers that checks for the IsPostBack property before deciding whether to execute any code.  As generated, the Init and Load handlers do not execute any code during event handling since the code is surrounded by If Not(Me.IsPostBack), so the event handler must perform all actions including loading data from the database if necessary.

  • Rendering: The HTML of the page and all controls are sent to the browser for rendering.  Iron Speed Designer generates code for the PreRender method that checks to see if this is the first time a page is being displayed or whether this is a postback caused by an event such as a button click.  During the initial page lifecycle when the page is first being displayed, the PreRender method does not perform any actions.  During event handling postbacks, PreRender checks to see whether any data is required to be reloaded because of button clicks or other events.  If the data needs to be loaded again based on the new settings, PreRender calls LoadData to retrieve data from the database.

All pages generated derive from the Microsoft .NET Framework’s Page class, so they follow the same page lifecycle described above.  The classes generated extend the Page class to support loading data from the database and to provide more enhanced user interface controls that support data type formatting and validation.

Overrides and Events

At each state of the page lifecycle, the Microsoft .NET Framework sends an event notification to the page.  You can handle an event to customize any aspect of the page before it is displayed to the user.  By handling an event, you can add functionality to your page, but cannot replace the existing functionality that is already provided by the underlying classes.

You can define any number of event handlers for a single event.  For example, the Init event can be handled by multiple event handlers.  In general, if you want to add functionality, it is better to define your own event handler, rather than modifying an existing event handler.  Note that the order of calling of event handlers for an event is not guaranteed.  The event handlers may be called in any order, so care must be taken to ensure that there are no dependencies betweem event handlers for the same event.

Note that event notifications are sent after the completion of each phase.  For example, the Init event is sent when the initialization of all the controls is complete and the Load is sent after the loading of the data and the controls of the page is completed.

Iron Speed Designer generates code to handle these standard events such as Init and Load.  The generated code then calls other methods to perform the specific tasks such as loading of the data or binding data to the user interface controls. 

You can customize or change the behavior of any control by either:

  • Adding your own event handler:  If the goal is to add to the functionality, you can simply add your own event handler.

  • Changing the generated event handler or method:  Generates code in two sections.  Section 1 is generated once, and never overwritten.  Section 2 will be overwritten whenever controls are added, modified or deleted.  All generated event handlers are in Section 2 and should not be modified.  To customize the behavior, Iron Speed recommends modifying the methods that are called by the event handlers.  These methods are defined in Section 1 and can be modified easily.

  • Overriding the generated method:  Any of the generated methods can be overridden in the sub-classes.  The sub-classes generated in Section 1 will not be overwritten, so the behavior can be easily customized by overriding the method in one of the subclasses.  Unlike event handling, overriding a method for a class allows you to replace the underlying functionality being performed.  For example, you can override the LoadData method of a record control class to read the data from the database and bind it to each of the controls.  If you override a method, you have a choice of calling the base method or simply replacing all of the functionality provided by the base class.

Each of the generated files contains two regions.  The first region is generated once and never overwritten.  This is called Section 1 and may also be referred to as the “safe” region of a file.  The second region may be regenerated during a rebuild and should not be modified.  This is called Section 2 and may also be referred to as the “gen” region of a file.

C#:

#region "Section 1: Place your customizations here."

 

     // Contains derived classes - you can override any method defined in inheritted classes.

     // Contains methods that can be modified.

 

#endregion

 

#region "Section 2: Do not modify this section."

 

     // Contains classes and methods that should not be modified.

     // Everything in this section may be overwritten during a rebuild.

 

#endregion

Visual Basic .NET:

#Region "Section 1: Place your customizations here."

 

     ' Contains derived classes - you can override any method defined in inheritted classes.

     ' Contains methods that can be modified.

 

#End Region

 

#Region "Section 2: Do not modify this section."

 

     ' Contains classes and methods that should not be modified.

     ' Everything in this section may be overwritten during a rebuild.

 

#End Region

Posted on Thursday, July 20, 2006 8:32 PM | Back to top


Comments on this post: The Page Lifecycle

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Mai Nguyen | Powered by: GeeksWithBlogs.net