1.3 System.Web.UI.Page | Essential ASP.NET With Examples in C#

Now that you understand that every page is compiled into a class definition, the next step is to understand exactly how that class is created and what control you have over its creation. As a first experiment, because we know that our page is turned into a class, we can display the type of our page and the class from which it inherits. Figure 1-2 shows a sample .aspx file, along with its output, that prints out the type of the page and its base class, using the GetType() method and the BaseType property. ^[4]

^[4] In this example, note the use of the Output property of the Response object. This is an instance of the TextWriter class, which writes to the response buffer. This class is convenient to use when you need to construct strings, because it supports the formatting of strings, which is more efficient than string concatenation.

Figure 1-2. ASP.NET Page Type

graphics/01fig02.gif

Notice that the type of the page is ASP.ShowPageType_aspx , which is simply the name of the file with the "." replaced by an "_" character. More interestingly, the base class is System.Web.UI.Page , which defines most of the functionality for processing requests in ASP.NET. By default, every .aspx page you author derives from the Page base class. As with any other class hierarchy, it is important to understand the features and functionality of the class from which you inherit. Listing 1-3 shows some of the most interesting members of the Page class.

Listing 1-3 Important Members of System.Web.UI.Page

 public class Page : TemplateControl, IHttpHandler {         // State management     public HttpApplicationState Application {get;}     public virtual HttpSessionState Session { get;}     public Cache Cache {get;}         // Intrinsics     public HttpRequest Request {get;}     public HttpResponse Response {get;}     public HttpServerUtility Server {get;}     public string MapPath(string virtualPath);         // Client information     public ClientTarget ClientTarget {get; set;}     public IPrincipal User {get;}     // Core     public UserControl LoadControl(string virtualPath);     public virtual ControlCollection Controls {get;}     public override string ID { get; set;}     public bool IsPostBack {get;}     protected void               RenderControl(HtmlTextWriter writer);     //... }

The Page class provides facilities for state management, including the familiar Application and Session state objects plus a new Cache object, the details of which are discussed in Chapter 9. All the familiar intrinsics ASP programmers are used to can be found exposed as properties in the Page class, including the Response , Request , and Server objects. This means that the familiar ASP-style syntax of accessing something like the Response object will compile because it maps onto a property of the class from which your page inherits. The details of the new classes that replace the ASP intrinsics are discussed later in this chapter.

Once you are aware that your pages are turned into classes, you can start taking advantage of this fact by adding features to your page as you might add features to a class. For example, consider the page shown in Listing 1-4.

Listing 1-4 Sample ASP.NET Page with Data Members

 <! SamplePage.aspx > <%@ Page Language="C#" %> <html><body> <script language="C#" runat=server>   private ArrayList _values = new ArrayList();   private void PopulateArray()   {       _values.Add("v1");       _values.Add("v2");       _values.Add("v3");       _values.Add("v4");   } </script> <h2>aspx==class!</h2> <ul> <%   PopulateArray();   for (int i=0; i<_values.Count; i++)     Response.Output.Write("<li>{0}</li>", _values[i]); %> </ul> </body> </html>

Because our page is now within a class definition, we can do things such as specifying the protection level of fields and methods , using field initializers, and pretty much anything else you might add to a class definition. In Listing 1-4, we defined a private field called _values of type ArrayList , initialized it to a newly allocated instance, and built a method called PopulateArray() to fill the field with values. Then in the body of our page we were able to invoke the PopulateArray() method and access the contents of the private _values field within a server-side script block. Notice that in this example, all the field and method declarations were placed in a server-side script block, while invocations of methods and access to fields were placed within server-side script tags ( <% %> ). This is important because code placed in each of these two places will be placed in the generated class definition in very different places. Code that falls within a server-side script block ( <script runat=server></script> ) will be placed directly into the class definition. Code that falls within server-side script tags ( <% %> ) will be placed into the body of a function of the class that will be called when the page is rendered. Figure 1-3 shows the relationship between these two server-side code notations and their placement in the generated class definition.

Figure 1-3. Server-Side Code Placement in Page Compilation

graphics/01fig03.gif

It is important to note this server-side code placement distinction, especially if you are migrating existing ASP pages to ASP.NET. It is no longer possible to include executable code outside the scope of a function within a script block marked as runat=server , and conversely, it is no longer possible to define a function within a pair of server-side script tags. Note also that the generated class definition provides a default constructor for you, and if you try to define your own default constructor within your page, it will cause a compiler error. This can be somewhat frustrating if you are trying to properly initialize elements of your class (such as filling up our array of values or subscribing to events). Fortunately, an alternative technique gives you more complete control over the class definition while separating the layout from the page logic. This technique is called code-behind.