Visual Basic .NET Developer's Guide to ASP.NET, XML and ADO.NET : Page Framework

In This Chapter:

ASP.NET's Control Model
Separating Presentation from Code Using Code Behind
Programming HTML Controls
Attributes of the Page Object
Creating User Interfaces with Web Controls
Server Controls and Page Object Reference

Programming an ASP.NET application is significantly different than programming in ASP.old. The difference can be likened to the change that occurred when moving from QuickBasic programming to Visual Basic programming.

The changes in ASP.NET can be broken down into three categories: the control model, the event model, and the separation of code from presentation.

ASP.NET's Control Model
In QuickBasic, your code dealt with the screen as a long piece of paper to which you sent output. You may have used screen libraries that encapsulated a lot of this functionality and made it a much higher-level operation with better positioning.

With the advent of Visual Basic, you moved into a world of reusable controls. You designed your UI by dragging and dropping controls onto a design surface instead of outputting text to the screen or drawing polygons.

These controls were objects that had methods and properties that were used to customize their display and functionality. ASP.old was in many ways similar to QuickBasic. The entire page was essentially treated as a long piece of paper onto which your code placed content. No object model gives you access to the HTML that surrounds your code—just a way for you to output additional HTML based on the location of your code.

ASP.NET changes this by introducing the concept of server controls. If you used Visual Interdev to create ASP.old Web applications, you may be thinking, "Great! They just renamed those onerous design-time controls!" This is not the case. Server controls are not design-time controls in another guise. Nor do server controls require any particular type of client—in other words, server controls aren't ActiveX Controls or client-side behaviors. Server controls are a high-level abstraction of functionality utilized during page execution to place user-interface elements onto the page.

Let's take a look at this. Listing 3.1 shows the HTML for a traditional ASP.old form.

Listing 3.1 A Simple ASP.old Page, SimplePage.asp

	<html>
	<head>
	  <title>SimplePage.asp</title>
	</head>


	<body>
	  <form name="WebForm1" method="post">
	<p>
	<table border=0>
	  <tr>
	   <td>Name:</td>   <td><input type=text name=txtName></td>
	   <td>
	    <input type=submit name=Button1 Value="Send">
	   </td>
	  </tr>
	  <tr>
	   <td valign=top>Hobby:</td>
	   <td>
	    <select name=lbHobbies Multiple>
	    <option Value="Ski">Ski</option>
	    <option Value="Bike">Bike</option>
	    <option Value="Swim">Swim</option>
	   </select>
	   </td>
	   <td>&nbsp;</td>
	  </tr>
	</table>
	</p>
	  </form>
	</body>
	</html>

What happens when a user fills in a name, chooses a hobby, and presses the Send button? The page is first posted back to the server. No code is in the form at this point, so all the selections that the user made in the Select tag (information that we'll refer to as form state) is lost. The page is then returned back to the browser. In ASP.old, if you want to preserve the form state, you are forced to write code to do that.

Listing 3.2 contains SimplePage2.asp showing the typical code you would write with ASP.old to make this work.

Listing 3.2 SimplePage2.asp Showing Code to Preserve Form State in ASP.old

	<html>
	<head>
	    <title>SimplePage.asp</title>
	</head>

	<SCRIPT LANGUAGE="VBScript" RUNAT=SERVER>
	    function IsOptionSelected(strControlName, strOption)
	        for iCount = 1 to Request(strControlName).Count
	          if request(strControlName)(iCount) = strOption then
	        response.write " SELECTED "
	      end if
	    next
	  end function

	</SCRIPT>

	<body>
	  <form name="WebForm1" method="post">
	    <p>
	    <table border=0>
	      <tr>
	        <td>Name:</td>
	        <td><input type=text name=txtName 
	          value="<% = Request("txtName") %>"></td>
	        <td><input type=submit name=Button1 Value="Send"></td>
	      </tr>
	      <tr>
	        <td valign=top>Hobby:</td>
	        <td>
	          <select name=lbHobbies Multiple>
	            <option <% IsOptionSelected "lbHobbies", "Ski" %> 
	               Value="Ski">Ski</option>
	            <option <% IsOptionSelected "lbHobbies", "Bike" %> 
	               Value="Bike">Bike</option>
	            <option <% IsOptionSelected "lbHobbies", "Swim" %> 
	               Value="Swim">Swim</option>
	          </select>
	        </td>
	        <td>&nbsp;</td>
	      </tr>
	    </table>
	    </p>
	  </form>
	</body>
	</html>

With the advent of server controls, ASP.NET adds functionality to HTML's own user-interface controls, making them do what you would expect them to do; that is, save the data that the user just spent time typing in.

You need to do three things to make ASP.NET server controls work.

ASP.NET server controls are identified using the ID attribute instead of (or in addition to) the Name attribute. You are allowed to use both. You may want to use the Name attribute if you have client-side script that needs to refer to the control.
ASP.NET server controls require you to add the runat=server attribute. This attribute indicates to ASP.NET that the tag is something more than a built-in HTML tag.
ASP.NET server controls require a closing tag. Server controls are implemented using XML namespaces and, like XML,require every element to have a matching closing element. You can use XML style syntax as a shortcut creating a tag such as <input type=text runat=server />.

So let's do this to the code that was in Listing 3.1. Listing 3.3 shows simplepage.aspx, an ASP.NET implementation of simplepage.asp.