Professional ASP.NET 2.0 Server Control and Component Development by Shahram Khosravi

Figure 1-1 follows the request all the way through the request processing architecture. The block arrows represent the request as it passes through different components. Everything starts when the user attempts to download the Default.aspx page; that is, the user makes a request for this page.

As Figure 1-1 shows, Internet Information Services (IIS) picks up the request and passes it to an ISAPI extension named aspnet_isapi.dll. After passing through some intermediary components, the request finally arrives in a .NET component named HttpRuntime. This component creates an instance of a .NET class named HttpContext that contains the complete information about the request, and exposes this information in the form of well-known, convenient managed objects such as Request, Response, Server, and so on. The cylinders in Figure 1-1 represent the HttpContext object as it's passed from one component to another.

The request finally arrives in a .NET component named HttpApplication. This component creates a pipeline of .NET components known as HTTP modules to perform preprocessing operations such as authentication and authorization. The results of these operations are stored in the HttpContext object.

After HTTP modules preprocess the request, HttpApplication passes the preprocessed request to a component known as an HTTP handler. The main responsibility of an HTTP handler is to generate the markup text that is sent back to the requester as part of the response. Different types of HTTP handlers generate different types of markup texts. For example, the HTTP handler that handles the requests for the .aspx extension, such as the Default.aspx page shown in Listing 1-1, generates HTML markup text similar to Listing 1-2. The HTTP handler that handles the requests for the .asmx extension, on the other hand, generates XML markup text.

Listing 1-2: The markup text that the HTTP handler generates in response to a request for the Default.aspx page

Therefore, ASP.NET instantiates and initializes the appropriate HTTP handler to handle or process the request for the specified extension. For example, as Figure 1-2 shows, ASP.NET takes the following actions to instantiate and initialize the HTTP handler that handles the request for the Default.aspx page; that is, the handler that emits or generates the HTML markup text shown in Listing 1-2 out of the Default.aspx file:

1. Parses the Default.aspx file.

2. Uses the parsed information to dynamically implement a control or class that derives from the Page class. By default, ASP.NET concatenates the name of the .aspx file with the string aspx and uses it as the name of this dynamically generated class. For example, in the case of the Default.aspx file, this class is named Default_aspx.

If you're curious as to what the code for this class looks like, here is what you need to do to view the code. Introduce a syntax error in the Default.aspx.cs and set the Debug attribute on the Page directive to true to run the application in debug mode. Now if you access the Default.aspx page, you'll get a page with a link named "Show Complete Compilation Source." Click this link to view the code for the dynamically generated class. Notice that the class is named Default_aspx.

3. Dynamically compiles the control or class.

4. Caches the compiled class.

5. Dynamically creates an instance of the compiled control.

6. Assigns the task of handling the request for the Default.aspx file to this instance.

The HTTP handler that processes the request for the Default.aspx file is a control or class named Default_aspx that ASP.NET dynamically implements from the contents of the Default.aspx file. As Figure 1-2 shows, the first four actions are taken only the very first time Default.aspx is being accessed. To handle the subsequent requests, ASP.NET simply retrieves the cached compiled Default_aspx class from the ASP.NET Cache object, creates an instance of the class, and assigns the task of handling the request to this instance.

Why Develop Custom Components?

As the previous section shows the request for a resource goes through different components of the ASP.NET request processing architecture, where each component contributes toward the final markup text that is sent back to the requester as part of the response message. As discussed, the content or type of the final markup text depends on the type of the requested resource, which normally depends on its extension. For example, the final markup text contains HTML if the request was made for an .aspx extension, and XML if the request was made for an .asmx extension.

The ASP.NET request processing architecture contains two groups of components:

Components that directly contribute to the generation of the final markup text. This group includes server controls such as TextBox, LiteralControl, Xml, and so on.

Components that indirectly contribute to the generation of the final markup text.

As an example of a component that contributes indirectly, consider the RoleManagerModule HTTP module shown in Figure 1-1. As you'll see later in this book, at the end of each request, this module retrieves the roles the current user is in from an object known as principal, and stores them in a cookie that is sent back to the requesting browser as part of the response.

At the beginning each request, on the other hand, the module retrieves the roles from the cookie and caches them in the principal object that represents the current user. Storing roles in a cookie improves the overall performance of a Web application because it's much more efficient to retrieve roles from a cookie than a database.

These roles affect the final markup text that is sent back to the user. For example, the application may only allow users in certain roles to access the Default.aspx page. Users who are not in one of those roles will receive a different HTML markup text that contains an error message.

You might be wondering why you would want to develop custom components. Why customize when you can use the existing standard ASP.NET controls and components?

This chapter invites you to change the way you think about the ASP.NET controls and components. This new perspective allows you to think of ASP.NET components in terms of their direct or indirect contributions to the final markup text that is sent back to the requester as part of the response message.

In light of this new perspective, you can easily address the preceding question. You need to develop custom components because there are many situations in which the contributions of the existing standard ASP.NET components do not add up to the markup text that would adequately service the request. The following sections provide a few examples of such situations to give you a flavor of what you can achieve with the skills, knowledge, and experience that this book provides you. Keep in mind that the examples and situations here make up only a very small portion of the situations and examples covered in this book.

Data Source Controls

