webdeveloper.earthweb.com/webjs/article.php/982451
By Jeff Prosise February 27, 2002 Page-Level DirectivesASP.NET supports a number of commands called page-level directives that you can put in ASPX files. They're sometimes called @ directives because all directive names begin with an @ sign: @ Page, @ Import, and so on. Page-level directives appear between <% and %> symbols and must be positioned at the top of an ASPX file. In practice, @ directives appear in all but the simplest of ASPX files. The table below lists the directives that ASP.NET supports. Succeeding sections document the most commonly used directives. Other directives are discussed as circumstances warrant elsewhere in the book. ASP.NET @ Directives
The @ Page DirectiveOf the various page-level directives that ASP.NET supports, @ Page is the one used most often. The following @ Page directive changes the default language for all scripts that don't specify otherwise from Visual Basic .NET to C#. It's especially useful when you "inline" code in an ASPX file by placing it between <% and %> tags: <%@ Page Language="C#" %> And here's an ASPX file that uses it:
<%@ Page Language="C#" %>
<html>
<body>
<%
Response.Write ("Hello, world");
%>
</body>
</html>
As this example demonstrates, ASP.NET pages can use Response and other intrinsic objects in the same way ASP pages can. Because you can't include Language="C#" attributes in <% %> blocks, you either need an @ Page directive telling ASP.NET which compiler to pass your code to or a Web.config file that changes the default language on a directory-wide basis. (If you're not familiar with Web.config files just yet, don't worry about it for now. You'll learn all about them in Chapter 9.) Another common use for @ Page directives is to enable debugging support. By default, ASP.NET builds release-build DLLs from your ASPX files. If you encounter a run-time error and need to debug it, you need DLLs with debugging symbols. The statement <%@ Page Debug="true" %> commands ASP.NET to create debug DLLs rather than release DLLs and enriches the information available to you when you debug a malfunctioning Web form. As you can see, @ Page is overloaded to support a variety of uses. In all, it supports some 28 different attributes such as Language and Debug. A page can have only one @ Page directive, but that directive can contain any number of attributes. For example, the statement <%@ Page Language="C#" Debug="true" %> enables debugging and sets the page's default language to C#. The @ Import DirectiveNext to @ Page, the directive that ASP.NET programmers use the most is @ Import. The @ Import directive is ASP.NET's equivalent of C#'s using statement. Its purpose is to import a namespace so that the types in that namespace are known to the compiler. You need @ Import anytime you use an FCL data type that's defined in a namespace that ASP.NET doesn't import by default. For example, the statement<%@ Import Namespace="System.Data" %> makes all the data types defined in System.Data available to a Web form. What namespaces does ASP.NET import by default? Here's a complete list:
Because System.Data isn't imported automatically, you must import it yourself if you want to use System.Data types (for example, DataSet) in a Web form. Otherwise, you'll receive an error message the first time ASP.NET attempts to compile the page. System.Web.Mail is another example of a commonly used namespace that isn't imported automatically. Look back at Chapter 3's SendMail program (Figure 3-8), and you'll see an @ Import statement importing System.Web.Mail on the very first line of the ASPX file. Unlike @ Page, @ Import can appear multiple times in a Web page. The following statements import three namespaces and are often used together in ASPX files that access SQL Server databases: <%@ Import Namespace="System.Data" %> <%@ Import Namespace="System.Data.SqlClient" %> <%@ Import Namespace="System.Data.SqlTypes" %> The @ Assembly DirectiveThe @ Import directive identifies namespaces containing an application's data types; @ Assembly identifies assemblies. The .NET Framework class library is implemented in a series of single-file assemblies: Mscorlib.dll, System.dll, and others. If ASP.NET is to compile your page, it must know which assemblies the page references so that it can provide that information to the compiler. The following assembly names are provided to the compiler by default and therefore require no @ Assembly directive:
These assemblies include the data types that Web forms are most likely to use. But suppose you want to use the FCL's System.DirectoryServices.DirectorySearcher class in a <script> block to perform a query against Active Directory. Because DirectorySearcher lives in an assembly (System.DirectoryServices.dll) that ASP.NET doesn't reference by default, its use requires an @ Assembly directive. In the following example, @ Import is required also because DirectorySearcher is defined in a nondefault namespace: <%@ Import Namespace="System.DirectoryServices" %> <%@ Assembly Name="System.DirectoryServices" %>It's coincidental that the namespace name and assembly name are one and the same; that's not always the case. Note that an assembly name passed to @ Assembly must not include the filename extension (.dll). In addition, the list of "default" assemblies can be changed by editing a machine-wide configuration file named Machine.config or augmented by dropping a Web.config file containing an <assemblies> section into an application root. Like @ Import, @ Assembly can appear multiple times in a Web page. The @ OutputCache DirectiveOne of the best ways to optimize the performance of ASP.NET applications is to cache Web pages generated from ASPX files so that they can be delivered straight from the cache if they're requested again. ASP.NET supports two forms of caching: page caching, which caches entire pages, and fragment (or subpage) caching, which caches portions of pages. The @ OutputCache directive enables an application to exert declarative control over page and fragment caching. Because examples have a way of lending clarity to a subject (funny how that works, isn't it?), here's a simple one that demonstrates @ OutputCache:
<%@ Page Language="C#" %>
<%@ OutputCache Duration="60" VaryByParam="None" %>
<html>
<body>
Today is <%= DateTime.Now.ToLongDateString () %>
</body>
</html>
This ASPX file displays today's date in a Web page. (The <%= ... %> syntax is an alternative to using Response.Write. It's an easy way to inject text into the page's output.) Since today's date changes only every 24 hours, it's wasteful to reexecute this page every time it's requested. Therefore, the page includes an @ OutputCache directive that caches the output for 60 seconds at a time. Subsequent requests for the page come straight from the cache. When the cache expires and ASP.NET receives another request for the page, ASP.NET reexecutes (and recaches) the page. The Duration attribute controls the length of time that the cached page output is valid. In real life, Web pages are rarely this simple. The output from an ASPX file often varies based on input provided by users. The designers of ASP.NET anticipated this and gave the page cache the ability to hold multiple versions of a page, qualified by the user input that produced each version. Imagine, for example, that you wrote a Web form that takes a city name and state name as input and returns a satellite image of that city from a database. (Sound far-fetched? It's not. Chapter 11 includes an application that does just that.) If the city and state names accompanying each request are transmitted in variables called city and state, the following directive caches a different version of the page for each city and state requested for up to 1 hour: <%@ OutputCache Duration="3600" VaryByParam="city;state" %> It's that simple. You can even use a shortened form of the VaryByParam attribute to cache a separate version of the page for every different input: <%@ OutputCache Duration="3600" VaryByParam="*" %> Now if two users request a satellite image of Knoxville, Tennessee 30 minutes apart, the second of the two requests will be fulfilled very quickly. |
| Go to page: Prev 1 2 3 4 5 Next |
|
|