• No results found

Directives for ASP.NET Web Forms:

In document ASP.net Web Application Web Forms (Page 27-34)

Directives specify settings that are used by the page and user-control compilers when the compilers process ASP.NET Web Forms pages (.aspx files) and user control (.ascx) files.

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.

Directives are instructions, inserted at the top of an ASP.NET page, to control the behaviour of the asp.net pages. So it is type of mixed settings related to how a page should render and processed.

Asp.Net web form page framework supports the following directives:

Directive Description

@ Page Defines page-specific attributes used by the ASP.NET page parser and compiler and can be included only in .aspx files.

@ Master Identifies a page as a master page and defines attributes used by the ASP.NET page parser and compiler and can be included only in .master files.

@ Control Defines control-specific attributes used by the ASP.NET page parser and compiler and can be included only in .ascx files (user controls).

@ Register Associates aliases with namespaces and classes, which allow user controls and custom server controls to be rendered when included in a requested page or user control.

@ Import Imports a namespace into a page or user control explicitly.

@ PreviousPageType Creates a strongly typed reference to the source page from the target of a cross-page posting.

@ Application The

Application

directive is used to define application-specific attributes. It is typically the first line in the Global.asax file.

@ Assembly Links an assembly to the current page or user control declaratively.

@ Implements Indicates that a page or user control implements a specified .NET Framework interface declaratively.

@ Reference Links a page, user control, or COM control to the current page or user control declaratively.

@ OutputCache Controls the output caching policies of a page or user control declaratively.

@ MasterType Defines the class or virtual path used to type the Master property of a page.

@ WebService Defines XML Web service specific (.asmx file) attributes used by the ASP.NET parser and compiler.

We use these directives in our applications whether the page uses the code-behind model or the inline coding model.

Basically, these directives are commands that the compiler uses when the page is compiled.

Directives are simple to incorporate into your pages.

A directive is written in the following format:

<%@ DirectiveName Attribute=Value %>

1.

Page Directive:

Basically Page Directives are commands. These commands are used by the compiler when the page is compiled.

When you want to specify the attributes for an ASP.NET page then you need to use @Page Directive.

As you know, an ASP.NET page is a very important part of ASP.NET, so this directive is commonly used in ASP.NET.

Every ASP.NET Web Form generally begins with the @ Page directive. This defines page-specific attributes used by the ASP.NET page parser and compiler and can be included only in .aspx files.

This directive can be used only in Web Forms pages. You can include only one @ Page directive per .aspx file. Further, you can define only one Language attribute per @ Page directive, because only one language can be used per page. Page Directives can be placed anywhere in .aspx file. But

standard practice is to include them at the top of the file. The Page directive is made of many attributes. There are following major attributes:

Attributes:

Language:

It Specifies the language used when compiling all inline rendering (<% %> and <%= %>) and code declaration blocks within the page. Values can represent any .NET Framework-supported language, including C# or VB. Only one language can be used and specified per page.

AutoEventWireup:

Indicates whether the page's events are auto wired. True if event auto wiring is enabled; otherwise, false.

By default its value is 'True' that means event of page class will be bound automatically with event handlers but if it is 'false' then we need to bind event handler with page class event manually.

CodeFile:

It specifies the name of the compiled file that contains the class associated with the page. This attribute is not used if the page uses inline code model as it represents to only code behind model.

Inherits:

Defines a code-behind class for the page to inherit. This can be any class derived from the Page class. This attribute is used with the CodeFile attribute, which contains the path to the source file for the code-behind class. The Inherits attribute is case-sensitive when using C# as the page language, and case-insensitive when using Visual Basic as the page language.

Title:

It specifies a title for the page that is rendered within the HTML <title> tags in the response. The title can also be accessed programmatically as a property of the page.

MasterPageFile:

Sets the path to the master page for the content page or nested master page. Supports relative and absolute paths.

Theme:

Specifies a valid theme identifier to use on the page. When the Theme attribute is set without using the StyleSheetTheme attribute, it overrides individual style settings on controls, enabling you to create a unified and consistent look on a page.

StyleSheetTheme:

Specifies a valid theme identifier to use on the page. When the StyleSheetTheme attribute is set, individual controls can override the stylistic settings contained in a theme. Thus a theme can provide an overall look for a site, while the settings contained in the StyleSheetTheme attribute enable you to customize particular settings on a page and its individual controls.

EnableTheming:

Indicates whether themes are used on the page. True if themes are used; otherwise, false. The default is true.

EnableViewState:

Specifies whether view state is maintained across page requests. This value is true if view state is maintained, or false if view state is not maintained. The default is true.

EnableSessionState:

Defines session-state requirements for the page. True if session state is enabled; ReadOnly if session state can be read but not changed; otherwise, false. The default is true.

ErrorPage:

Defines a target URL for redirection if an unhandled page exception occurs.

ValidateRequest:

