Web Form Processing

Server-side web form processing ASP.NET this happens in stages. Different events are generated at each stage. This allows the page to join the processing flow at any stage and return a response in any convenient way. The following list lists the main steps of the page processing flow ASP.NET:

  • Initializing the page structure
  • Initializing the user code
  • Verification of validity
  • Event Handling
  • Automatic data binding
  • Clearing

In the next few sections, each step will be considered separately, and then an example of a simple web page will be presented.

Initializing the page structure

At this stage, ASP.NET creates a page. All controls defined in handles inside the .aspx web page are generated. Moreover, if the page is not requested for the first time (in other words, if it is a return request), ASP.NET deserializes information about the view state and applies it to all controls.

At this stage, the Page event is triggered.Init. However, this event is rarely handled by the web page, because it is still too early to perform page initialization. This is because the control objects haven’t been created yet, and the view state information hasn’t been loaded yet.

Initializing the user code

At this stage, the Page event is triggered.Load. Most web pages process this event to perform any necessary initialization, such as filling in dynamic text fields or configuring controls.

The Page event.Load is always triggered, regardless of whether the page is being requested for the first time or as part of a postback. Fortunately, ASP.NET allows programmers to distinguish between the events of the first page load and all subsequent loads.

Why is this important? First, because the view state is maintained automatically, you only need to extract your data from the dynamic data source when the page is loaded for the first time. During the return message, you can enable ASP.NET restore the properties of controls from the view state yourself. This can significantly increase performance if the information is sufficiently “expensive” to recover (for example, if it needs to be queried from a database).

Second, there are also other scenarios, such as editing forms and drill-down pages, where you need to display one interface when you first use the page and another interface when you load it later.

You can determine the current state of a page by checking its IsPostBackproperty, which will be set to false when the page is first requested, for example:

if (!Page.IsPostBack) 
{ 
    // Initialize controls the first time
    // handling is quite safe.
   FirstName.Text = "Enter your name here"; 
} 

Keep in mind that each modified property is saved in the view state. Initializing the control in the Page event.Load is considered a change, so any control value you touch will be saved in the view state, which unnecessarily increases the page size and slows down the data transfer time. To speed up the preparation of the view state and minimize page sizes, avoid initializing controls in code.

On the contrary, set properties in the control handle (manually or in the Properties window). As a result, this information will not be stored in the view state. In cases where it is really easier to initialize a control in code, disable the view state for the control by setting EnableViewState to false and initializing the control each time the Page event is triggered.Load regardless of whether the current request is a return request.

Verification of validity

Part of the ASP.NET includes special controls that can automatically check other controls that accept user input and display error messages. These controls come into play after the page loads, but before any other event occurs. However, they are mostly self-contained, which means that you don’t need to respond to the validation events they generate. Instead, you can use another event handler to check whether the entire page is valid (using the Page property.IsValid).

Event Handling

At this stage, the page is already fully loaded and verified. Therefore, ASP.NET fires all events that have occurred since the last time data was sent back. Overall events ASP.NET there are two types::

  • Events that require an immediate response. These events include a click on the Submit button or some other button, image area, or link in a multi-function web control that initiates sending data back by calling the __doPostBack () JavaScript function.
  • Change events. These events include changing the selection in the control or the text in the text field. These events are triggered for web controls immediately if the AutoPostBack property is set to true. Otherwise, they are triggered the next time the page is sent back.

As you can see, the event model is ASP.NET quite different from the traditional Windows environment. In the case of a Windows application, the form state is stored in memory, and the application runs continuously. This means that you can respond to any event immediately. In ASP.NET everything happens in stages and because of this, it happens that events sometimes accumulate and are combined in batches.

For example, let’s assume that there is a page with a Submit button and a text field that does not automatically send data back. You change the text in the text box and click Submit. After that ASP.NET fires all of the following events (in this order)::

  1. Page.Init
  2. Page.Load
  3. TextBox.TextChanged
  4. Button.Click
  5. Page.PreRender
  6. Page.Unload

Remembering this information can make your life much easier. The event-driven model has both positive and negative aspects.

The positive side is that the event model provides a higher level of abstraction, which eliminates the stereotypical fragments of state support from the code. On the negative side, it’s very easy to forget that the event model is really just an emulation. This can lead to an incorrect assumption (for example, the expectation that information remains in instance variables) or an unsuccessful design decision (for example, storing a large amount of information in the view state).

Clearing

At the end of its life cycle, the page is converted to HTML markup. After that, the real cleanup starts and the Page event is triggered.Unload. At this point, the page objects are still available, but the final HTML markup has already been generated and cannot be changed.

Remember that y .The NET Framework has a garbage collection service that runs periodically to free up memory occupied by objects that are no longer referenced. Unmanaged resources should be released explicitly during the cleanup phase or, better yet, before it. When the garbage collector destroys a page, the Page event is triggered.Disposed. This completes the life cycle of the web page.

Example of a page processing flow

No matter how many times other people explain how a particular thing works, it’s always more fun to see it with your own eyes. So that you can satisfy your curiosity, we suggest you try out a test web form that will allow you to see what the processing flow looks like:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="PageFlow.aspx.cs" Inherits="WebApplication1.PageFlow" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Page Flow</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:Label ID="lblInfo" runat="server" EnableViewState="false"></asp:Label>
        <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click"/>
    </div>
    </form>
</body>
</html>

Next, you need to add event handlers. When completed, the separated code file will contain five event handlers that respond to various events, including Page.Init, Page.Load, Page.PreRender, Page.Unload и Button.Click.

Page event handlers are a special case. Unlike event handlers for other controls, they do not need to be specifically attached using markup attributes, because if they specify the correct method name (and assuming that the Page directive for AutoEventWireup is set to true by default), they are attached automatically:

        protected void Page_Load(object sender, EventArgs e)
        {
            lblInfo.Text += "Page.Load Event fired<br/>";
            if (Page.IsPostBack)
                lblInfo.Text += "<b>Page not loaded for the first time.</b><br/>";
        }

        protected void Page_Init(object sender, EventArgs e)
        {
            lblInfo.Text += "Page.Init<br/>";
        }

        protected void Page_PreRender(object sender, EventArgs e)
        {
            lblInfo.Text += "Page.PreRender Event fired<br/>";
        }

        protected void Page_Unload(object sender, EventArgs e)
        {
             // This text is never displayed because this
             // All the HTML code for the page has already been generated. 
            lblInfo.Text += "Page.Unload Event fired<br/>";
        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            lblInfo.Text += "Button.Click Event fired<br/>";
        }

Page handlers are enabled explicitly using delegates in a hidden part of the constructor code. Since this constructor code is still considered part of your class (thanks to the” magic ” mechanism of partial classes), it can connect any method, including a private one. Event handlers for controls are attached using a different mechanism — the control handle. And this happens at a later stage of processing, or rather, after combining the information contained in the file .aspx markup and separated code class. ASP.NET performs this union by creating a new class derived from the separated code class.

Leave a Reply

Your email address will not be published.

You May Also Like
Read More

App Model ASP.NET

Difference between applications ASP.NET and feature-rich client applications, which makes a lot of sense when analyzing the execution…