Some of the stages listed above are not visible at the page level and are meaningful only to the creator of the server control and to the developers who want to create the class derived from page. Init, Load, PreRender, Unload, plus all postback events defined by the embedded control, form the various stages of the outgoing page.
Various stages of implementation
The first stage in the page life cycle is initialization. The flag for this phase is the Init event. This event is triggered on the application after the page's control tree is successfully created. In other words, when the Init event occurs, all of the controls statically declared in the. aspx source file are instantiated and their default values are taken. Control can intercept the Init event to initialize all the settings that are required in the life cycle of the incoming WEB request. For example, the control can load an external template file or set up handlers for the event. Note that the view state information is not yet available.
After initialization, the page frame loads the view state of the page. View state is a collection of name/value pairs in which the control and the page itself store all the information that must always be valid for all WEB requests. View state represents the calling context of the page. Typically, it contains the state of the control when the page was last processed on the server. The first time a page is requested in a session, the view state is empty. By default, view state is stored in a hidden field that is silently added to the page, and the name of the field is __viewstate. By overriding the LoadViewState method (the protected, overridden method of the control class), the component developer controls how view state is stored and how the contents of the view state are mapped to the internal state.
Some methods, such as LoadPageStateFromPersistenceMedium and their corresponding savepagestatetopersistencemedium, can be used to load and save view state to other storage media such as sessions, Database or server-side files). Unlike LoadViewState, the above methods can only be used in classes that are exported from the Page.
After the view state is stored, the state of the control in the page tree is the same as the last time the page was displayed in the browser. The next step is to update their status to join the client's changes. Processing the postback data phase gives the control an opportunity to update its state, which accurately reflects the state of the corresponding HTML element for the client. For example, the HTML element corresponding to the server's TextBox control is <input type=text>. In the postback data phase, the TextBox control retrieves the current value of the <input> tag and uses that value to refresh its internal state. Each control extracts the value from the postback data and updates its own partial properties. The TextBox control will update its Text property, and the CheckBox control will refresh its Checked property. The corresponding relationship between the server control and the HTML element can be found by the ID of the two.
At the end of processing the postback data phase, the state of all controls on the page will update the previous state with changes that are entered by the client. At this point, the Load event is triggered on the page.
There may be controls on the page that require specific tasks to be completed when one of its sensitive properties is modified in two different requests. For example, if the text of a TextBox control is modified at the client, the control triggers the TextChanged event. Each control can decide to trigger the appropriate event when one or more of its properties are modified to a value entered by the client. For controls that are critical to these changes, the control implements the IPostBackDataHandler interface, which is called immediately after the Load event LoadPostData. By encoding the LoadPostData method, the control verifies that a critical change has occurred since the last request and triggers its own change event.
The key event in the page lifecycle is the event that is called to execute the server-side code, which is associated with the event that is triggered by the client. When the user clicks the button, the page is sent back. The collection of postback values includes the ID of the button that started the entire operation. If the control implements IPostBackEventHandler interfaces (such as buttons and link buttons), the page frame calls the RaisePostBackEvent method. The behavior of this method depends on the type of control. In the case of buttons and link buttons, this method finds the Click event handler and runs the associated delegate.
After the postback event has been processed, the page can be displayed. The sign of this phase is the PreRender event. The control can take advantage of this time to perform the update operations that need to be performed at the first minute of saving view state and displaying the output. The next state is SaveViewState, in which all controls and the page itself update the contents of their ViewState collection. Then, you get a serialized, hashed, BASE64-encoded view state, and this view state is associated with the hidden field __viewstate.
You can change the display mechanism of individual controls by overriding the Render method. This method accepts the HTML writer object and uses this object to accumulate all the HTML text that is generated for the control. The default implementation of the Render method for the Page class includes recursive calls to all member controls. For each control, the page calls the Render method and caches the HTML output.
The last flag in the life of a page is the Unload event, which occurs before the Page object is eliminated. In this event, you should release all the critical resources that might be in use (such as files, drawing objects, database connections, and so on).
After this event, that is, finally, the browser receives the HTTP response packet and displays the page.
asp.net Web life cycle
ASP.net has a great development relative to the previous ASP. Many new mechanisms are cited. This article is a preliminary introduction to a asp.net Web lifecycle.
When a request to get a Web page (possibly through a user submission, or through a user-clicked link) is submitted to the server. The Web page then starts running a series of events from creation to processing. As we build the ASP.net page, We don't have to think about this process. However, if properly manipulated, a page's execution cycle would be an effective and powerful tool. Many developers, when writing asp.net pages and user controls, find that knowing what's going on in the process and when it happens will play an important role in helping complete the task. Now let me introduce you to a asp.net page. 10 events from creation to process completion. Also, show you how to add your own code to these events to achieve a predetermined effect.
First, initialize the object
A page's controls (and the page itself) should initially be properly initialized. By making a list of all the objects in your C # file's constructor, the page knows how many objects to create and their types. Once you have a reputation for all the objects in your constructor, you can access them by inheriting classes, methods, events, or attributes. However, if some of your objects are some of the controls specified in the ASPX file, then the controls have no properties to speak of. Also, accessing them through code can cause some unexpected errors because these control instances are not in a certain order of creation (if they were created together). Also, you can overload initialization events by OnInit.
second, import viewstate data
After the event is initialized, all controls can be accessed only through their IDs (since no corresponding DOM is available). In LoadViewState this event, all controls will get their first property: the ViewState property. This property will eventually be returned to the server to determine whether the page has been accessed by the user or is still being accessed by the user. The ViewState property is saved as a string of "name/value" pairs, which contains information such as the control's text and values. This property is stored in the Value property of a hidden <input type= "hidden"/> Control and is passed when the page is requested. You can also overload the LoadViewState event function to set values for the corresponding control. Figure:
Joint single
third, the use of loadpostdata processing postback data
At this stage of the page creation, the server handles the form data that is submitted by the control on the page (called postback data in asp.net). When a page submits a form, the framework performs a IPostBackDataHandler interface operation on each control that submits the data. The page then executes the LoadPostData event, parses the page, finds each control that performs the IPostBackDataHandler interface operation, and updates the control state with the appropriate postback data. asp.net is done by matching the name/value pair in the Namevalue set with the unique ID of each control. Therefore, each control must have a unique ID on the asp.net page, and there can be no instances where several controls have a common ID. Even for user-defined controls, the framework gives them unique IDs. After the LoadPostData event, the following Raisepostdatachanged event will be executed.
Iv. Importing objects
In the Load event, the object is instantiated. All objects are first laid out in the DOM page (called the Control tree in asp.net) and can be referenced by code or relative location. This allows an object to easily obtain property values such as width, height, value, visibility, and so on in HTML from the client. In the Load event, there is, of course, the occurrence of actions such as setting control properties. This process is the most important and major part of the entire lifecycle, and you can overload the load event by calling OnLoad. As shown in figure:
v. raisepostbackchanged events
As mentioned above, this event occurs after all controls perform the IPostBackDataHandler interface operation and are updated with the correct postback data. In this process, each control is given a Boolean value to flag that the control has not been updated. ASP.net then searches the entire page for any controls that have been updated and performs raisepostdatachanged event operations. However, this event occurs only after all controls have been updated and the Load event is complete. This ensures that a control is not manually changed in the Raisepostdatachanged event until it is updated by the postback data.
vi. Handling Client Postback events
When the event caused by the postback data on the server is complete, the object that produces the postback data performs the RaisePostBackEvent event operation. However, this can happen because a control state changes so that it returns the form to the server or the user clicks the Submit button to return the form to the server. In this case, there should be a corresponding processing code to reflect the event-driven object-oriented (OOP) programming principle. Due to the accuracy requirements of the data presented to the browser, the RaisePostBackEvent event is the last occurrence in a series of postback events. Controls that are changed during the postback process should not be updated after the function function is invoked. That is, any data that changes as a result of an expected event should be reflected on the final page. You can modify the RaisePostBackEvent function to meet your requirements.
VII. Pre-submitted objects
The last moment that can change the object and save the change is this step--presenting the object in advance. In this way, you can make a final change to the control's properties, control tree structure, and so on. At the same time, there is no need to consider asp.net to make any changes, because at this time has been separated from the database calls and ViewState update. After this step, all modifications to the object will eventually be determined and cannot be saved to the ViewState of the page. You can overload this step by OnPreRender.
viii. Preservation of ViewState
ViewState is saved after all modifications to the page control have been completed. The state data for the image remains in the hidden <input type= "hidden"/> Control, where the object state data presented to the HTML is also obtained. In the SaveViewState event, the value can be saved to the ViewState object, but the changes on the controls on the page are not available. You can use SaveViewState to overload this step. Figure:
ix. presenting to HTML
The render event occurs when you use HTML to create a page that is output to a browser. During the render event, the page calls the objects in which they are presented to the HTML. The page can then be accessed by the user's browser in HTML form. When the render event is overloaded, the developer can write custom HTML code to invalidate the previously generated HTML and organize the page according to the new HTML. The Render method takes a HtmlTextWriter object as a parameter and uses it to display HTML as a Web page on the browser. You can still do some modifications, but they are just a few changes to the client. You can overload the render event. Figure:
10, destroy the object
After presentation to HTML, all objects should be destroyed. In the Dispose event, you should destroy all objects created when the page was built. At this point, all the processing is complete, so destroying any remaining objects will not produce errors, including page objects. You can overload the Dispose event.
Full Text summary:
These are the 10 events in the life cycle of the ASP.net page. Every time we ask for a asp.net page, we all go through the same process: from initializing the object to destroying the object. By understanding the internal operating mechanism of the ASP.net page
