Page event Loading Sequence in Asp.net)

Msdn:
Events on ASP. NET master pages and content pages
Both the master page and content page can contain the event processing of the control.Program. For controls, events are processed locally, that is, controls on the Content Page trigger events on the Content Page, and controls on the master page trigger events on the master page. Control events are not sent from the content page to the master page. Similarly, you cannot process events from the master page control in the Content Page.

In some cases, the same event is triggered on the Content Page and master page. For example, both triggers the init and load events. The general rule for triggering an event is that the initialization event is triggered from the innermost control to the outermost control, and all other events are triggered from the outermost control to the innermost control. Remember that the master page is merged into the content page and considered as a control in the content page, which is useful at 01:10.

The following shows the sequence of events after the master page and content page are merged:

The init event of the master page control.

Content Control init event.

The init event on the master page.

Content Page init event.

Content Page load event.

Master page load event.

Content Control load event.

Content Page prerender event.

The prerender event on the master page.

The prerender event of the master page control.

Content Control prerender event.

The event sequence on the master page and content page is not important to page developers. However, if the event handler you create depends on the availability of some events, you will find it helpful to understand the event sequence on the master page and content page.

 

 

 

 

Order of loading page events in Asp.net

 

The page will be activated in the following order:

Page. preinit
Page. init
Page. initcomplite
Page. Preload
Page. Load
Page. loadcomplete
Page. prerender
Page. prerendercomplete

If the page inherits from another page, such as basepage: system. web. UI. page, some extensions are made in the basepage, such as permission check. When other pages inherit from the basepage, the order of activation of the events of the basepage and the final page is:

Ui. preinit
Page. preinit
Ui. init
Page. init
Ui. initcomplite
Page. initcomplite
Ui. Preload
Page. Preload
Ui. Load
Page. Load
Ui. loadcomplete
Page. loadcomplete
Ui. prerender
Page. prerender
Ui. prerendercomplete
Page. prerendercomplete

If masterpage is used, the events in masterpage and those in contentpage are activated in the following order:

Contentpage. preinit
Master. init
Contentpage. init
Contentpage. initcomplite
Contentpage. Preload
Contentpage. Load
Master. Load
Contentpage. loadcomplete
Contentpage. prerender
Master. prerender
Contentpage. prerendercomplete

Furthermore, if contentpage inherits the basepage, the execution sequence of each event is changed:

Ui. preinit
Contentpage. preinit
Master. init
Ui. init
Contentpage. init
Ui. initcomplite
Contentpage. initcomplite
Ui. Preload
Contentpage. Preload
Ui. Load
Contentpage. Load
Master. Load
Ui. loadcomplete
Contentpage. loadcomplete
Ui. prerender
Contentpage. prerender
Master. prerender
Ui. prerendercomplete
Contentpage. prerendercomplete

I did not find the Asp.net 1.1 I have learned now. It is estimated that it should be Asp.net 2.0,

But it does not matter, which makes me know the order in which they are loaded during inheritance.

That is, the inherited page is loaded first. If the inherited page has an inherited page, the inherited page is loaded first.

It is actually a very simple content. Write down the page event by the way (I don't know if 1.1 is the case)

Event processor name
Occurrence time
 
Page_init
Load and initialize the Server Control in the view status of the web form.

This is the first step in the web form lifecycle.
 
Page_load load Load the server control on the page object. The view status information can be used at this time,

Therefore, you can useCodeTo change the space settings or display text on the page.
 
The page_prerender application will render the Page Object
The page_unload page is detached from the memory.
An unhandled error occurred in page_error.
Page_aborttransaction transaction processing terminated
Page_committransaction transaction processing accepted
Page_databinding binds the server space on the page with the data source
The page_disposed Page Object is released from the memory. This is the last event in the lifecycle of the page object.

Init, load, and prerender event execution sequence:
1) Init event of the control
2) Init event on the page where the control is located
3) Load events on the page where the control is located
4) Load events of controls
5) prerender event on the page where the control is located
6) control prerender event

Rule:
1) The init event is triggered from the innermost control (including the user control and common control) to the outermost control (page, load, prerender, and other events are triggered from the outermost control to the innermost control;
2) The execution sequence of the same events between controls depends on the control's position on the page from left to right, from top to bottom.

Note:
1) Remember that the user control is also regarded as a control in the page;
2) using a user control as a special page, the user control itself and its contained controls follow the same rules;
3) Sometimes the onload event of the client body object is used in the client program (such as JavaScript). Note that this client event is the final execution, that is, all events on the server are executed only after they are executed.

Test environment:
Windows2000 Pro + iis5.0 + DOTNET framework1.1

========================================================== ========================================================== ===

Repost an article about the Page Object ModelArticle. When it's okay, read it twice and try again later :).
ASP. NET page Object Model
Dino esposito
Wintellect
August 2003
 
Applicable:
Microsoft ASP. NET
Abstract: Understand the event model created for ASP. NET web pages and the phases of converting web pages to HTML. ASP. NET is responsible for managing object pipelines during HTTP runtime. These objects first convert the request URL to a specific instance of the page class, and then convert these instances to pure HTML text. This article will explore events that serve as page lifecycle markers and how controls and page writers intervene and change standard behavior. (This article contains links to English sites .)

