Pro CSharp And The .NET 2.0 Platform (2005) [eng]

844 CHAPTER 23 ■ ASP. NET 2 . 0 WEB PAGES AND WEB CONTROLS

Figure 23-9. The Default.aspx UI

Now, click the Source button at the bottom of your code window and locate the <form> section of your page. Notice how each web control has been defined using an <asp:> tag. Before the closing tag, you will find a series of name/value pairs that correspond to the settings you made in the Properties window:

<form id="form1" runat="server"> <div>

<asp:Label ID="lblInfo" runat="server" Text="Click on the Button to Fill the Grid">

</asp:Label>

<asp:GridView ID="carsGridView" runat="server"> </asp:GridView>

<asp:Button ID="btnFillData" runat="server" Text="Fill Grid" /> </div>

</form>

You will dig into the full details of ASP.NET web controls later in this chapter. Until then, understand that web controls are classes processed on the web server, and they emit back their HTML representation into the outgoing HTTP response automatically (that’s right—you don’t author the HTML!).

Beyond this major benefit, ASP.NET web controls support a Windows Forms–like programming model, given that the names of the properties, methods, and events mimic their Windows Forms equivalents. To illustrate, handle the Click event for the Button type using either the Visual Studio Properties window (via the lightning-bolt icon) or using the drop-down boxes mounted at the top of the Source view window. Once you do, you will find your Button’s definition has been updated with an OnClick attribute that is assigned to the name of your Click event handler:

<asp:Button ID="btnFillData" runat="server" Text="Fill Grid" OnClick="btnFillData_Click" />

As well, your <script> block has been updated with a server-side Click event handler (notice that the incoming parameters are a dead-on match for the target of the System.EventHandler delegate):

<script runat="server">

protected void btnFillData_Click(object sender, EventArgs e)

{

}

</script>

846 CHAPTER 23 ■ ASP. NET 2 . 0 WEB PAGES AND WEB CONTROLS

That was simple, yes? Of course, as they say, the devil is in the details, so let’s dig a bit deeper into the composition of this *.aspx file.

The <%@Page%> Directive

The first thing to be aware of is that a given *.aspx file will typically open with a set of directives. ASP.NET directives are always denoted with <%@ XXX %> markers and may be qualified with various attributes to inform the ASP.NET runtime how to process the attribute in question.

Every *.aspx file must have at minimum a <%@Page%> directive that is used to define the managed language used within the page (via the language attribute). Also, the <%@Page%> directive may define the name of the related code-behind file (if any), enable tracing support, and so forth. Table 23-2 documents some of the more interesting <%@Page%>-centric attributes.

Table 23-2. Select Attributes of the <%@Page%> Directive

The <%Import%> Directive

In addition to the <%@Page%> directive, a given *.aspx file may specify various <%@Import%> directives to explicitly state the namespaces required by the current page. Here, you specified you were making use of the types within the System.Data.SqlClient namespace. As you would guess, if you need to make use of additional .NET namespaces, you simply specify multiple <%@Import%> directives.

■Note The <%@Import%> directive is not necessary if you are making use of the code-behind page model. When you do make use of code-behind, you will specify external namespaces using the C# using keyword.

Given your current knowledge of .NET, you may wonder how this *.aspx file avoided specifying the System.Data or System namespaces. The reason is that all *.aspx pages automatically have access to a set of key namespaces, including the following:

•System

•System.Collections

•System.Collections.Generic

•System.Configuration

•System.IO

•System.Text

•System.Text.RegularExpressions

•All of the System.Web-centric namespaces

ASP.NET does define a number of other directives that may appear in an *.aspx file above and beyond <%@Page%> and <%@Import%>; however, I’ll reserve commenting on those for the time being.

The “Script” Block

Under the single-file page model, an *.aspx file may contain server-side scripting logic that executes on the web server. Given this it is critical that all of your server-side code blocks are defined to execute at the server, using the runat="server" attribute. If the runat="server" attribute is not supplied, the runtime assumes you have authored a block of client-side script to be emitted into the outgoing HTTP response:

<script runat="server">

protected void btnFillData_Click(object sender, EventArgs e)

{

}

</script>

The signature of this helper method should look strangely familiar. Recall from our examination of Windows Forms that a given event handler must match the pattern defined by a related .NET delegate. And, just like Windows Forms, when you wish to handle a server-side button click, the delegate in question is System.EventHandler which, as you recall, can only call methods that take

a System.Object as the first parameter and a System.EventArgs as the second.

The ASP.NET Widget Declarations

The final point of interest is the declaration of the Button, Label, and GridView Web Form controls. Like classic ASP and raw HTML, ASP.NET web widgets are scoped within <form> elements. This time, however, the opening <form> element is marked with the runat="server" attribute. This again is critical, as this tag informs the ASP.NET runtime that before the HTML is emitted into the response stream, the contained ASP.NET widgets have a chance to render their HTML appearance:

<form id="form1" runat="server">

...

</form>

ASP.NET web controls are declared with <asp> and </asp> tags, and they are also marked with the runat="server" attribute. Within the opening tag, you will specify the name of the Web Form control and any number of name/value pairs that will be used at runtime to render the correct HTML.

