How Web Forms Work

王朝asp·作者佚名  2006-01-10
窄屏简体版  字體: |||超大  

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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航