Using Web Forms
- Understanding How Web Forms Are Processed
- Performing Basic State Management in Web Applications
- Using Cookies
- Using Hidden Fields and Query Strings
- Working with the Session Object
- Working with the Application Object
- Setting Up Global Objects with the global.asax File
- Configuring the Application
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Yesterday's lesson introduced ASP.NET programming. You saw how to implement a basic ASP.NET page using a simple Web form and how to use code behind with Web forms. Today's lesson will introduce more techniques that you can use with Web forms, including basic state management and some details about the life cycle of Web forms. Today you will learn about the following:
- The way Web forms are processed
- An introduction to Web form state management
- The Session and Application objects
- The way global objects are stored
Understanding How Web Forms Are Processed
As we discussed yesterday, a Web form is another name for an ASP.NET page. You learned yesterday that a Web form can be made up of a single file with an .aspx extension. You also saw how an .aspx file and a code behind file can be combined to make a Web form. As we'll show in the following few days, Web forms can also contain your own custom controls, defined similarly to .aspx pages, called user controls.
Because a Web form can include HTML, ASP.NET Web controls, custom (user) controls, and code behind, creating them can get complicated pretty quickly. However, you need to remember only a few key ideas about ASP.NET page processing so that you can develop and debug effectively.
The first key idea is that much of the ASP.NET infrastructure is set up so that a single ASP.NET page can post form data back to itself repeatedly. You saw this "postback" technique in yesterday's examples with the Login page. This technique is most useful when you divide your Web site's functionality into a few main pages. We'll explore this kind of design in the first bonus programming project in this book, after Day 12.
The second key idea to remember is that all ASP.NET pages are eventually compiled into executable files by the ASP.NET infrastructure. This means that every time a page is processed and rendered, a small program corresponding to each Web form is executed by the ASP.NET infrastructure.
Let's explore in more detail how Web forms are processed. Listing 3.1 shows a sample Web form that performs an English unit to metric unit conversion, and Figure 3.1 shows the resulting page.
){kind=link}
Figure 3.1 The English unit to metric unit conversion page.
Listing 3.1 EnglishToMetric.aspx: Converting Feet and Inches to Meters
1: <%@ Page Language="VB" %> 2: <html> 3: <body> 4: <form runat="server"> 5: <h2>English to Metric conversion</h2> 6: <h3>Please enter your height, and then click the Convert button</h3> 7: <asp:Textbox id="Feet" runat="server"/>Feet 8: <br> 9: <asp:Textbox id="Inches" runat="server"/>Inches 10: <br> 11: <asp:Button OnClick="OnConvert" Text="Convert" runat="server"/> 12: <br> 13: <br> 14: <asp:Label id="lblMeters" runat="server"/> 15: </form> 16: </body> 17: </html> 18: 19: <script runat="server"> 20: Sub Page_Load(Sender As object, e As EventArgs) 21: 22: If IsPostBack Then 23: If Feet.Text = "" Then Feet.Text = "0" 24: If Inches.Text = "" Then Inches.Text = "0", 25: End If 26: End Sub 27: 28: Sub OnConvert(Sender as Object, e As EventArgs) 29: 30: Dim fFeet As Single = Single.Parse(Feet.Text) 31: Dim fInches as Single = Single.Parse(Inches.Text) 32: Dim fMeters As Double = 0.305*fFeet + 0.0254*fInches 33: lblMeters.Text = "<b>You are " & fMeters.ToString() & " meters tall</b>" 34: 35: End Sub 36: </script>
ANALYSIS Let's examine how Web forms work using Listing 3.1 as our reference. Web forms like Listing 3.1 are processed in two different ways:
-
A Web form is rendered when the user initially browses to the .aspx file. In this case, the Web form doesn't process any events because there has been no user interaction.
-
A Web form may be processed after the user interacts with one of the page controls. For instance, the user might click a button on the page or select an item from a drop-down list. When the user does so, the same Web form gets hit by the user's browser, this time with information about what the user has done.
Through both cases, a Web form goes through five distinct stages when it's rendered, as shown in Figure 3.2.
){kind=link}
Figure 3.2 Web forms processing stages.
In Figure 3.2, the first stage deals with Web control initialization. We'll learn more details about how controls save and then remember their state in tomorrow's lesson. You don't need to be too concerned about this stage in your own programming tasks.
Your code is frequently involved in the second stage of Web forms processing, when the ASP.NET infrastructure fires the Load event in the Page class. As Listing 3.1 shows, you can use the Page_Load event (Lines 20-26) to change the contents of controls or to perform any other kinds of processing before a page is rendered. If the page posts back to itself (that is, if the user clicks the Convert button), the Page_Load event will fill in zeros if the user leaves any field blank (Lines 22-25).
The third stage of Web forms processing is for control event handling, which happens only if the user manipulates one of the Web controls on the page. This stage won't happen if this is the first time the user is browsing to this particular page. In Listing 3.1, the OnConvert method is called during this stage (Lines 28-35). Note that event handling happens after the Page_Load event. You will learn about more complex Web controls that contain many events on Day 5, "Using Advanced ASP.NET Web Controls."
In the fourth stage, the HTML for the page is rendered. This process involves calling the Render method for the page, which will call the Render method for every control, among other things.
NOTE
Listing 3.1 doesn't contain an explicit Render method, because the page class and Web control classes have default implementations for it already. You will need to override the Render method only if you want to customize the exact HTML that each class produces.
In the last stage, , the Page_Unload event gets called. You can use the Unload event to clean up database connections and other objects that have to be closed explicitly, for example. (Listing 3.1 also doesn't define the Page_Unload event, because it doesn't need to clean up any objects.)