Home arrow ASP.NET arrow Page 3 - Sample Chapter: Pure ASP.Net
ASP.NET

Sample Chapter: Pure ASP.Net


In this sample chapter from "Pure ASP.Net", we'll see what web forms are, how the code is processed on the server and how client-side code can also be integrated into web forms...

Author Info:
By: Mitchell Harper
Rating: 4 stars4 stars4 stars4 stars4 stars / 46
January 26, 2003
TABLE OF CONTENTS:
  1. · Sample Chapter: Pure ASP.Net
  2. · Server-Side Code Blocks
  3. · Web Form Events
  4. · Conclusion

print this article
SEARCH DEVARTICLES

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.

The 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.
blog comments powered by Disqus
ASP.NET ARTICLES

- How Caching Means More Ca-ching, Part 2
- How Caching Means More Ca-ching, Part 1
- Reading a Delimited File Using ASP.Net and V...
- What is .Net and Where is ASP.NET?
- An Object Driven Interface with .Net
- Create Your Own Guestbook In ASP.NET
- HTTP File Download Without User Interaction ...
- Dynamically Using Methods in ASP.NET
- Changing the Page Size Interactively in a Da...
- XML Serialization in ASP.NET
- Using Objects in ASP.NET: Part 1/2
- IE Web Controls in VB.NET
- Class Frameworks in VB .NET
- Cryptographic Objects in C#: Part 1
- Sample Chapter: Pure ASP.Net

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials