The internal structure of an ASP.NET page is extremely modular and comprises three distinct sections—page directives, code, and page layout.
The code section includes any source code pertinent to the page, such as event handlers and helper routines. The page layout represents the skeleton of the page and includes server controls, literal text, and HTML tags. What about page directives, then?
In the end, the set of page directives establish the environment in which the page will run. Directives specify how the HTTP runtime should process the page, and determine which assumptions about the page’s behavior are safe to make. Directives also let you import namespaces to simplify coding (the @Import directive), load assemblies not currently in the global assembly cache (the @Assembly directive), and register new controls with custom tag names and namespace prefixes (the @Register directive). The role of a couple more directives—specifically, @Implements and @Reference—is less emphasized in literature; perhaps little used in practice, but still important.
The @Implements directive indicates that the current page implements the specified interface. Implementing an interface in an ASP.NET page is definitely possible and in no way different from implementing the same interface in a class. If you write the page with inline code, you declare any required methods and properties within the <script> section. The syntax of the @Implements directive is as follows:
<%@ Implements interface="InterfaceName" %>
The @Implements directive can appear multiple times in the page if the page has to implement multiple interfaces. Note that if you use the code-behind model, you can't use the directive to implement interfaces. In this case, you simply implement the interface in the code-behind class.
The @Reference directive is used to establish a dynamic link between the current page and the specified page or user control. It enables cross-page communication and lets you create strongly typed instances of user controls. The @Reference directive can appear multiple times in the page and features two mutually exclusive attributes—Page and Control. Both attributes are expected to contain a path to a source file:
<%@ Reference page="source_page" %> <%@ Reference control="source_user_control" %>
The Page attribute points to an ASP.NET source file, whereas the Control attribute contains the path to a user control. In both cases, the referenced source file will be dynamically compiled into an assembly, thus making the classes defined in the source programmatically available to the referencing page. When the referencing page executes, a referenced page becomes a class that represents the ASPX source file and can be instantiated and programmed at will. Notice that for the directive to work, the referenced page must belong to the same domain as the calling page. Cross-site calls are not allowed, and both the Page and Control attributes expect to receive a relative virtual path.
It is worth noting that, in ASP.NET 2.0, the @Implements directive is used to let a page implement script callbacks, which is the ability to perform lightweight roundtrips to the server to download up-to-date information on the client.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
