Classic HTML and Server-Side Controls

Most Web development involves interacting with user data in one way or another. Much of this data is contained in forms that users have filled out. Other items that fall into the user data category are things that are passed as parameters or contained in session variables . Web development in the past has always dealt with this kind of user data. ASP.NET provides a new way to interact with this data. It is a much more traditional way of programming than classic ASP programming, more closely resembling traditional Visual C++ or Visual Basic development.

Classic ASP programming can be used to create ASP pages that contain both HTML and VBScript code. The HTML is static ”it doesn't change ”whereas the ASP code dynamically generates HTML that is sent to the client machine. When this was first introduced, it offered a very powerful way to quickly and easily develop Web applications. The problem with this approach, of course, is that alternating between HTML and ASP code is confusing. It makes the code very hard to follow and decipher. It is much like the fabled spaghetti code that was so common in early BASIC programs.

Classic ASP development also offers some non-obvious challenges. For instance, what if you have a list of items in a <select> object? You may have 10 or 15 objects, perhaps describing merchandise colors. Depending on the situation, such as a formerly decided user selection, or some item that may be on sale, you may want different items in the select list to be selected. For instance, if red sweaters are on sale this week, you may want to default the color selector to red. Maybe your company has an abundance of red sweaters, and by making red the default you feel that you can sell more red sweaters. So you have to decide which of the items in the selection list is selected when the page first appears to the user. The way you do that in classic HTML is to add the selected attribute to one of the option items. This is easy to do if you are creating static HTML. But when you need to make a dynamic decision on which item to add this attribute to, it complicates things. What you end up doing is having a conditional test in the code, and then outputting the selected attribute to the appropriate item. Although this is a tried and true method that developers have used over the last five years , it tends to lead to unreadable or possibly unmanageable code.

The classic ASP code in Listing 11.1 shows the exact situation I just described. For your benefit I have included the resulting HTML code in Listing 11.2.

Listing 11.1 Classic ASP Code That Dynamically Selects a Color

 <select size="1" name="Colors">    <option value=Red>Red</option>    <option value=Green>Green</option>    <option value=Blue>Blue</option>  <%    If SESSION( "User" ) = "JOHN" Then      Response.Write( "<option selected value=Magenta>Magenta</option>" )      Response.Write( "<option value=Orange>Orange</option>" )      Response.Write( "<option value=Teal>Teal</option>" )    ElseIf SESSION( "User" ) = "GEORGE" Then      Response.Write( "<option value=Magenta>Magenta</option>" )      Response.Write( "<option selected value=Orange>Orange</option>" )      Response.Write( "<option value=Teal>Teal</option>" )    Else      Response.Write( "<option value=Magenta>Magenta</option>" )      Response.Write( "<option value=Orange>Orange</option>" )      Response.Write( "<option selected value=Teal>Teal</option>" )    End If  %>  </select> 

Listing 11.2 The Result of Listing 11.1 When the User Is GEORGE

 <select size="1" name="Colors">    <option value=Red>Red</option>    <option value=Green>Green</option>    <option value=Blue>Blue</option>    <option value=Magenta>Magenta</option>    <option selected value=Orange>Orange</option>    <option value=Teal>Teal</option>  </select>