Previously, all ASP directives were formatted as <%@ [ attribute=value ] ⁺ %> because there was only one type of directive.^[43]

ASP.NET adds a number of directives to ASP.NET files. With the new list of directives—Page, Control, Import, Register, Assembly, and OutputCache—the syntax for directive is now <%@ directive [ attribute=value ] ⁺ %>. All of the old ASP directives are attributes under the Page directive. If you use the old syntax by omitting the directive name, the attribute/value pairs will be applied to the default directive, which is Page.

<@ Page Language="VB" ErrorPage="URL" EnableViewState="true">

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

<%@ Register Tagprefix="Ch07"
             TagName="MyCustomControl 
             Src="MyCustomControl.ascx" %>

<%@ Assembly Name="Ch07" %>

As in ASP, code declaration blocks define the code to be parsed and run for the page. In these blocks, the runat attribute specifies whether the code block is client-side or server-side code. For server-side programming, set this attribute to server. If you ignore the runat attribute, IIS will interpret the code block as client-side code, which is used for Dynamic HTML (DHTML).

<script runat="server" [language="codelanguage"]>
  Code
</script>

For both client-side and server-side code declaration blocks, you can also use the src attribute to point to an external source file containing the code. This is to help separate the code from the HTML content of the page.

<script runat="server" 
  [language="codelanguage"] 
  [src="externalfilename"] />

There are no changes to this syntax versus that in ASP. Inline code or inline expressions specified in these code rendering blocks are executed when the page is rendered. All these blocks are enclosed between the tags <% and %>. The language used in these tags is specified in the language attribute of the Page directive.

HTML controls are very similar to standard HTML elements, with the exception of the id and the runat attributes. If you’ve developed web applications with DHTML, you should be familiar with the id attribute of an HTML element and how to programmatically reference the client-side control representing the HTML element. The difference in this case is that the control is not on the client side but on the server side. For example, the following code represents an HTML server button control:

<input id="cmd1" runat="server"
  type="button" value="Click Me" />

All HTML server controls must be inside a <form runat="server"> control because web forms use the POST method to maintain the controls’ states.

When encountering an HTML element tagged with id and the runat attribute set to server, ASP.NET creates the appropriate scriptable server HtmlControl object. For example, the previous HTML snippet generates a server HtmlControl of type HtmlInputButton with id cmd1.

You can bind an event handler to this control’s event to handle notification from this control, such as the onclick event. There are two ways to bind an event handler to a control’s event, the declarative way and the programmatic way. The declarative is done inside the HTML element tag as an attribute/value pair. The attribute is the name of the event, and the value is the name of the event-handling function. For example, to handle the onclick event, add this to the previous HTML tag:

onserverclick="handleServerClick"

The programmatic way to bind an event to the handler involves a line of code that assigns a delegate to the event property of the control. In C#, the code to bind the ServerClick event of the button to the event handler handleServerClick is:

cmd1.ServerClick += new System.EventHandler(handleServerClick);

If you’ve used client-side DHTML in your web applications, event binding should be nothing new to you, except for some subtle differences. The first difference is obvious: the event handler runs on the server before the page is sent back to the browser, instead of running on the client side. The other difference is that all event-handler functions for server side have to have two parameters: Sender and Event. The Sender parameter indicates the source element that caused the event to happen; the Event parameter is the actual event fired. In DHTML scripting, we would inspect the window.event object to find out which element was the source of the event and other event information.

Similar to HTML Server Controls, custom controls also have id and runat attributes; however, custom controls are not standard HTML elements. To insert a custom control into a page, use the following syntax:

<tagprefix:tagname id="controlID" runat="server" eventname=
  "eventHandler" />

Notice that all custom controls’ tags have a tag prefix, which is an alias to the namespace in which the control is defined. See the Register directive earlier in this chapter for information on registering namespaces’ aliases.

Binding events to their handlers for custom controls is the same as for HTML controls. Even though we show the two ways of binding events, it is preferable to bind events using the second method because it cleanly separates the HTML tags from the code behind the screen.

All web controls mentioned in the WebControls namespace can be inserted in the same manner (these controls have the prefix asp). For example, you can have the following tags in your aspx page:

<asp:TextBox id=txt1 runat=server></asp:TextBox>
<asp:Button id=cmd1 runat=server Text="Web Button"></asp:Button>
<asp:Label id=label1 runat=server></asp:Label>

These tags result in three objects generated from the three classes: TextBox, Button, and Label, from the System.Web.UI.WebControls namespace. In your server script, you can access and manipulate these objects to render your page appropriately.

Data-binding expressions bind the server controls with some data sources. The syntax to bind data is:

<%# data-binding-expression %>

Let’s examine the following block of code to see how the simplest data binding works:

<asp:Label text='<%# TestData %>' runat=server/>

The data-binding expression here indicates that the label’s text content is bound to a publicly defined property, TestData, of the Web Form. This means that when data binding occurs for the form, <%# TestData %> will be replaced by the content of the TestData property. Let’s define this property for the Web Form:

public string TestData = "Hello World";

The Web Forms page framework does not perform data binding automatically. The developers must explicitly call the DataBind( ) method to activate the evaluation of the data-binding expression and perform the substitution. We can call the page’s DataBind method upon the page-load event or whenever we change the TestData property and want it reflected on the page. This example calls DataBind( ) upon page load to bind the Label’s text to the TestData variable.

<html>
  <head><title>Data Binding Sample</title></head>
  <body>

    <script language="C#" runat=server>
      /* Declare the variable we want to bind to. */
      public string TestData;
      void Page_Load(Object oSender, EventArgs oEvent) {
        TestData = "Hello World!
";
        Page.DataBind(  );
      }
    </script>

    <asp:Label text='<%# TestData %>' runat=server/>
 
  </body>
</html>

Let’s try something a little more complicated. In the next block of tags, we have three labels bound to three different properties of an object called currStudent:

Name: <asp:Label text='<%# currStudent.FirstName %>' runat=server/>
<asp:Label text='<%# currStudent.LastName %>' runat=server/> <br/>
SSN: <asp:Label text='<%# currStudent.SSN %>' runat=server/>

The currStudent object is a publicly accessible property of the current page.

<script language="C#" runat=server>
  public class CStudent {
    /* Declare the variable we want to bind to. */
    public string FirstName;
    public string LastName;
    public string SSN;
  }public CStudent currStudent;

  void Page_Load(Object oSender, EventArgs oEvent) {
    currStudent = new CStudent(  );
    currStudent.FirstName = "Jack";
    currStudent.LastName = "Daniel";
    currStudent.SSN = "123-45-6789";
    Page.DataBind(  );
  }

</script>

You can have this currStudent object filled with data coming from any source then perform a DataBind call to update the page with the current student’s information. The assumption here, of course, is that the Student class provides the previously mentioned properties.

Server-side object tags statically declare and instantiate COM and .NET objects. The syntax to declare server-side objects is:

<object id="id" runat="server" class=".NET class name">
<object id="id" runat="server" progid="COM ProgID">
<object id="id" runat="server" classid="COM classID">

To dynamically add a server-side object to the page, you would use the Page.LoadControl( ) method.

Server-side includes, server-side comments, and literal text are exactly the same as in ASP. Therefore, we will not go over them here.