- Understanding Page Events
- Understanding Page Properties
- Understanding Directives
- Code Separation and Using Code-Behind
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding Directives
ASP.NET directives can simply be described as instructions and settings used to describe how ASP.NET web form pages (.aspx) or User control (.ascx) pages will be processed by the .NET Framework. They are little do-dads that we insert in our ASP.NET pages to control how a page acts or the characteristics it has.
These directives aren't very different from a person's personality traits. Some people are shy, whereas others are outspoken. Some like loud, raucous music, whereas others enjoy the soft sounds of folk music. Some people can compute complicated math problems in their heads, and others can write wondrous stories that capture the imagination.
ASP.NET directives help you give your pages personality and capabilities. You can cause one page to behave in one fashion, whereas another page responds to the same stimulus in a totally different way. One page can have one set of skills or capabilities, whereas another has a totally different set. Directives give us this power.
Table 4.3 shows a list of directives that you will commonly use, but this isn't an exhaustive list. As is true with many aspects of the .NET Framework, the full scope of directives is beyond the scope of this book, but you can see the full list of directives, their functions and their players, in the .NET Framework SDK at the following link:
ms-help://MS.NETFrameworkSDK/cpgenref/html/cpconpagedirectives.htm
Table 4.3 Directives
|
Directive |
Description |
|
@Page |
This defines page-specific attributes used in ASP.NET pages (.aspx). |
|
@Control |
This defines control-specific attributes used in ASP.NET User controls (.ascx). |
|
@Import |
Imports a namespace into a page or User control. |
|
@Register |
Creates an alias to User controls, allowing them to be rendered to the browser when they are included in a requested page. |
@Page
@Page directives allow you to set attributes that directly affect your ASP.NET pages that end with the .aspx extension. There are 26 directives available, and you can explore the exhaustive list in the SDK at the link I provided a few paragraphs back, but Table 4.4 contains some of the more commonly used @page directives.
Table 4.4 @Page Directives
|
Directive |
Description |
|
Buffer |
As seen in the previous section on the Response object, this sets whether the Buffer is enabled or not. This is true by default and would need to be set explicitly to false. |
|
EnableSessionState |
This defines Session-State requirements for the page. If this is set to true (default) then Session-State is enabled; if false Session-State is disabled; or if ReadOnly then Session state can be read but not changed. |
|
EnableViewState |
This direct controls whether ViewState(Maintain GUI state) is maintained across page requests. It is true by default. |
|
Explicit |
Specifies whether all variables on a page must be declared using a Dim, Private, Public, or ReDim statement in Visual Basic .NET. The default is false. |
|
Inherits |
Defines a class from a code-behind page that a page should inherit. (Don't worry, this will be explained is a few short minutes.) |
|
Language |
Informs the .NET Framework of the language used for all inline(<% %>) and server-side script blocks within the ASP.NET page. |
|
Src |
This contains the name of the source file for an included code-behind page. |
|
Trace |
This indicates whether tracing is enabled or not. True is enabled; otherwise false. False is the default. Tracing is a debugging function in ASP.NET that allows you to see diagnostic and debug information about an ASP.NET page. |
Some of these may seem a bit Greek to you, but you will be seeing many of them throughout the book, and they will be more clear to you then. For the time being, just keep this section in mind and look at it as a seed we're planting that will spring back to your memory later in the book.
The following is a small example of what an @Page directive looks like:
<%@ page language="c#" buffer="true" Explicit="true" runat="server" %>
@Control
The @Control directive operates in exactly the same way the @Page directive does, except that it is used specifically for User controls only. The next chapter discusses User controls in depth, but if you remember from Chapter 1, a User control is ASP.NET's answer to Server-Side Include files.
The @Control directive uses many of the same directives that the @Page directive uses. From the directives I included for @Page, @Control uses all of them except Buffer, EnableSessionState, and Trace. If you think about it, this makes perfect sense because these are attributes that affect an entire page and can't be applied to small sections of included documents, like a User control.
@Import
The @Import directive is used to allow you to import a namespace (group of class objects) into your ASP.NET page, making all its classes available for use on your page. You can use this function to import namespaces that are part of the .NET Framework, or you can also use it to import namespaces that are user-defined.
The following namespaces are automatically imported into your ASP.NET pages, so all the class objects within these namespaces are available without you having to explicitly import them.
System
System.Collections
System.Collections.Specialized
System.Configuration
System.IO
System.Text
System.Text.RegularExpressions
System.Web
System.Web.Caching
System.Web.Security
System.Web.SessionState
System.Web.UI
System.Web.UI.HtmlControls
System.Web.UI.WebControls
As I said before, the @Import directive can be used to import existing .NET Framework namespaces and user-defined namespaces as well. In an earlier chapter, you created a class (blueprint) for a ball. Also, I've outlined creating a user-defined class in Appendix B of this class in the namespace called Peter.Toybox. The following is an example of how to import this namespace, as well as of the .NET Framework namespace called System.Data.
<%@Import Namespace="Peter.Toybox" %> <%@Import Namespace="System.Data" %>
@Register
The @Register directive is a powerful tool used for dynamically creating tags that represent your User controls.
WHAT? Can you repeat that in English?
First let me say that the next chapter shreds through User control in depth. We'll cover them from soup to nuts but for now try to remember that they are like Server-Side Includes except much cooler.
Let's imagine I create User controls for my site that will be used as my page's header and footer. These files will have an .ascx file extension to identify them as User controls. The @Register directive allows me to create a tag name and tag prefix with which my controls are associated, and it allows me to drop my User controls into my page with a single simple tag. I will call my header header.ascx and my footer footer.ascx for this example.
<%@Page Language="vb" runat="server"%> <%@Register TagPrefix="OurTag" Tagname="Header" Src="header.ascx"%> <%@Register TagPrefix="OurTag" Tagname="Footer" Src="footer.ascx"%> <html> <head> <title>@Register</title> </head> <body> <OurTag:Header id="OurHeader" runat="server"/> Here is our pages content <OurTag:Footer id="OurFooter" runat="server"/> </body> </html>
As you can see, I assign a TagPrefix, Tagname, and Src to define what file I'm attaching to TagPrefix:Tagname. As you can see, the TagPrefix and Tagname are separated by a colon. The TagPrefix can be used as many times as you want, and is set up this way so you can easily identify your own tags within your code. It's a simple yet powerful way to use User controls.
You can see how these different directives help you to shape and form your ASP.NET pages and control how they look, act and feel to your end user. We will be exploring and using in more abundance as time and this book progresses.