ASP.NET Page Class
|
ASP.NET pages begin as code in a text file with an .aspx extension. They lie within an Internet Information Service (IIS) virtual directory located somewhere on your LAN or on a remote server. Pages are instantiation classes derived from the parent Page class. For example, you can write your code using any text editor such as Notepad or, preferably, Visual Studio .NET. The text file becomes a valid ASP.NET page only when a client sends a request to the server to render the page to the client browser. The page compiles to a class. It is created at runtime as a Page object and is subsequently cached in memory. It naturally follows that the Page object serves as a naming container for all server controls embedded within the page. The only exception to this is those server controls implementing the INamingContainer interface.
Examining the Page Class
ASP.NET functionality lies primarily with the Page class. Every page derives from the Page class, thereby inheriting all the methods and properties the Page class exposes. The following list describes several members of this class.
-
The ASP objects such as Application, Session, Request, Response, Server, and Context are implemented in ASP.NET as class instances, which are exposed as properties of a specified page.
-
The Controls collection provides access to the set of controls defined for a specific page. With this collection, you can add or alter controls.
-
The IsPostBack property is used to determine whether the current request is a GET request or a POST request.
-
The User property provides information about the logged-in user.
-
The Cache property enables access to the ASP.NET cache engine. You can use this property to allow data to be cached for later retrieval.
-
The FindControl property allows you to locate a control in the Controls collection by specifying the ID attribute property.
-
The ViewState property allows you to store a page’s state in a hidden form field (key-value pair) between client requests.
-
The ClearChildViewState property allows you to delete view state information for any child controls residing on a page.
Two methods exist for inheriting from the Page class: the first is adding the @ Page directive to an .aspx file. By doing so, the directive automatically makes available all page properties and methods for any code written on the page.
<%@ Page Language ="vb"%>
The second method uses the code-behind feature to inherit from the Page class associated with a particular page by specifying either the Src or Inherits attribute:
<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="RegisterForm.aspx.vb"
Inherits="RegisterForm.WebForm1" %>
The second method allows ASP.NET to combine the code in the web form’s .aspx file with the code in the code-behind class file and compile both files to a single merged file at compile time.
An ASP.NET Page’s Life Cycle
Let’s examine a page’s life cycle to further our knowledge of ASP.NET pages. Figure 6-1 illustrates the page’s process from its inception to its destruction.
Figure 6-1: An ASP.NET page’s life cycle
Each ASP.NET page contains a server-side <form> tag. This tag directs the page to post back to itself when a client submits the form. The Form type events include Load, Draw, Render, and Unload.
ASP.NET controls also render JavaScript to the client, enabling actions such as selecting a specified item from a drop-down list, thereby causing a post back to the server. The ASP.NET runtime also renders a hidden form field to the page and allows it to preserve its state between client requests.
| Note | The engagement between client and page in the case of hidden form fields occurs on the client side, rather than on the server. |
Because ASP.NET is event driven, client and page interaction allows the page to be reconstructed on the server. It also permits code execution in response to events raised by users and any changes occurring in the hidden fields.
The initial event begins with an HTTP URL client request for rendering a specific page to a client’s browser. The Load event fires next. Here is where the CLR uses reflection to examine the .aspx page and see if the page is called for the first time, or whether this represents a post back through user interaction with a button or some other page control. If the event is a first-time request, the code is converted to a class. Subsequently, the class compiles to an assembly and is stored in a valid Internet Information Server virtual directory where the page can be located. However, if the page is posted back, ASP.NET restores any data residing in hidden fields (ViewState) and passes the information to the server. The control event triggering the post back then fires. At this point, all control events are initiated. The change events fire first; those events are stored in the browser and execute only when the client sends the page back to the server. After a control event fires, the page is rendered to the browser.
Before Page_Unload() unloads the page from server memory, a final event performs any cleanup tasks before the unload method disposes of the page.
| Note | A dynamically generated assembly is not static. If you modify any application code in the .aspx page, the DLL is regenerated the next time the page is called before storing it again to the disk. Latency is an issue here. For example, in a network, latency is a delay. Latency could be solved by multithreading. The browser will respond to callbacks and DLL regeneration. |
Applying Page Directives
Most likely if you are a classic ASP developer, you have used directives such as @ Include and @ Language. The @ Include directive instructs the ASP runtime to include a particular file inline with the page. The @ Language directive tells the runtime to employ a specific script interpreter located within the <% %> render blocks. Directives provide easy ways for developers to determine declaratively how various aspects of an application will ultimately behave. For example, in addition to the @ Language directive, classic ASP provided only four directives:
-
@ Codepage Used in globalization to set the code page for an ASP page
-
@ EnableSessionState Used to disable session state for a specified page
-
@ LCID Used to set the locale identifier for an ASP page
-
@ Transaction Used to specify how a page participates in COM+ transactions
ASP.NET has added numerous directives for controlling page behavior, page configuration, and many other tasks. Table 6-1 presents a partial list of new directives included with ASP.NET. Note that in the Values column, T/F stands for true or false.
| Attribute | Values | Meaning |
|---|---|---|
| @@ Page | T/F | Defines page-specific attributes used by ASP.NET compilers and the CLR to determine page behavior. |
| AutoEventWireup | T/F | Determines whether handlers are set up automatically. Default is true. |
| Buffer | T/F | Specifies whether rendered output is buffered before sending it to clients, or sent as it is rendered. |
| ClassName | Can be any class name | Determines name of page when dynamically compiling the page. This works either with or without CodeBehind. |
| CodeBehind | File name of CodeBehind class | Visual Studio .NET uses this attribute |
| CodePage | Any code page | The same in both ASP and ASP.NET. |
| CompilerOptions | A string containing valid compiler options | Allows developers to specify compiler options for a specified page. |
| ContentType | Any valid MIME type | Sets the MIME type for page output. |
| Debug | T/F | Determines whether pages are compiled with debug symbols or not. Default is false. |
| Description | Any string | Provides a text description of the page. The ASP.NET runtime ignores this attribute. |
| EnableSessionState | T/F | Determines whether a page request initiates a new session and whether or not the page can access or modify data saved in an existing session. Default is true. |
| EnableViewState | T/F | Specifies whether ViewState is enabled for the page. Default is true. |
| EnableViewStateMac | T/F | Determines whether ASP.NET executes |
| Note | The list of directives in Table 6-1 is incomplete. Many other equally important directives exist, such as Inherits, ResponseEncoding, LCID, Strict, and Transaction. You can search for these directives in Visual Studio .NET Help. |
Here is a brief example of how you would use the Page directive:
<%@ Page debug="true" %>
Another example sets the trace directive:
<%@ Page trace="true" %>
Other directives include the @ Implements directive, employed to implement a defined interface from within an ASP.NET page. In addition, use the @ Register directive to register user controls and custom server controls on an ASP.NET page.
Code-Behind Feature
ASP.NET’s code-behind feature separates business logic from the presentation layer. In order to take advantage of this technique, derive from the Page class. Then place your code in an .aspx file and insert a reference to another file containing the business logic, for example:
<%@ Page Language="vb"%>
<%@ Register TagPrefix="ASPNETSBtn"
TagName="ClientName" src="/books/4/237/1/html/2/RegisterClient" %>
| Note | Any file rerferenced with the src attribute of the Page directive is compiled into a separate assembly and added to the list of referenced assemblies when the page is compiled. Additionally, an advantage of using the src attribute for the code-behind file is the ease with which the developer can update the code-behind file by replacing the file. Subsequently, the next time a page is requested, ASP,NET recompiles the file. |
The following example contains HTML, text, and several lines of VB .NET code. The web form has two Textbox controls named FirstName and LastName. The form also contains two RequiredFieldValidator controls that prevent you from submitting the form to the server without entering data in the FirstName and LastName Textbox controls.
| Note | The <asp: TextBox> tag informs the compiler that this ASP.NET page contains a text box control for execution on the server. |
A typical ASP.NET page looks like this:
<%@ Page Language = "vb" AutoEventWireup="false"
Codebehind = "WebForm1.aspx.vb" Inherits="IFCE.WebForm1"%>
<html><head><title>Registering a new client</title></head>
<body>
<form runat="Server">
<p>FirstName:
<br><asp:TextBox runat="Server"/>
<asp:RequiredFieldValidator ControlToValidate="firstName"
Runat="Server"/>
<p>LastName:
<br><asp:TextBox runat="Server"/>
<asp:RequiredFieldValidator
ControlToValidate="lastname"
Runat="Server"/>
<p>
<asp:button text="Submit Form" Runat="server"/>
</form>
</body>
</html>
| Note | If the <form> element is not present on the page, both web controls and HTML controls will not be able to participate in page post backs, nor will they be able to save their state in the page’s ViewState. They will continue to function otherwise. |
It is unwise to bypass one of the key benefits that ASP.NET offers, namely, preserving state between client page requests. Always add the <form> element to your web forms page. If a post-back event occurs, any state stored in hidden fields rendered to the form is retrieved and sent back to the server for rendering the new page to the browser. The user views the newly rendered .aspx page as though it were the original page. In reality, they are two individually unique pages.
|
EAN: 2147483647
Pages: 101