Automate Your Classic ASP Web Forms

If you've ever created data-driven forms, especially complex ones, you know how hard it is to make all the control names and database column names match up correctly—and you'll immediately appreciate how the techniques shown in this article can simplify development, reduce errors, and minimize maintenance.

by Steve Skelton

Nov 14, 2003

Page 1 of 4

TML form handling consists of a set of named form controls on an HTML page and a Submit button for sending the information contained by the controls to a server, which presents a confirmation/summary page to the user, validates the information and then updates a database. Most important forms insert one more step—displaying the entered data in a preview page so that users can examine the information and correct any errors or incomplete data. When the user approves the information, the preview page's Submit button sends the data to the server, where server-side code writes the information to a database.

If you've developed data-driven Web applications, this scenario should be very familiar. Unfortunately, as forms become more complex, all this passing data back and forth makes developing such pages labor-intensive. It becomes increasingly difficult to ensure that developers perform the data-passing operations correctly, matching the form field control names to the label names for the data on the preview page, and eventually, to the correct columns in the database.

What You Need

Classic ASP, standard HTML form controls, an ASP-enabled Web server for building and troubleshooting your ASP code, and a SQL-aware database.

Consider the code fragments shown below, which contain:

Typical code for a generic HTML form
The server side code to format values submitted by the form into hidden fields on the preview page.
The server-side code to build a SQL INSERT statement to insert the data into a database.

The first task involves building a standard HTML form. Developers must select control names and associate those names with individual data fields. Generic HTML Form:

   <html>
      <form method="post" action="preview_form.asp">
         <input name="Control_Name" size="30" >
         <input type="submit" value="Submit" 
            name="B1">
         <input type="reset" value="Reset" 
            name="B2">
      </form>
   </html>

In the second task, developers gather submitted values from the form and insert them into fields for a preview page, touching each data value twice more. ASP Preview (Server-side Code)

   <!-- Insert the form value(s) into a hidden field 
        for submission to the database -->
   My Control Value: <input type="hidden" 
   name="Control_Name"> value="<% = 
   Request.Form("Control_Name")%>">

Finally, after the user approves the data on the preview page, developers must gather the hidden field values and construct an INSERT statement—touching the data values yet again. ASP Submit Page:





   <%
   ' DataConnection code goes here
   ' Construct an INSERT statement from 
   '   the submitted hidden field value(s)
   SQL = "Insert into Table (FieldNames) " & _
      "Values ("Control_Name")"
   DataConnection.Execute (SQL)
   %>

The process is extremely error-prone. As you can see from the code fragments, there are four separate places where a developer must identify a data value with the name "Control_Name." Misspelling the form control name can result in a variety of problems. If you misspell the control name in the <value="<% = Request.Form("Control_Name")%>"> section of the preview page, no value will display. Finding such an error is obvious for this simplistic form, but becomes considerably less obvious when you're assembling a preview page for a complex form. Unavoidably, the more complex the form, the easier it gets to miss the fact that one or more of the fields has a mismatched name.

Worse things can happen: if you accidentally use a control name that corresponds to an existing, but different control—a value will appear, but not the one you want. Or if you misspell the name in the hidden field and not in the value field, you'll see the right value in preview mode, but that value won't get sent to the database—and the UPDATE or INSERT won't necessarily report an error. For example, if your database field is Foo_1 and you assign Fooo_1 to the <input type="hidden" name="Fooo_1" value="<% = Request.Form("Foo_1")%>">, what happens to your data on submittal? If the submit string expects Foo_1 somewhere in the Request.Form stream, that value will not show up. The data contained by Fooo_1 disappears into cyberspace, never to be seen again.

When you're building forms with a lot of controls, you're in real danger of data loss if you don't handle the field names consistently. Wouldn't it be better for ASP to do all that for you?

In the course of finding a method to do this I found the following code on www.aspfaq.com:

   <% 
   For x = 1 To Request.Form.count() 
      Response.Write(Request.Form.key(x) & _
         "(" & x & ")" & " = ") 
      Response.Write(Request.Form.item(x) & _
         "<br>") 
   Next 
   %>

This code displays all the form elements (including the SUBMIT and RESET buttons) passed to it from a POST in the order they appear on the source form. This is the first step toward flawless form handling! You can use this technique to display control values and build a list of hidden control values automatically that will pass to a SUBMIT page where you can then construct the necessary SQL string for writing/reading/inserting the database. The following sections contain examples of each operation.

12 3 4 Next Page »

0 Comments (click to add your comment)

Comment and Contribute