■Source Code The SinglePageModel example is included under the Chapter 23 subdirectory.

Working with the Code-behind Page Model

To illustrate the code-behind page model, let’s re-create the previous example using the Visual Studio 2005 Web Site template (do know that Visual Studio 2005 is not required to build pages using code-behind). Activate the File New Web Site menu option, and select the ASP.NET Web Site template (see Figure 23-11).

848 CHAPTER 23 ■ ASP. NET 2 . 0 WEB PAGES AND WEB CONTROLS

Figure 23-11. The Visual Studio 2005 ASP.NET Web Site template

Notice in Figure 23-11 that you are able to select the location of your new site. If you select File System, your content files will be placed within a local directory and pages will be served via WebDev. WebServer.exe. If you select FTP or HTTP, your site will be hosted within a virtual directory maintained by IIS. For this example, it makes no difference which option you select, but for simplicity I’d suggest the File System option.

■Note When you create an ASP.NET website, Visual Studio 2005 will place the solution file (*.sln) under the My Documents\Visual Studio 2005\Projects directory. Your site’s content files (such as the *.aspx files) will be located under the specified local directory or (if using IIS) within the physical file mapped to the virtual directory.

Once again, make use of the designer to build a UI consisting of a Label, Button, and GridView, and make use of the Properties window to build a UI of your liking. Now, click the Source button at the bottom of your code window, and you will see the expected <asp> and </asp> tags. Also note that the <%@Page%> directive has been updated with two new attributes:

<%@ Page Language="C#" AutoEventWireup="true"

CodeFile="Default.aspx.cs" Inherits="_Default" %>

The CodeFile attribute is used to specify the related external file that contains this page’s coding logic. By default, these code-behind files are named by suffixing .cs to the name of the *.aspx file (Default.aspx.cs in this example). If you examine Solution Explorer, you will see this code-behind file is visible via a subnode on the Web Form icon (see Figure 23-12).

■Source Code The CodeBehindPageModel example is included under the Chapter 23 subdirectory.

Details of an ASP.NET Website Directory Structure

If you have created web applications using ASP.NET 1.x, you may be quite surprised to see that many familiar files (Web.config, Global.asax, AssemblyInfo.cs, and so on) are not included when creating a new website. As well, the Web Site template contains a folder named App_Data and does not appear to have References folder within Solution Explorer.

First of all, do know that Web.config and Global.asax files are most certainly supported under ASP.NET 2.0, but you will need to explicitly add them to your project using the WebSite Add New Item menu option. Chapter 24 will examine the role of both of these file types, so don’t sweat the details for now. Next, be aware that your websites are still able to add references to any number of external .NET assemblies via the WebSite Add Reference menu option (the end result is a bit different, however, as you will soon see).

Another significant difference is that under Visual Studio 2005, websites may contain any number of specifically named subdirectories, each of which has a special meaning to the ASP.NET runtime. Table 23-3 documents these “special subdirectories.”

Table 23-3. Special ASP.NET 2.0 Subdirectories

If you are interested in adding any of these known subfolders to your current web application, you may do so explicitly using the WebSite Add Folder menu option. However, in many cases, the IDE will automatically do so as you “naturally” insert related files into your site (e.g., adding a new C# file will automatically add an App_Code folder to your directory structure if one does not currently exist).

852 CHAPTER 23 ■ ASP. NET 2 . 0 WEB PAGES AND WEB CONTROLS

The Role of the Bin folder

As described in a few pages, ASP.NET web pages are eventually compiled into a .NET assembly. Given this, it should come as no surprise that your websites can reference any number of private or shared assemblies. Under ASP.NET 2.0, the manner in which your site’s externally required assemblies are recorded is quite different from ASP.NET 1.x. The reason for this fundamental shift is that Visual Studio 2005 now treats websites in a projectless manner.

Although the Web Site template does generate a *.sln file to load your *.aspx files into the IDE, there is no longer a related *.csproj file. As you may know, ASP.NET 1.x Web Application projects recorded all external assemblies within *.csproj. This fact brings up the obvious question, where are the external assemblies recorded under ASP.NET 2.0?

When you reference a private assembly, Visual Studio 2005 will automatically create a Bin directory within your directory structure to store a local copy of the binary. When your code base makes use of types within these code libraries, they are automatically loaded on demand. By way of a simple test, if you activate the WebSite Add Reference menu option and select any of the previous (non–strongly named) *.dlls you created over the course of this text, you will find a Bin folder is displayed within Solution Explorer (see Figure 23-14).

Figure 23-14. The Bin folder contains copies of all referenced private assemblies.

If you reference a shared assembly, Visual Studio 2005 automatically inserts a Web.config file into your current web solution (if one is not currently in place) and records the external reference within the <assemblies> element. For example, if you again activate the WebSite Add Reference menu option and this time select a shared assembly (such as System.Drawing.dll), you will find that your Web.config file has been updated as so:

<?xml version="1.0"?>

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <appSettings/>

<connectionStrings/>

<system.web>

<compilation debug="false">

<assemblies>

<add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

</assemblies>

</compilation>

<authentication mode="Windows"/> </system.web>

</configuration>

As you can see, each assembly is described using the same information required for a dynamic load via the Assembly.Load() method (see Chapter 12).