Directory
Introduction
Real page class
Page Lifecycle
Stages of execution
Summary

Introduction
Each request to the Microsoft ASP. NET page processed by Microsoft Internet Information Service (IIS) is handed over to the ASP. net http pipeline. An HTTP pipeline consists of a series of hosted objects that process requests in sequence and convert URLs to plain HTML text. The HTTP pipeline entry is the httpruntime class. The ASP. net structure creates an instance of this type for each appdomain in the auxiliary process. (Note that the auxiliary Process maintains a specific appdomain for each currently running ASP. NET application .)

The httpruntime class obtains the httpapplication object from the internal pool and schedules the object to process the request. The main task completed by the HTTP application manager is to find the class that will actually process the request. When a. aspx resource is requested, the handler is the page handler, that is, the instance of the class inherited from the page. The associations between resource types and handler types are stored in the application configuration file. More specifically, the default ing set is defined in the

<Add verb = "*" Path = "*. aspx" type = "system. Web. UI. pagehandlerfactory"/>
Extensions can be associated with the handler class, and more are associated with the handler factory class. In all cases, the httpapplication object that processes the request will obtain an object that implements the ihttphandler interface. If the associated resource/class is parsed Based on the HTTP handler, the returned class implements the interface directly. Additional steps are required if the resource is bound to the handler factory. The handler factory class implements the ihttphandlerfactory interface. The gethandler method of this interface returns an ihttphandler-based object.

How does the HTTP runtime end this loop and process page requests? The processrequest method is very important in the ihttphandler interface. By calling this method on the object that represents the requested page, ASP. NET structure will start the process that will generate browser output.

Real page class
The type of the HTTP handler for a specific page depends on the URL. When a URL is called for the first time, a new class is built, which is dynamically compiled into an assembly. The result of the analysis process of the. aspx resource is a class.Source code. This class is defined as an ASP Component of the namespace and is assigned a name to simulate the original URL. For example, if the end of a URL is page. aspx, the class name is ASP. page_aspx. However, the class name can be controlled programmatically by setting the classname attribute in the @ page command.

The base class of the HTTP handler is page. This class defines the minimum set of methods and attributes shared by all page handlers. The page class implements the ihttphandler interface.

In many cases, the base class of the actual processing program is not page, but other classes. For example, if code separation is used, this situation occurs. Code separation is a development technology that isolates the Code required for the page into a separate C # and Microsoft Visual Basic. Net classes. The page code is a set of event handlers and helper methods that really determine the page behavior. You can use the <SCRIPT runat = Server> flag to inline define the code, or place it in an external class (code separation class. The code separation class is a class that inherits from page and uses additional methods. It is specified as the base class of the HTTP handler.

In another case, the HTTP handler is not page-based, that is, the <pages> section of the application configuration file contains the redefinition of the pagebasetype attribute.

<Pages pagebasetype = "classes. mypage, mypage"/>
The pagebasetype attribute specifies the type and assembly of the base class containing the page handler. This class exported from page automatically grants custom methods and attribute sets for Handler extensions.

Page Lifecycle
After fully identifying the HTTP page handler class, ASP. NET will call the processrequest method of the handler to process the request when running. Generally, you do not need to change the implementation of this method because it is provided by the page class.

