Sample Chapter: Pure ASP.Net - Web Form Events
(Page 3 of 4 )
From the moment a user first requests an ASP.NET Web Form to the moment the server actually sends the response, quite a few events and processes occur. A few of the most important ones are described in the following sections.
A significant number of events occur between the moment a client issues a page request and the moment that the server sends the response. Many of these events will be transparent to you as the developer, and they will involve the compiler, the preprocessors, and the various collections that make up the .NET framework. However, you will need to understand some events because you will likely come across them in your coding escapades. Figure 3.1 shows the events in a life cycle of an ASP.NET request.
Page Directives Page directives enable you to set optional metasettings for the compiler when it processes the ASP.NET Web form. You can use page directives to set the default language for the ASP.NET Web form, enable or disable session state, choose to buffer the contents of the page before sending to the client, and make a host of other changes.
Page directives must be located at the very top of an ASP.NET Web Form, before any other code. A page directive is always contained inside <% %> tags and always begins with the @ character. Here is an example of the syntax used for a page directive:
<%@ directive.property = value %> For example, to turn off session state for a page, you use the following page directive:
<%@ Page EnableSessionState="false"%> Server-Side Includes SSIs offer a way to insert the contents of a file into an ASP.NET Web form. Because an SSI is inserted before the page is compiled to IL, you can use an SSI to insert blocks of source code into a page. You can use SSIs to add a copyright notice to the bottom of a page, include a common set of functions, or include any other sort of static content.
The code for an SSI looks like this:
<!-- #include PathType = FileName --> PathType can be set to either File or Virtual, depending on the type of path being referenced:
- File sets a relative path from the directory in which the ASP.NET Web Form is located. It is important to note that the file location cannot be in a directory higher on the file tree than the current directory. This prevents a possible breach in a site's security.
- Virtual enables you to include a file from a virtual path from a virtual directory on the Web server.
You should not use SSIs to encapsulate site functionality such as site navigation or common site text. ASP.NET offers a solution for these types of situations, called user controls, which are explored in the following section.
User Controls User controls provide a way to encapsulate site functionality in ASP.NET. Because user controls are self-contained in standalone files, you can think of them as a "black box." Variables are explicitly passed to user controls by using public properties. Similarly, for user control methods to be accessed outside the scope of the user control, they must be declared as public. If the user control contains HTML or Web Form information, then it will be produced inline, where the user control was included in the calling form. In this way, a user control is like any other server control.
User controls are self-contained entities, and they support fragment caching. By using a user control and fragment caching, it is possible to cache the output of a single piece of functionality on a page. For instance, if a page in an application contains a menu and highly personalized user content, it would be difficult to send the entire page to the output cache because of the high number of potential permutations of the personalized content. For instance, if a page welcomes a user by name, it would be difficult to cache the entire page since a separate copy of the page would need to be stored in memory for each user name. Encapsulating certain pieces of the page, such as the menu, into a user control and then turning on fragment caching for the user control increases the overall performance of the page.
Because user controls can be programmatically manipulated, several developers can use user controls to work on the design of an ASP.NET application simultaneously. Because each user control is self-contained, each developer can work on his or her part of the puzzle and not worry too much about interfering with someone else's code.
Visual Studio and the Code Behind Method Currently, there are two major paradigms for designing ASP.NET Web Forms:
- One method is to insert server-side code on a page that contains all the HTML and client-side code. This method of building pages should be familiar to ASP developers.
- Because ASP.NET Web Forms are compiled, you can place presentation logic such as HTML and any Web controls in one file and any server-side code (such as C# or Visual Basic.NET) in a second file. At compile time, the two pages are compiled as one entity. This method of designing ASP.NET Web Forms is called code behind.
Although many users might be reluctant to use this method, the code behind method offers some benefits. Presentation code such as HTML is neatly separated from any page logic being performed. This makes it easy for a development group in charge of graphics and layout to work independently of a group in charge of back-end development. Visual Studio.NET uses this code behind method of development. In fact, it doesn't support the traditional in-line code methodology at all.
If you have done significant development in previous versions of ASP, you might find code behind difficult to work with at first, especially when combined with all the other new features in ASP.NET. It's definitely worth learning to use, however, Visual Studio.NET impressively shortens development time.
Next: Conclusion >>
More ASP.NET Articles
More By Mitchell Harper