Indicates whether request validation should occur. If true, request validation checks all input data against a hard-coded list of potentially dangerous values. If a match occurs, an HttpRequestValidationException exception is thrown. The default is true.

This feature is enabled in the machine configuration file (Machine.config). You can disable it in your application configuration file (Web.config) or on the page by setting this attribute to false.

Syntax:

<%@ Page attribute="value" [attribute="value"...] %>

For Example:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs"

Inherits="_Default" %>

2.

Master Page Directive:

The @Master Directive is quite similar to the @Page Directive. The only difference is that the

@master directive is for Master pages. You need to note that, while using the @Master Directive you define the template page's property. Then any content page can inherit all the properties defined in the Master Page. But there are some properties that are only available in a Master Page.

It Defines master page–specific (.master file) attributes that are used by the ASP.NET page parser and compiler.

Syntax:

<%@ Master attribute="value" [attribute="value"...] %>

Example:

%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage1.master.cs"

Inherits="MasterPage" %

3.

Control Directive:

Defines attributes that are specific to user controls (.ascx files) that are used by the ASP.NET page parser and compiler.

The @ Control directive is used when we build an Asp.Net web user controls. The @Control directive helps us to define the properties to be inherited by the user control. These values are assigned to the user control as the page is parsed and compiled.

This directive can be used only in user controls. User controls are defined in files with the .ascx extension. You can include only one @ Control directive per .ascx file. Further, you can define only one Language attribute per @ Control directive, because only one language can be used per control.

Note:

The @ Control directive has a number of attributes in common with other directives that apply to an entire source file, such as the @ Page directive (used in .aspx files for Web pages) and the @ Master directive (used in .master files for master pages).

Syntax:

<%@ Control attribute="value" [attribute="value"...] %>

Example:

<%@ Control Language="C#" AutoEventWireup="false" CodeFile="WebUserControl.ascx.cs"

Inherits="WebUserControl" %>

4.

Register Directive:

The @ Register directive associates aliases with namespaces and class names for notation in custom server control syntax. When you create a web user control and you drag and drop a web user control onto your .aspx pages, the Visual Studio automatically creates a @ Register directive at the top of the page. This register the user control on the page so that the control can be accessed on the .aspx page by a specific name.

The @ Register directive can be included in Web Forms (.aspx files), Web User Controls (.ascx files), and Master Pages (.master files).

Attributes:

Assembly

Note:

The assembly name cannot include a file extension. Also note that if the assembly attribute is missing, the ASP.NET parser assumes that there is source code in the App_Code folder of the application. If you have source code for a control that you want to register on a page without having to compile it, place the source code in the App_Code folder. ASP.NET dynamically compiles source files in the App_Code folder at run time.

Namespace:

The namespace of the custom control that is being registered.

Src:

The location (relative or absolute) of the declarative ASP.NET Web User Controls file to associate with the TagPrefix and TagName pair.

TagName:

An arbitrary alias to associate with a class. This attribute is only used for user controls.

TagPrefix:

An arbitrary alias that provides a shorthand reference to the namespace of the markup being used in the file that contains the directive.

Syntax:

<%@ Register attribute="value" [attribute="value"...] %>

Example:

<%@ Register Src="~/WebUserControl.ascx" TagName="WebUserControl" TagPrefix="uc1" %>

5.

Import Directive:

As you know you need to define namespaces in your .cs class file before using any type like class, interface, struct, enum. So the @Import Directive imports namespaces. This directive supports just a single attribute "Namespace" and this attribute takes a string value that specifies the namespace to be imported. One thing you need to note is that the @Import Directive cannot contain more than one attribute/value pair. But you can use multiple lines.

The @Import directive allows you to specify any namespaces to the imported to the Asp.Net pages or user controls. By importing, all the classes and interfaces of the namespace are made available to the page or user control.

Explicitly imports a namespace into an ASP.NET application file (such as a Web page, a user control, a master page, or a Global.asax file), making all classes and interfaces of the imported namespace available to the file. The imported namespace can be part of the .NET Framework class library or a user-defined namespace.

The @ Import directive cannot have more than one namespace attribute. To import multiple namespaces, use multiple @ Import directives.

A set of namespaces can be automatically imported into .aspx pages. The imported namespaces are defined in the machine-level Web.config file, within the <namespaces> section of the <pages> element. The following namespaces are automatically imported into all pages:

 System

 System.Web.Security

 System.Web.SessionState

 System.Web.UI

 System.Web.UI.HtmlControls

 System.Web.UI.WebControls

 System.Web.UI.WebControls.WebParts Example:

<%@ Import Namespace="System.Data" %>

6.

PreviousPageType Directive:

This directive specifies the page from which any cross-page posting originates.

The @PreviousPageType is a new directive makes excellence in asp.net 2.0 pages. The concept of cross-page posting between Asp.Net pages is achieved by this directive. This directive is used to specify the page from which the cross-page posting initiates.

Attributes:

TypeName: Specifies the type name for the previous page.

VirtualPath: Specifies the path to the file that generates the strong type.

