Author: Dino Esposito, Wintellect
Time: August 2003
Application to: Microsoft ASP.NET
Summary:
Discuss the details of the event model for establishing an ASP.NET web page and the various processes transformed into HTML. The ASP.NET HTTP runtime manages the object pipe that converts the request URL into a specific instance of a page class, which will be converted into a general HTML text format. This article explains how to control pages in the event of each page lifecycle, how to control the implementation of these standard behavior, and the developer intervene.
Introduction
Whenever IIS is requesting an ASP.NET page that is accommodated, it is always necessary to transfer the request to the ASP.NET HTTP pipe. The HTTP pipe is a set of controlled objects that handle requests in order and convert these requests into general HTML text. The entrance to the HTTP pipe is an HTTPRuntime class. The underlying structure of ASP.NET establishes an instance of this class (note, one work process) only supports a running ASP.NET application domain).
The HTTPRuntime class selects an HTTPAPPLCATION object from the internal boot and works when the request is received. The main job of the HTTP application management program is to find such a category to handle requests. For example: When requesting a .aspx resource, handle the handle is an instance from the PAGE inherited class. Requesting the type of resource and the relationship of the relevant handler of the handle is saved in the application's configuration file. More specifically, this mapping table is defined in the
An extension can be linked with a handle, more generally, is associated with a handle factory class. In all cases, the HTTPApplication object that is responsible for processing the request gets a specific implementation of the IHTTPHANDLER interface. If the relationship is processed according to the HTTP handle, the return class is directly implemented interface; if the resource is bound to a handle factory, it will have to pass another stage: the handle of the IHTTPHANDLERFActory interface. The GetHandler Method of the factory class will return an object based on IHTTPHANDLER.
How to end a cycle or turn off a page request when HTTP is running? The ProcessRequest method of the IHTTPHANDLER interface has this feature. Calling the method of the object that is the object being requested, the ASP.NET underlayer opens a process to generate the browser.
Page class
The type of HTTP handle handle on a page depends on the URL. When this URL is first accessed, a new class will be built and dynamically compiled into an assembly. A process for analyzing the ASPX files from the ASPX files out of this class code. By default, this class is added to a namespace called ASP and uses the URL as the class name of this class. For example, if the requested URL is page.aspx, this class is ASP.PAGE_ASPX. This class name can be modified by setting the ClassName property of the @PAGE pre-processed instruction.
The base class of the HTTP handle is the Page class. This class defines a set of minimum methods and properties sets, which are shared by all pages handle. The IHTTPHANDLER interface is concrete.
In the other and the above-described case, the basic class of the handle of the actual processing page is not a PAGE class, but a class of classes. This happens when using the post code mode. Postcodes are techniques that separate C # or VB.NET code and page separation. Page code is a set of event handle handles and other methods that define various behaviors of the page. These codes can be defined in the inline form, or you can write with external classes - this is post-code mode. The postcode class is inherited from the PAGE class, but some other methods are resolutely defined. After the post-class code class specified the page, this post-coded code is as an HTTP handler. In other cases, if the PageBaseType property of the application's configuration file is defined, the HTTP handle is not based on the PAGE class, for example:
The PageBaseType property indicates the type and assembly containing the parent class that contains the page processing handle. These classes from the Page class automatically give some collection of usual or extended methods and attributes to the handle.
Page life cycle
Once the HTTP page handle handle is clearly defined, the ProcessRequest method for handling the handle when the ASP.NET runtime is runtime. Typically, there is no need to change the implementation method provided by the PAGE class.
The page execution is starting from the FrameworkInitialize method, this method is a page build control tree. This method is protected by the TemplageControl class and is a virtual method. Any handle that is dynamically generated for the ASPX resource covers the method. In this method, all controls of the page are built.
Next, the ProcessRequest method makes the page experience a different stage: initialization, load view status information, return data, load page code, and server events that perform back. After this, the page is converted to the display mode: collect the updated view status; generate HTML code and transferred to the console. Finally, the page is uninstalled, and all the services requested is over.
In various stages, the page handles events associated with Web controls, programmers code can intervene and solve certain problems. Some events are designed specifically for those inline controls and controls that cannot be handled in .ASPX code level.
A page to solve such an event, which can be clearly registered as a suitable handle. However, in order to have backward compatibility with the original Visual Basic programming mode, ASP.NET also supports the form of implicit events. By default, the page will find and event-related method names; if you find and match the method, this method is considered a handler for this event. ASP.NET provides six special method names, they are page_init, page_load, page_database, page_prender, and page_unload. These methods These methods have been defined in the PAGE class, they are the handler of the corresponding event. HTTP runtime will automatically bind these methods to related page events without requiring programmers to write code that connects events and methods. For example, in the following code, the Page_Load method and the page load event are associated with:
THISLOAD = New EventHandler (this.page_load);
This automatic recognition is controlled by the AutoeventWireUp property of the @Page pre-instruction. If this property is set to false, the application must explicitly declare and event-related methods. The page that does not automatically associate page event code will be made fast because they don't need to do too much work on the match. This property can be turned off in the Visual Studio.net engineering. However, the default setting is True, which means that the Page_Load method is automatically identified and associated with the relevant event. The page execution contains several phases listed in the following table, they are marked as an application level event, and may also be some protected, redefined methods:
stage
Page event
Refrequent method
Page initialization
Init
View status loading
LoadViewState
Recycling data processing
The LoadPostData method for the iPostBackDataHandler interface is implemented in the control.
Page loading
Load
Recycling data change check
The RaisePostDataChangeDevent method of the IPostBackDataHandler interface is implemented in the control.
Recycling event processing
Recycling event defined in the control
The RaisePostBackeVent method for the iPostBackeVentLer interface is implemented in the control.
Page pre-return phase
Prerender
Page return phase
Render
Page unloading phase
Unload
The phase listed in the above table is invisible on the page level, which is just when the author of the server control is written in the class that is inherited in Page. Init, LOAD, PRERENDER, UNLOAD, coupled to the return processing event defined in the inner control, which constitutes the entire life cycle of the page.
Performance of each stage
The first phase of the page life cycle is initialized. This phase is described by the init event, which is executed after the control tree is built. In other words, when the init event occurs, all the controls in the .aspx file are instantiated and given the default value. Any settings needed in the page life cycle can be initialized in the init event. For example, at this stage, the control can load the external touch file or establish a handle for the event. It should be noted that any view status information cannot be used at this stage.
Immediately after the initialization is completed, the page framework is loaded with the page. The view status is a collection of name / value pairs, the control or page saved here, which must be stable during the entire web request. The status represents the context of the page. Typically, it saves the status of the control when executed on the server last time. The view status is empty when requested at the first page of the session. By default, attempting status is saved in a hidden domain, this hidden domain is automatically added to the page. The name of this hidden domain is __viewstate. If you override the LoadViewState method - the Control class is declared as protected method - component developers can control the saving of the view status and how it is mapping in the internal state.
LoadPageStateFormPersistencemedium and corresponding SavePageStateTopistenceMedium methods can be used to load or save view status to other storage intermediaries, such as sessions, databases, or files on the server. The LoadViewState method is not the same, the method mentioned above can only be used in the inheritance class of Page.
Once the view status is loaded, the controls in the page are given the same state as the previous sector to the browser. The next phase is to update them so that it is consistent with the changes that occur in the server. In the return data processing phase, the control updates their status to consistent with the status of the client's HTML element. For example, server control TextBox has HTML control with it. In the return data phase, the TextBox control will get the value of the tag, and use him to update his internal status. Each control can obtain its own data from the return data and update your status. The TextBox control will update its Text property, the same, Checkbox control will also refresh their checked properties. The matching of server controls and HTML elements is performed by the ID of the two. In the final phase of the return data processing, all page controls reflect the previously updated state, which are caused by the changes of the client. Next, the LOAD event will be executed by the page.
There are some controls, and if some sensitive properties have changed in two requests, they need to respond to this and complete certain tasks. For example, if the text of the client's TextBox control changes, this control has inspired the TextChangeD event. Depending on the data from the client, if one or more attributes of the control changes, each control can accurately inspire the appropriate events. These controls have implemented the iPostBackDataHandler interface. The loadPostData method in this interface is executed after the LOAD event. By redefining the LoadPostData method, the control can verify the changes that occur in both requests and provision the relevant event handler.
Key events in a page cycle are events that are excited by the client event to execute a code in the server. For example, when the user clicks on a button, the page needs to return. The process of this event is started from the collection of buttons ID and values. If the control is an iPostBackeVentHandler interface (Button and LinkButton are like this), the page architecture will call the RaisePostBackevent method. The specific situation of this method is depends on the type of control. The Button and LinkButton control mentioned above will look for the Click event handler.
After processing the return incident, the page is ready to be sent. This stage begins with the prerender event. This is a good time for the actions that need to be performed before the view information is saved and the result is sent before the view information is saved and the result is sent. The next step is SaveViewState, all space and page itself saves the collection content of the view status. Next, the view state is serialized, hash encoded, base64 encoded, and saved in the __viewstate hidden domain.
The transmission mechanism of each control can be changed by redefining the Render method. This method builds an HTML Writer object that generates HTML code for the control. The default execution of the render method in the Page class contains recursive calls to all member controls. The page calls a render method for each control and buffered HTML output.
The final stage of the page lifecycle is uninstalling event, which is excited before the page object disappears. In this incident, you should release any critical resources (for example: files, graphics objects, database connections).
Finally, the browser has received an HTTP response and displayed the page.
to sum up
The ASP.NET page object model is a characteristic novel model because it is based on an event mechanism. A web page consists of some controls that have a wealth of HTML-based user interfaces while interacting through events and users. Build an event model in the Web Application Context Environment is challenging. It is amazing that the event generated by the client and the code on the server is amazing. This process is the same as HTML is also visible, but they are properly modified when they need it. To understand each phase of the page lifecycle, how the page object is instantiated and is used by HTTP runtime, and it is important to master this model.
About the Author:
Dino Esposito is Rome's technical trainer and consultant. Members of the Wintellect team, Dino spent a lot of time to teach ASP.NET and ADO.NET in Europe and the United States while providing consultation. It is worth mentioning that Dino provides ADO.NET courseware for Wintelle and writing an article for the Cutting EDGE column of MSDN Magazine. Contact: mailto: dinoe@wintellect.com
