How Web Forms Work

How Web Forms Work
Just as you'll find when working with Windows Forms, ASP.NET Web Forms raise
events in a certain order as the page initializes and loads. ASP.NET also
raises events in response to user interaction in the browser. When you
think about how a standard ASP or HTML page is created and sent to a
browser, you assume that everything is processed in a very linear, top-down
fashion. However, for a Web Form, nothing could be further from the truth.

Like a Windows Form, a Web Form goes through the standard Load, Draw
(Render), and Unload types of events. Throughout this process, different
procedures within the page's class module are called. When a page is
requested from a client browser, a DLL that encapsulates the tags in the
ASPX page as well as the page code is loaded and then processed.

First, the Init event occurs as ASP.NET sets the page to its initial state,
as described by the tags in the ASPX file. If the page is posting back to
itself, Init also restores any page state that may have been stored by the
page previously.

Next, ASP.NET raises the Load event as the page is loaded. In the event
handler for this event, you can use the Page.IsPostback property to
determine whether the page has posted back to itself. This might happen
because a user has clicked a button or is interacting with some other
control that caused a postback to the page. You might perform some
initialization only on the first page load梖or example, you might bind data
into the controls. (You're far more likely to trigger a postback with
ASP.NET pages than you are when creating ASP applications. Because ASP.NET
makes it so simple to have just about any control passed back to the page
and to run event code before the page renders again, you'll find that you
end up running code in the Page_Load procedure quite often. Checking the
Page.IsPostback property will allow you to only run code the first time the
page is loaded, if that makes sense.)

Next, if the page is being posted back, ASP.NET raises control events. (If
the page isn't being posted back梩hat is, being loaded for the first time梕ve
nt procedures won't run. There's obviously no event that requires handling
yet.) First, all the "change" events are fired. These events are batched up
in the browser and executed only when the page is sent back to the server.
These "change" events include changing the text in a text box and selecting
an item in a ListBox or DropDownList control.

TIP

Event procedures only run when you post back to a page. Postback happens
immediately, and automatically, when you click a button. You may want to
have postback occur automatically when you select an item from a list or
when you check a check box. Doing this in ASP requires you to write
client-side script. In ASP.NET, it's as simple as setting a control's
AutoPostBack property to True. When you do that, ASP.NET inserts the
appropriate client-side script for you, so clicking the check box or
selecting an item from a list triggers a postback, and the page can run the
associated event code immediately.



TIP

You cannot control the order in which the "change" events fire on the
server. You are guaranteed only that they will all fire.



Next, and only if the page is posted back, the control event that caused
the page to post back is fired. Examples of postback events include a
button's Click event or controls for which you've set the AutoPostBack
property to True, like a check box's CheckedChanged event.

Next, the page is rendered to the browser. Some state information (the
page's view state) is included in a hidden field in the page so that when
the page is called again through a postback, ASP.NET can restore the page
to its previous state. (You'll learn more about view state and managing
state in Chapter 23, "State Management in ASP.NET.")

There is a final page event your code can handle before the page is
disposed: the Unload event. Because the page is already rendered, this
event is typically used to perform cleanup and logging tasks only. Finally,
the class that represents the running page is removed from memory, and the
page is unloaded from memory as well.

If you change the ASPX page or its code, the dynamically generated DLL that
represents the page will be regenerated the next time the page is
requested. This DLL is stored to disk each time it is generated.