This implementation starts from calling the frameworkinitialize method for building the control tree for the page. The frameworkinitialize method is a protected Virtual Member of the templatecontrol class (the page itself is exported from this class. All the handlers dynamically generated for. aspx resources will overwrite frameworkinitialize. In this method, the entire control tree of the page is constructed.

Next, processrequest makes the page go through various stages: initialization, loading view status information and sending back data, loading page user code, and executing the sending back server events. Then, the page enters the display mode: collect updated view status, generate HTML code, and then send the code to the output console. Finally, the page is uninstalled and the request processing is complete.

In each stage, the page triggers a few events that can be intercepted and processed by Web controls and user-defined code. Some of these events are dedicated to embedded controls, so they cannot be processed at the. aspx code level.

The page for processing specific events should clearly register an appropriate handler. However, to be backward compatible with earlier Visual Basic programming styles, ASP. NET also supports implicit event hooks. By default, the page will try to match the specific method name with the event. If the implementation matches, the method is considered to be the handler that matches the event. ASP. NET provides six methods for specific identification: page_init, page_load, page_databind, page_prerender, and page_unload. These methods are considered to be the handler of the corresponding event provided by the page class. During HTTP runtime, these methods are automatically bound to page events, so that developers do not have to write the required bonding code. For example, if the method named page_load is bound to the load event on the page, you can skip the following code.

This. Load + = new eventhandler (this. page_load );
Automatic Identification of specific names is controlled by the autoeventwireup attribute of the @ page command. If this attribute is set to false, all applications that want to handle the event need to explicitly connect to the page event. Page performance is slightly better if you do not use auto-binding events, because no additional name or event matching is required. Note that all Microsoft Visual Studio. Net projects are created when the autoeventwireup attribute is disabled. However, the default setting of this attribute is true, that is, page_load and other methods are recognized and bound to associated events.

The following table lists several stages of page execution in sequence. The execution marks application-level events and/or protected and override methods.

Table 1: key events in ASP. NET page Lifecycle

Method for overwriting stage page events
Page initialization init
Load view status loadviewstate
The loadpostdata method in the control that implements the ipostbackdatahandler interface for processing the returned data
Load page
The raisepostdatachangedevent method in the control that implements the ipostbackdatahandler interface when sending a change notification.
The raisepostbackevent method in the control that implements the ipostbackdatahandler interface is implemented by any sending events defined by the control.
Prerender
Save view status saveviewstate
Display page render
Unload

Some of the stages listed above are invisible at the page level and only make sense for the server control writers and developers who want to create Classes exported from the page. Init, load, prerender, and unload, coupled with all the sending events defined by the embedded control, constitute the stages of the sending page.

Stages of execution
The first stage in the page lifecycle is initialization. The identifier of this phase is the init event. After the control tree of the page is successfully created, this event is triggered on the application. In other words, when the init event occurs, all controls declared statically in the. aspx source file are instantiated and Their default values are used. Controls can intercept init events to initialize all the settings required during the lifecycle of incoming Web requests. For example, the control can load an external template file or set the event handler. Note that the view status information is not available.

After initialization, the page framework loads the view status of the page. View status is a set of name/value pairs. In this collection, the control and page itself store all information that must always be valid for all Web requests. The view status indicates the call context of the page. Generally, it contains the status of the controller when the page was last processed on the server. When a page is requested for the first time in a session, the view status is empty. By default, the view State is stored in a hidden field that is silently added to the page. The field name is _ viewstate. By overwriting the loadviewstate method (the control class is protected and can be overwritten), component developers can control the storage mode of the view State and the way in which the view State content is mapped to the internal state.

Some methods (such as loadpagestatefrompersistencemedium and its corresponding savepagestatetopersistencemedium) can be used to load the view status and save it to other storage media (such as sessions, databases, or server files. Unlike loadviewstate, the above method can only be used in the class exported from page.

After the view status is stored, the status of the control in the page tree is the same as that shown in the browser for the last time. The next step is to update their status to add changes to the client. The control has the opportunity to update its status in the data sending and sending process, so as to accurately reflect the status of corresponding HTML elements on the client. For example, the HTML element of the Textbox Control on the server is <input type = text>. In the send-back data phase, the Textbox Control retrieves the current value marked with <input> and uses this value to refresh its internal status. Each control extracts values from the returned data and updates some of its attributes. The Textbox Control updates its text property, while the checkbox control refreshes its checked property. The ing between server controls and HTML elements can be found through the IDs of the two.

At the end of the data re-sending phase, the status of all controls on the page will be updated using changes entered by the client. The load event is triggered on the page.

Some controls may exist on the page. When a specific sensitive property is modified in two different requests, a specific task needs to be completed. For example, if the text of the Textbox Control is modified on the client, the control triggers the textchanged event. Each control can trigger an event when one or more of its properties are modified to the value entered by the client. For the controls that are critical to these changes, the control implements the ipostbackdatahandler interface. The loadpostdata method of this interface is called immediately after the load event. By encoding the loadpostdata method, the control verifies whether a key change has occurred since the last request and triggers its own change event.

The key event in the page lifecycle is the event called to execute the server code. This code is associated with the event triggered by the client. When you click the button, the sending back page is displayed. The set of return values includes the ID of the button that starts the entire operation. If the control implements the ipostbackeventhandler interface (such as buttons and link buttons), the page Framework calls the raisepostbackevent method. The behavior of this method depends on the type of the control. For buttons and links, this method searches for the click event handler and runs related delegation.

After the event is returned, the page is displayed. This phase marks the prerender event. The control can use this time to perform the update operations that need to be performed before the view status is saved and the output is displayed. The next state is saveviewstate. in this state, all controls and pages update the content of their own viewstate set. The status of the serialized, hashed, and base64 encoded view is obtained. The view status is associated with the hidden field _ viewstate.

By overwriting the render method, you can change the display mechanism of each control. This method accepts the HTML writer object and uses this object to accumulate all the HTML text to be generated for the control. By default, the render method of the page class includes recursive calls to all member controls. For each control, the page calls the render method and caches HTML output.

The last flag in the page is the unload event, which occurs before the Page Object is deleted. In this event, you should release all key resources (such as files, graphical objects, and database connections) that may be occupied ).

After this event, the browser receives the HTTP response packet and displays the page.

Summary
The ASP. NET page object model is extremely novel and unique due to its event mechanism. Web pages are composed of controls that can generate rich HTML-based user interfaces and interact with users through events. Previously, setting event models in the context of Web applications was challenging. We are surprised to see that the events generated by the client can be solved by the server code, and the same HTML page can still be output after only some corresponding modifications are made.

Understanding this model is very important to understand the various stages of the page lifecycle and how page objects are instantiated and used by HTTP runtime.