Page Execution Model


The page execution model in ASP.NET ties together all aspects of the page programming model. Chapter 1, "ASP.NET Overview," provided the outline for request processing inside an ASP.NET Web application. This section takes a deeper look at how a page handles an incoming request to generate an output response.

Figure 2-4 illustrates two incoming requests for the same page and shows how the page framework processes these two requests .

As described in Chapter 1, the incoming request is handled by Internet Information Services (IIS), which hands the request to the HTTP runtime in ASP.NET for processing. The page execution model begins with the page HTTP handler factory, which is registered with the HTTP runtime to handle requests for all .aspx files. The page handler factory is responsible for creating an instance of a Page object, which is an HTTP handler that will eventually process the request to produce the response output.

Figure 2-4. How a page handles requests

graphics/f02hn04.jpg

The page handler factory first attempts to look for a previously compiled page class in the ASP.NET cache associated with the .aspx file being requested . When this lookup fails, as it does during the first request, the handler factory reads in the file and parses it to create a parse tree . A parse tree is similar to a control tree. But instead of containing controls, a parse tree contains instances of objects known as control builders . Control builders contain information about controls that is gathered during the parsing process. The parse tree is then converted into code in the language associated with the page via the Language attribute of the Page directive. The page handler factory then invokes the appropriate compiler ”for example, the C# compiler, csc.exe ”to dynamically compile a class deriving from Page . The page handler factory also places the newly created page class into the ASP.NET cache and associates the cache entry with a file dependency. The file dependency monitors changes made to the .aspx file and ensures that any change automatically invalidates the cache entry, which causes the modified file to be reparsed the next time it is requested.

The page handler factory instantiates the dynamically compiled page class and allows the newly created instance to process the incoming request. An important aspect of the page programming model is that the pages execute as fully compiled code. This provides significantly better performance than interpreted code (such as code contained in Active Server Pages). The page executes the code generated from the parse tree, which creates and processes the control tree contained in the original .aspx file. The control tree has its own life cycle involving initialization, loading, rendering, and disposing. This life cycle is described in Chapter 9, "Control Life Cycle, Events, and Postback." In its final processing phase, the page renders itself to produce the response content. At the end of its processing cycle, the page is completely disposed of. Thus, the page framework does not maintain any state or page instances across requests. This enables the development of stateless and scalable Web applications.

During any subsequent request, the same page HTTP handler factory can use the previously compiled and cached page class and continue with its normal processing logic by again instantiating a new page instance to handle the new incoming request. This allows the handler factory to skip all the work of opening, reading, and parsing the file; generating code; and invoking the compiler. This single-parse-and-compile aspect of the page execution model greatly improves the performance and responsiveness of the Web application.

Viewing the Generated Code

You can view the code for the class that the page parser generates to transform the .aspx file into a control tree by turning on page debugging. In debug mode, the class file containing the generated code is preserved. However, this file is deeply nested in a temporary folder. The following steps provide a quick alternative to viewing the generated source code:

  1. Enable debugging by setting the Debug attribute of the Page directive to true in the .aspx file:

     <%@PageDebug="true" %> 
  2. Introduce a syntax error (such as an unbalanced parenthesis or a missing semicolon statement terminator) in your code inside a server-side script block in your page, and save the file.

  3. Request the page in your Web browser. The server will return an error message that contains various links at the bottom of the page.

  4. Click the Show Complete Compilation Source link. This displays the autogenerated code for your page.

You don't necessarily need to study and understand the generated code to use ASP.NET or develop server controls. However, you might find it useful to examine the code to understand the creation of the control tree. It can be useful to view the parser-generated source code for the page when debugging your application or controls.



Developing Microsoft ASP. NET Server Controls and Components
Developing Microsoft ASP.NET Server Controls and Components (Pro-Developer)
ISBN: 0735615829
EAN: 2147483647
Year: 2005
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net