Developing data-driven Web applications is a huge challenge because data comes from many different types of data stores, such as relational databases, XML documents, flat files, and Web services, to name a few. It's a challenge because different types of data stores use different types of data access APIs.

As you'll see in Chapters 12, 13, 14, and 15, a data source control is a component that acts as an adapter between the data store and your application. Your application can talk to any type of data store as long as there is an adapter for that type of data store. You can't use the same adapter to talk to two different types of data stores, however - each type of data store has its own adapter.

The ASP.NET Framework comes with standard data source controls for a handful of data stores, such as SQL Server and XML documents. This leaves out numerous data stores that your application cannot talk to. This is where you as the developer come into play. If you know how to develop a data source control, you can easily develop a data source control for your favorite data store to allow your application to talk to the data store without changing a single line of code in your application! Chapters 12-15 will help you gain the skills, knowledge, and experience that you need to develop data source controls.

Role Manager Modules and Principals

As discussed previously, the standard ASP.NET RoleManagerModule stores the current user's role information in a cookie to improve the performance of your application. This leaves out those clients that don't support cookies or where cookies are disabled.

Chapters 20 and 24 help you learn to develop a role manager module that can store the current user's role information in other sources, such as the Session object. Those chapters also teach you how to implement the IPrincipal interface to develop your own custom principals.

Role Providers

If you're using the ASP.NET 2.0 Framework to develop a brand new Web application, and if your clients don't have any requirements as to where and in what format or schema you should store your application's role information, you can store the role information in the standard SQL Server database named aspnetdb. However, if you have to move your existing applications to the new Framework, you can't afford to dump the database where your application has been storing role information for the last few years and start using the aspnetdb database. Or if you're using the ASP.NET 2.0 Framework to develop a brand new Web application but you're required to store your application's role information in a non-SQL Server data store such as XML documents or a SQL Server database with a different schema than the aspnetdb database, you can't use the aspnetdb database.

Chapters 20, 23, and 24 teach you everything you need to develop a role provider that will allow you to integrate your desired role data store (both relational such as SQL Server and Oracle, and non-relational such as XML documents) with the role management features of the ASP.NET 2.0 Framework.

Membership Providers

Much like the role provider, if you have applications that you need to move from ASP.NET 1.x to 2.0, you can't afford to dump the databases where you have been storing you user membership information for the last few years and jump to the new aspnetdb database. Or if you're developing a brand new ASP.NET 2.0 Web application but you're required to store your application's user membership information in a non-SQL Server data store such as XML documents or a SQL Server database with a different schema than the aspnetdb database, you can't use the aspnetdb database. Chapters 20, 21, and 22 teach you everything you need to develop a membership provider that will allow you to integrate your desired membership data store (both relational and non-relational) with the new ASP.NET 2.0 user membership feature.

Customizing XML Web Services and Their Clients

The ASP.NET 2.0 XML Web service infrastructure comes with two new exciting features that work together to provide you with amazing customization power. First, it allows you to implement the IXmlSerializable interface to take complete control over the serialization and deserialization of your custom components. Second, it allows you to implement your own custom schema importer extension to customize the code for the proxy class. These two features work hand-in-hand to empower you to resolve problems that you couldn't handle otherwise. One of these common problems is the significant degradation of the performance and responsiveness of XML Web services that expose huge amounts of data. Chapter 11 builds on Chapter 10 to teach you how to implement your own custom schema importer extensions to customize the proxy code generation and how to implement the IXmlSerializable interface to customize the serialization and deserialization of your custom components.

Developing Ajax-Enabled Controls and Components

Asynchronous JavaScript And Xml (Ajax) is a popular Web application development approach that allows a Web application to break free from the traditional click-and-wait user interaction pattern characterized by irritating waiting periods. An Ajax-enabled control or component exhibits the following four important characteristics:

It has rich client-side functionality that uses client-side resources to handle user interactions. Chapter 26 provides you with a detailed step-by-step recipe for using XHTML/HTML, CSS, DOM, and JavaScript client-side technologies to implement the client-side functionality of an Ajax-enabled control or component. Chapter 26 then uses the recipe to develop two Ajax-enabled controls.

It uses an asynchronous client callback to communicate with the server without having to perform a full-page postback. Chapter 27 shows you how to use the ASP.NET 2.0 client-callback mechanism to develop Ajax-enabled controls that make asynchronous client-callback requests to the server. Chapter 27 then uses the ASP.NET 2.0 client-callback mechanism to implement several Ajax-enabled controls and components.

It exchanges data with the server in XML format. Chapter 27, 28, and 29 show you how to develop Ajax-enabled controls and components that use XML, DOM, and JavaScript client-side technologies to read the XML data that they receive from the server and to generate the HTML that displays the XML data. These three chapters also implement several Ajax-enabled controls and components that exchange data with the server in XML format.

Its communication with the server is governed by Ajax patterns. Chapters 28 and 29 discuss the Predictive Fetch, Periodic Refresh, Submission Throttling, and Explicit Submission Ajax patterns in detail and use these patterns to implement several Ajax-enabled controls and components.

(Continues...)

---

Excerpted from Professional ASP.NET 2.0 Server Control and Component Development by Shahram Khosravi Copyright © 2006 by John Wiley & Sons, Ltd. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---