Asp.net| Object | Page Summary:
Discusses the details of the event model for establishing a ASP.net web page and the processes that are translated into HTML. The ASP.net HTTP runtime manages the object pipeline that converts the request URL into a specific instance of a page class, and then converts these instances into a generic HTML text format. This article explains the process of performing events that represent the lifecycle of each page, how to control page execution, and how developers intervene in these standard behaviors.
Introduced
The request is always forwarded to the ASP.net HTTP pipe whenever the ASP.net page that IIS accommodates is requested. An HTTP pipeline is a set of controlled objects that process requests sequentially and convert them to generic HTML text. The entrance to the HTTP pipe is the HttpRuntime class. Asp. NET's underlying structure establishes an instance of this class (HttpRuntime) for each application domain (AppDomain) worker process (note that a worker process can only support a running asp.net application domain).
The HttpRuntime class selects a Httpapplcation object from the internal program pool and makes it work when the request is received. The main job of the HTTP application manager is to find such a class that it can handle the request. For example, when you request an. aspx resource, the processing handle is an instance of the class that inherits from the page. The Relational mapping table for the type of the request resource and the associated handle handle is saved in the application's configuration file. More precisely, the mapping table is defined in the
<add verb= "*" path= "*.aspx" type= "System.Web.UI.PageHandlerFactroy"/>
An extension can be associated with a handle class and, more generally, with a handle factory class. In all cases, the HttpApplication object that handles the request gets an object that is specifically implemented from the IHttpHandler interface. If the relationship between the resource and the related processing class is handled according to the HTTP handle, the return class is directly implementing the associated interface; If the resource is bound to a handle factory, will have to go through another phase: the GetHandler method of the handle factory class that implements the IHttpHandlerFactory interface will return an object based on IHttpHandler.
How does the HTTP runtime end a cycle or close a page request process? The ProcessRequest method of the IHttpHandler interface has this function. The method that invokes the object representing the requested page, ASP. NET underlying structure to open a process to produce output for the browser.
Page class
The type of HTTP processing handle for a page depends on the URL. When this URL is first accessed, a new class is built and dynamically compiled into an assembly. The process of parsing an ASPX file separates the code of this class from the ASPX file. By default, this class is added to a namespace called ASP, and the URL is used as the class name for this class. For example, if the requested URL is page.aspx, then this class is asp.page_aspx. This class name can be modified by setting the ClassName property of the @page preprocessing directive.
The base class for HTTP handles is the page class. This class defines a set of minimal methods and properties that are shared by all page-handling handles. The page class implements the IHttpHandler interface specifically.
In another case corresponding to the above, the underlying class of the actual handle to the page is not a page class, but a different class. This occurs when the post code pattern is used. The post code is a technique that separates C # or vb.net code from the page. The page code is a set of event-handling handles and other methods that define the various behaviors of the page. The code can be defined inline with the <script runat=server> tag, or you can write in an external class form-This is the post code pattern. The following code class inherits from the page class, but it materializes or redefined some other methods. After you specify a descendant code class for a page, the following code class acts as an HTTP processing handle.
In other cases, if the PageBaseType property of the <pages> section is redefined in the application's configuration file, the HTTP processing handle is not based on the page class, for example:
<pages PageBaseType = "classes.myoage, MyPage"/>
The PageBaseType property indicates the type and assembly that contains the parent class of the page handling handle. These classes from the page class are automatically given a collection of common or extended methods and properties to handle handles.
Page life cycle
Once the HTTP page processing handle is explicitly defined, the ASP. NET runtime calls the ProcessRequest method of the handle handle to process the request. Generally, there is no need to change the execution method provided by the page class.
Page execution starts with the FrameworkInitialize method, which constructs the control tree for the page. The method is protected by the Templagecontrol class and is a virtual method. Any handle that is dynamically generated for the ASPX resource overrides the method. In this method, all the control trees of the page are constructed.
Next, the ProcessRequest method makes the page go through several stages: initializing, loading view state information, returning data, loading the page code, and performing a server event that is returned. After that, the page transitions to display mode: Collects the updated view state, generates HTML code, and passes it to the console. Finally, the page is uninstalled, and all of the requested services are over.
At various stages, the page handles events related to Web controls, where the programmer code can intervene and solve a problem. Some of these events are designed specifically for controls that are inline and that cannot be processed at the. aspx code level.
A page to resolve such an event, it can be clearly registered as the appropriate handle. However, in order to have post compatibility with the original Visual Basic programming model, ASP. NET also supports the form of implied events. By default, the page looks for the name of the method associated with the event, and if you find a method that matches the event, this method is considered a handler for the event. Asp. NET provides six specialized method names, they are Page_Init, Page_Load, Page_databind, Page_PreRender and Page_Unload. These methods are already defined in the page class, and they are handlers for the corresponding events. The HTTP runtime automatically binds these methods to related page events without requiring programmers to write code that links events and methods. For example, in the following code, the Page_Load method is associated with the Load event of the page:
This. Load + = new EventHandler (this. Page_Load);
This automatic recognition is controlled by the AutoEventWireup attribute of the @Page pre instruction. If this property is set to False, the application must explicitly declare the method associated with the event. Pages that do not automatically correlate page event code are quicker to perform because they do not need to do too much work on the match. This attribute can be turned off in Visual Studio.NET engineering. However, the default setting is true, which means that the Page_Load method is automatically recognized and associated with the associated event.
Page execution includes several stages listed in the following table, which are flagged as application-level events and may be protected, redefined methods:
Stage
Page Events
A method that can be redefined
Page initialization
Init
View state Load
LoadViewState
Postback data processing
The LoadPostData method of IPostBackDataHandler interface implemented in the control
Page load
Load
Return Data Change Check
The RaisePostDataChangedEvent method of IPostBackDataHandler interface implemented in the control
Postback event handling
A postback event defined in a control
The RaisePostBackEvent method of IPostBackEventHandler interface implemented in the control
Page pre-return stage
PreRender
Page return stage
Render
Page Unload phase
Unload
The stages listed in the previous table are not visible at the page level, and they are used only when the author of the server control writes the class that inherits from the page. Init, Load, PreRender, Unload, plus the return handling events defined within the nested controls, they form the entire lifecycle of the page.
Implementation at all stages
The first stage of the page life cycle is initialization. This phase is described by the Init event, which executes after the control tree is constructed. In other words, when the Init event occurs, all controls statically declared in the. aspx file are instantiated and given a default value. In the Init event, you can initialize any settings that you want in the page life cycle. For example, at this stage, the control can load an external version of the file or establish a processing handle for the event. It should be noted that any view state information is not available at this stage.
The page frame loads view state for the page immediately after initialization is complete. View state is a collection of name/value pairs, and the data saved by a control or page must be solid throughout the Web request process. The view state represents the context of the page. Typically, it holds the state of the control when the page was last executed on the server. View state is empty when the first page requested at the beginning of the session. By default, the attempt state is saved in a hidden field, and the hidden field is automatically added to the page. The name of this hidden field is __viewstate. If you override the LoadViewState method--a method that is declared protected in the control class--the component developer controls how the view state is saved and how it maps to the internal state.
Methods such as Loadpagestateformpersistencemedium and their corresponding Savepagestatetopersistencemedium methods can be used to load or save view state to other storage intermediaries, for example: Session , a database, or a file on a server. As with the LoadViewState method, the method mentioned above can only be used in the page's inheriting class.
Once the view state has been loaded, the control on the page is given the same state as the last time it was sent to the browser. The next stage is to update them to match the changes that occur on the server side. In the postback data processing phase, the controls update their state to match the state of the client's HTML elements. For example, the server control textbox has an HTML control <input type=text> that corresponds to it. In the postback data phase, the TextBox control gets the value of the <input> tag and uses him to update his internal state. Each control can get its own data from the postback data and update its status. The TextBox control will update its Text property, and the CheckBox control will also refresh their checked properties. The matching of server controls and HTML elements is done by the ID of both.
In the final phase of the postback data processing, all page controls reflect the last updated state, which is caused by changes in the input from the client. Next, the Load event is executed by the page.
There are controls that, in two requests, need to respond to certain sensitive properties and perform certain tasks. For example, if the text of a client's TextBox control changes, the control fires the TextChanged event. Depending on the data from the client, if one or more of the control's properties have changed, each control can accurately fire the appropriate event to handle. These controls implement the IPostBackDataHandler interface, and the LoadPostData method in this interface is executed after the Load event. By redefining the LoadPostData method, the control can verify the changes that occurred in two requests and provoke the associated event handlers.
Key events in a page cycle are those that are triggered by a client event to execute a piece of code on the server. For example, when a user clicks on a button, the page needs to be returned. The processing of this event starts with the collection of button IDs and values. If the control is implementing the IPostBackEventHandler interface (as is the case with button and LinkButton), the page schema will invoke the RaisePostBackEvent method. The specifics of this method depend on the type of control. In the button and LinkButton control mentioned above, this method will look for the Click event handler.
Once the postback event is processed, the page is ready to be sent out. This phase begins with the PreRender event. This is a good time for controls to perform actions that need to be performed before the view information is saved and the result is sent. The next step is SaveViewState, where all the space and the page itself save the contents of the view state's collection. Next, the view state is serialized, hashed, BASE64 encoded, and stored in the __viewstate hidden domain.
The sending mechanism of individual controls can be changed by redefining the Render method. This method constructs an HTML writer object that is used to generate 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 invokes the Render method once for each control and buffers the HTML output.
The final stage of the page life cycle is the uninstall event, which is fired before the page object disappears. In this event, you should release any critical resources (e.g. files, graphics objects, database connections).
Finally, the browser receives the HTTP response and displays the page.
Summarize
Asp. NET Page object model is a new and characteristic model because it is based on the event mechanism. A Web page consists of controls that have a rich html-based user interface and interact with the user through events. Building an event model in a Web application context environment is challenging. It is amazing to associate the events generated by the client with the code on the server, and the process is that output is as visible as HTML, except that they are appropriately modified when needed.
Mastering this model is important to understand the stages of the page lifecycle, how the page objects are instantiated, and are used by the HTTP runtime.