Note:

Use the @ PreviousPageType directive to get strong typing against the PreviousPage property. You can use the @ PreviousPageType directive only on a Web Forms page (an .aspx file). If both attributes, TypeName and VirtualPath, are defined, the @ PreviousPageType directive will fail.

Example:

<%@ PreviousPageType VirtualPath="~/YourPreviousPageName.aspx" %>

7.

Application Directive:

The Application directive defines application-specific attributes. It is provided at the top of the global.asax file.

Application directives specify optional application-specific settings used by the ASP.NET parser when processing ASP.NET global application (.asax) files. Application directives are located at the top of the Global.asax file.

Note that the@ Applicationdirective can be used only in Global.asax files, while the other directives are used in other ASP.NET files such as Web pages (.aspx files) and user controls (.ascx files).

Application Directive supports following attributes: Language, Inherits, and CodeBehind.

Example:

<%@ Application Language="C#" %>

8.

Assembly Directive:

The @ Assembly directive links an assembly to the page or the application at parse time. This could appear either in the global.asax file for application-wide linking, in the page file, a user control file for linking to a page or user control.

OR

Links an assembly to an ASP.NET application file (such as a Web page, a user control, a master page, or a Global.asax file) during compilation, making all the assembly's classes and interfaces available

This directive supports the two attributes Name and Src. The Name attribute defines the assembly name (The assembly name does not include a file name extension) and the Src attribute defines the path to a source file to dynamically compile and link against.

Note:

You must include either a Name or a Src attribute in a @ Assembly directive, but you cannot include both within the same directive. If you need to use both of these attributes, you must include multiple @ Assembly directives in the file.

Example:

<%@Assembly Name="MyAssembly" %>

<%@Assembly Src="MyAssembly.cs" %>

9.

Implements Directive:

The @ Implements Directive gets the ASP.NET pages to implement .Net framework interfaces. This directive only supports a single attribute i.e. Interface.

OR

The Implement directive indicates that the web page, master page or user control page must implement the specified .Net framework interface.

Example:

<%@ Implements Interface="System.Web.UI.IValidator" %>

10.

Reference Directive:

The Reference directive indicates that another page or user control should be dynamically compiled and linked against the current ASP.NET file (Web page, user control, or master page) in which this directive is declared.

Attributes:

Page:

The external page that ASP.NET should dynamically compile and link to the current file that contains the @ Reference directive.

Control:

The external user control that ASP.NET should dynamically compile and link to the current file that contains the @ Reference directive.

VirtualPath:

The virtual path for the reference. Can be any file type as long as a build provider exists. For example, it would be possible to point to a master page.

Example:

<%@Reference VirtualPath="~/MyControl.ascx" %>

11.

OutputCache Directive:

The OutputCache directive controls the output caching policies of a web page or a user control.

Attributes: The very important attributes for the @OutputCache directive are as follows:

Duration:

The time, in seconds, that the page or user control is cached. Setting this attribute on a page or user control establishes an expiration policy for HTTP responses from the object and will automatically cache the page or user control output.

VaryByParam:

A semicolon-separated list of strings used to vary the output cache. By default, these strings correspond to a query string value sent with GET method attributes, or a parameter sent using the POST method. When this attribute is set to multiple parameters, the output cache

contains a different version of the requested document for each combination of specified parameters. Possible values include none, an asterisk (*), and any valid query string or POST parameter name.

Example:

<%@ OutputCache Duration ="180" VaryByParam="None" %>

12.

MasterType Directive:

The @MasterType Directive connects a class name to the ASP.NET page for getting strongly typed references or members contained in the specified Master Page.

This directive supports the two attributes TypeName and VirtualPath.

TypeName sets the name of the derived class from which to get the strongly typed or reference members and VirtualPath sets the location of the page from which these are retrieved.

If both attributes, TypeName and VirtualPath, are defined, the @ MasterType directive will fail.

Example:

<%@ MasterType VirtualPath="~/MasterPage1.master" %>

13.

WebService Directive:

Defines XML Web service specific (.asmx file) attributes used by the ASP.NET parser and compiler.

Attributes:

Class

The WebService directive's Class attribute specifies the name of the class implementing the web service. The Class attribute is required. The class specified can reside either in a separate code-behind file, or in-line in the .asmx file.

CodeBehind

Specifies the source file implementing the XML Web service, when the class implementing the XML Web service does not reside in the same file.

Debug

Indicates whether the XML Web service should be compiled with debug symbols. True if the XML Web service should be compiled with debug symbols; otherwise, false.

Language

Specifies the language used when compiling all inline code within the XML Web service file (.asmx). The values can represent any .NET-supported language, including C#, and VB, which refer to Visual C#, and Visual Basic .NET respectively.

Example:

<%@ WebService Language="C#" CodeBehind="~/App_Code/WebService.cs"

Class="WebService” %>

In document ASP.net Web Application Web Forms (Page 27-34)

Related documents