Pro ASP.NET 2.0 In CSharp 2005 (2005) [eng]

98 CHAPTER 3 ■ WEB FORMS

Figure 3-11. Writing custom trace messages

Application Tracing

By default, tracing is enabled on a page-by-page basis. This isn’t always convenient. In some cases, you want to collect trace statistics for a page and then view them later. ASP.NET supports this approach with application-level tracing.

To enable application-level tracing, you need to modify the web.config configuration file. Look for the <trace> element and enable it as shown here:

<configuration>

<system.web>

<trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />

</system.web>

</configuration>

When you enable application-level tracing, you won’t see the trace information on the page. Instead, to view tracing information you must request the trace.axd application extension in your web application’s root directory. This extension doesn’t correspond to an actual file—instead, ASP.NET automatically intercepts the request and lists the most recently collected trace requests (as shown in Figure 3-12), provided you’re making the request from the local machine or have enabled remote tracing. You can see the detailed information for any request by clicking the View Details link.

100 CHAPTER 3 ■ WEB FORMS

Table 3-6. Continued

Tracing with the ASP.NET Development Helper

If you’ve installed the ASP.NET Development Helper introduced in Chapter 2 (and available at http://www.nikhilk.net/ASPNETDevHelperTool.aspx), you have another option for looking at tracing information—viewing it in a separate window. When the ASP.NET Developer Helper is running (both on the web server and web browser), it automatically removes trace information from the page. To access it, you can either uncheck the Hide Trace from Page check box (which shows it in the page) or click the Show Trace link.

Figure 3-13 shows this handy feature at work.

Accessing the HTTP Context in Another Class

Over the past several sections, you’ve seen how the Page class exposes a significant number of useful features that let you retrieve information about the current HTTP context. These details are available because they’re provided as properties of the Page class. But what if you want to retrieve this information from inside another class, one that doesn’t derive from Page?

Fortunately, another way exists to get access to all the HTTP context information. You can use the System.Web.HttpContext class. This class exposes a static property called Current, which returns an instance of the HttpContext class that represents all the information about the current request and response. It provides the same set of built-in ASP.NET objects as properties.

Figure 3-13. Managing trace information with the ASP.NET Development Helper

For example, here’s how you would write a trace message from another component that doesn’t derive from Page but is being used by a web page as part of a web request:

HttpContext.Current.Trace.Write("This message is from DB Component");

If you want to perform multiple operations, it may be slightly faster to retrieve a reference to the current context and then reuse it:

HttpContext current = HttpContext.Current; current.Trace.Write("This is message 1"); current.Trace.Write("This is message 2");

Summary

In this chapter you walked through a detailed examination of the ASP.NET page. You learned what it is and how it really works behind the scenes with postbacks and view state. You also learned the basics of the server control model, took a close look at the System.Web.UI.Page class, and learned how to use tracing. In the next chapter, you’ll take a closer look at the web controls that ASP.NET gives you to build sophisticated pages.

104 C H A P T E R 4 ■ S E R V E R C O N T R O L S

Types of Server Controls

ASP.NET offers many different server controls, which fall into several categories. This chapter explores the controls in the following categories:

HTML server controls: These are classes that wrap the standard HTML tags and are declared with the runat="server" attribute. Apart from this attribute, the declaration for an HTML server control remains the same. Two examples include HtmlAnchor (for the <a> tag) and HtmlSelect (for the <select> tag). However, you can turn any HTML tag into a server control. If there isn’t a direct corresponding class, ASP.NET will simply use the HtmlGenericControl class. To create one of these controls in Visual Studio, you need to drag an HTML element from the HTML tab of the Toolbox. Then, right-click the element, and choose Run As Server Control to add the runat="server" attribute.

Web controls: These classes duplicate the functionalities of the basic HTML tags but have a more consistent and meaningful set of properties and methods that make it easier for the developer to declare and access them. Some examples are the HyperLink, ListBox, and Button controls. In addition, several other types of ASP.NET controls (such as rich controls and validation controls) are commonly considered to be special types of web controls. In Visual Studio, you’ll find the basic web forms controls in the Standard tab of the Toolbox.

Rich controls: These advanced controls have the ability to generate a large amount of HTML markup and even client-side JavaScript to create the interface. Examples include the Calendar, AdRotator, and TreeView controls. In Visual Studio, rich controls are also found in the Standard tab of the Toolbox.

Validation controls: This set of controls allows you to easily validate an associated input control against several standard or user-defined rules. For example, you can specify that the input can’t be empty, that it must be a number, that it must be greater than a certain value, and so on. If validation fails, you can prevent page processing or allow these controls to show inline error messages in the page. In Visual Studio, these controls are found in the Validation tab of the Toolbox.

Additionally, you’ll examine several more specialized control groupings in other chapters. These include the following:

Data controls: These controls include sophisticated grids and lists that are designed to display large amounts of data, with support for advanced features such as templating, editing, sorting, and pagination. This set also includes the data source controls that allow you to bind to different data sources declaratively, without writing extra code. You’ll learn about the data controls in Chapter 9 and Chapter 10.

Navigation controls: These controls are designed to display site maps and allow the user to navigate from one page to another. You’ll learn about the navigation controls in Chapter 16.

Login controls: These controls support forms authentication, an ASP.NET model for authenticating users against a database and tracking their status. Rather than writing your own interfaces to work with forms authentication, you can use these controls to get prebuilt, customizable login pages, password recovery, and user creation wizards. You’ll learn about the login controls in Chapter 21.

Web parts controls: This set of controls supports WebParts, an ASP.NET model for building componentized, highly configurable web portals. You’ll learn about WebParts in Chapter 31.

ASP.NET mobile controls: This is a set of controls that resembles the web controls but is customized to support mobile clients such as PDAs, smart phones, and so on, by rendering pages to markup standards such as HTML 3.2 or WML 1.1. The mobile controls are highly adaptive, which means that when you create a page using these controls, the page can be rendered in several completely different ways depending on the device that’s accessing the page. (This concept is also used in ordinary web controls on a lesser scale. They can generate XHTML or HTML 4.01 with JavaScript code or generate plain HTML 3.2 code according to the client browser’s capabilities.)

ASP.NET mobile controls aren’t covered in this book, although you can learn more from Derek Ferguson’s Mobile .NET (Apress, 2001).

The Server Control Hierarchy

All server controls derive from the base Control class in the System.Web.UI namespace. This is true whether you’re using HTML server controls, using web controls, or creating your own custom controls. It also applies to the Page class from which all web forms derive. Figure 4-1 illustrates the main branches of this inheritance chain.

Figure 4-1. Server control inheritance

Because all controls derive from the base Control class, you have a basic common denominator that you can use to manipulate any control on the page, even if you don’t know the specific control type. (For example, you could use this technique to loop through all the controls on the page and hide each one by setting the Visible property to false.) Table 4-1 and Table 4-2 describe the most commonly used members of the Control class.

106 C H A P T E R 4 ■ S E R V E R C O N T R O L S

Table 4-1. Control Class Properties

HTML Server Controls

In the following sections you’ll learn about the HTML server controls, which are defined in the namespace System.Web.UI.HtmlControls. Overall, there are about 20 distinct HTML server control classes. They’re split into separate categories based on whether they are input controls (in which case they derive from HtmlInputControl) or can contain other controls (in which case they derive from HtmlContainerControl). Figure 4-2 shows the inheritance hierarchy.

Figure 4-2. HTML server controls

The HtmlControl Class

All the HTML server controls derive from the base class HtmlControl. Table 4-3 shows the properties that the HtmlControl class adds to the base Control class.

Table 4-3. HtmlControl Properties