asp. net page lifecycle details

Asp.net is an integral part of Microsoft's Net strategy. It is a significant development from the previous Asp, with many new mechanisms introduced. This article gives you a preliminary introduction to the life cycle of Asp.net pages in order to guide you to operate Asp.net better and more flexibly. When a request for a web page, either submitted by the user or hyperlinked, is sent to the Web server, the page then runs a series of events from creation to processing. When we were trying to build the Asp.net page, we didn't have to worry about the execution cycle, because that would have been a recipe for disaster. However, if manipulated correctly, the one-page execution cycle can be an effective and powerful tool. Many developers who write Asp.net pages and user controls find that knowing what is happening and when is an important help in completing the task. Let me show you 10 events from the creation to the completion of the next Asp.net page. It also shows you how to add your own code to these events to achieve the desired effect.

1. Initializing object
The 1 page control (and the page itself) should initially be initialized correctly. By naming all objects in the constructor of your C# file (Figure 1), the page knows how many objects to create and what type they are. Once you name all objects in your constructor, you can access them by inheriting classes, methods, events, or properties. However, if your objects are the controls specified in the Aspx file, then the controls have no properties to speak of. At the same time, accessing them through code will cause 1 unexpected error, because these control instances are not created in a certain order (if they were created at 1). Also, you can override initialization events via OnInit.

2. Import the Viewstate data
After initializing the event, all controls can only be accessed by reference through their ID (because there is no corresponding DOM available yet). In the event LoadViewState, all controls get their first property: Viewstate. 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 that contain information such as the text of the control and its value. This property is stored in 1 hidden < input > Control, which is passed when the page is requested. This is a big improvement over es34EN3.0, which maintains and determines the state of the page. Also, you can override the LoadViewState event function to set the value of the corresponding control.

3. Use LoadPostData to process Postback data
At this stage of page creation, the server processes form data submitted by controls on the page (Asp.net, postback). When a form is submitted on a page, the framework performs an IPostBackDataHandler interface operation on each control that submits data. The page then performs the LoadPostData event, parses the page, finds each control that performs the IpostBackDataHandler interface operation, and updates the state of those controls with the appropriate postback data. Asp.net achieves this by matching the name/value pair in the NameValue set with the only ID match for each control. Therefore, on the page of ES52en.net, each control must have 1 unique ID. It is not possible for several controls to have a total of ID. Even for user-defined controls, the framework gives them their own version of ID. After the LoadPostData event, the following RaisePostDataChanged event is executed.

4. Import the object
In the Load event, objects are instantiated. For the first time, all objects are placed on the DOM page (called the control tree in ES64en.net) and can be referenced through code or related locations. In this way, the object can easily obtain property values such as width, height, value, visibility, and so on in Html from the client. In the Load event, of course, actions such as setting control properties occur. This process is the most important and important in the entire life cycle, you can override Load events by calling OnLoad,

5. RaisePostBackChanged event
As mentioned above, this event occurs after all the controls have performed the IPostBackDataHandler interface operation and have been updated with the correct postback data. During this process, each control is assigned a Boolean value to indicate whether the control has been updated. Asp.net then looks across the page for any controls that have been updated and performs the RaisePostDataChanged event operation. However, this event does not occur until all the controls have been updated and the Load event is complete. This ensures that one control will not be changed manually in the RaisePostDataChanged event until it is updated by postback data.

6. Handle client PostBack events
When the events caused by the postback data on the server are complete, the object that generated the postback data performs the RaisePostBackEvent event operation. However, there may be a situation where a change in the state of a control causes it to return 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 corresponding processing code to reflect the event-driven 1 object oriented (OOP) programming principles. The RaisePostBackEvent event is the last in the postback series 1 to occur due to the accuracy of the data presented to the browser.
Controls that change during postback should not be updated after the execution function is called. That is, any data that changes due to an expected event should be reflected on the final page. You can do this by modifying the RaisePostBackEvent function,

7. Prepresent the object
The last time you can change an object and save the change is in this step to pre-present the object. In this way, you can make final changes to the control's properties, tree structure, and so on in step 1. You also don't have to worry about Asp.net making any changes to it, because at this point the database call is gone and the viewstate update is gone. After this step, all changes to the object are finally determined and cannot be saved to viewstate on the page. You can reload this step via OnPreRender.

8. Save ViewState
viewstate is saved after all the changes to the page controls have been made. The state data for the image remains hidden < input > Control, where the object state data is rendered to Html. In the SaveViewState event, the value can be saved to the viewstate object, whereas changes to controls on the page cannot. You can reload this step with SaveViewState

9. Handed over Html
The Render event occurs when you use Html to create a page that outputs to the browser. During the Render event, the page calls its objects and presents them to Html. The page can then be accessed by the user's browser as Html. When the Render event is reloaded, the developer can write custom Html code that invalidates the previously generated Html and organizes the page according to the new Html. The Render method takes an HtmlTextWriter object as a parameter and USES it to display Html in the browser as a web page. You can still make a few changes, but they are just changes to the client. You can override the Render event

10. Destruction of objects
After the presentation to Html is complete, all objects should be destroyed. In the Dispose event, you should destroy all the objects that were created when the page was created. At this point, all processing is complete, so destroying any remaining objects, including page objects, will not produce an error. You can override the Dispose event

The full text summary
These are the 10 events in the ES141en.net page life cycle. Every time we request an ES143en.net page, we go through the same process: from initializing the object to destroying it. By understanding the inner workings of Asp.net, I believe you will be more comfortable writing and debugging code.