HTML Forms and ASP Forms | Microsoft Visual J# .NET (Core Reference) (Pro-Developer)

I l @ ve RuBoard

HTML forms are at the heart of any Web-based application ”they provide the standard way of gathering input from users. Figure 16-4 shows a simple HTML form. This form is part of an online cake ordering service and allows the user to determine how many people a cake of a certain size with a particular type of filling will serve.

Figure 16-4. A simple HTML form

The HTML required to generate this form is fairly simple; it is shown in the FeedsHowMany.htm sample file listed below. As you can see, the form consists of three user input controls: two text boxes and a Submit button. These controls allow the user to specify a cake size and a type of filling. When the user clicks the Calculate button, the information in the two text boxes is sent to the URL specified by the action attribute. The method attribute defines whether the form data is appended to the URL ( method="get" ) or sent in the body of the HTTP request ( method="post" ). In this case, the action is just an example and is set to someURL , which will cause an error if you click the submit button.

FeedsHowMany.htm

 <HTML> <BODY> <formmethod="post" action="someURL"> Size:<inputtype="text" name="size"> Filling:<inputtype="text" name="filling"> <inputtype="submit" value="Calculate"> </form> </BODY> </HTML>

In the pre-ASP environment, this form would have been paired with some server-side functionality, such as a CGI script written in Perl, an ISAPI DLL, or a Java servlet. This is not an ideal style of development because the resulting application will consist of disparate components that must be kept in sync. Also, the server-side programming model and languages might be quite different from those used for the client development.

ASP and the equivalent JavaServer Pages (JSP) introduced a simpler model of server-side development in which the HTML for the Web page can be combined with script that is interpreted on the server. The script has access to server-side resources as well as any form data posted from the client, and it can use these resources and information to generate HTML dynamically as the page is delivered back to the client. This allows the static HTML of the page and the dynamic processing to be kept together, and it provides a more consistent development environment.

An ASP version of the entry form for cake information is shown in the listing of the FeedsHowMany.asp sample file. In this version, the page contains a calculate function written in JScript that is run on the server side to determine the number of people the cake will serve. (This calculation can also be written in JavaScript running on the client side, but because this information is a closely guarded secret, precise details of the calculation should not be sent to the client!)

FeedsHowMany.asp

 <%@Language=JScript%> <HTML> <BODY> <formmethod="post" action="FeedsHowMany.asp"> Size:<inputtype="text" name="size"> Filling:<inputtype="text" name="filling"> <inputtype="submit" value="Calculate""> <p>Thiswillfeed<%calculate()%>people</p> </form> </BODY> </HTML> <scriptlanguage="jscript" runat="server"> functioncalculate() { varfilling=Request.Form("filling")(); varsize=Request.Form("size")(); varnumConsumers=0; if(filling!=null&&filling!= "" &&size!=null&&size!= "") { fruitFilling=(filling== "fruit")?true:false; munchSizeFactor=(fruitFilling?3:1); numConsumers=size*munchSizeFactor; } Response.Write(numConsumers); } </script>

When the ASP page is accessed, it generates HTML that produces the form shown earlier in Figure 16-4. When the user fills out the form and clicks the Calculate button, the information is posted back to the URL of the ASP as defined by the form's action attribute. This causes the page to be processed again, but this time code in the ASP page can access the values submitted by the user through the intrinsic ASP Request object.

As part of the page processing, the calculate function is called. This function retrieves the size of cake and type of filling from the form and performs the calculation. Note that the calculate function is tagged as runat="server" , which indicates that it is a server-side script and that the function uses server-side objects made available by the ASP runtime, such as the intrinsic Request object. After the ASP has been processed, another version of the page is generated that contains the form, the message below it, and the correct number of cake eaters. This new page is then sent back to the client.

The result of asking how many people a 10-inch fruit cake will feed is shown in Figure 16-5.

Figure 16-5. An ASP page can change what is displayed based on user input, such as the size and filling of a cake.

As you can see, the correct result is displayed, but the data entered into the form has been lost. To rectify this, you could add more code to the ASP page that would set the value attributes of the text boxes to match those sent by the client every time the form is generated. However, this would add to the complexity of the ASP page. As the application became more complex, other functionality would be needed, such as different actions to be performed based on different button clicks. All of this would require more code in the ASP to handle the different requirements. This approach has several problems:

You end up continually reinventing the wheel because many people have already implemented the type of function that you want to perform. A lot of developer time is spent fiddling with code that processes the HTTP request and less time is spent writing business-oriented code.
The code in the page can become quite complex because you must keep track of when form submissions are made and smooth the transition between client and server. An example of this is the need to repopulate the text fields in a form every time the page is refreshed.
You have to connect parts of the application manually. For example, if a button click is to call a server-side function, you must hook up this client-side event to the server-side code yourself.

As you can see, ASP development is not without its problems. The main problems with ASP-based applications are as follows :

The mixed pages of script and HTML can become complex and difficult to maintain.
The programming model is somewhat awkward and requires considerable specialized knowledge of the underlying Web protocols.
ASP pages tend to run relatively slowly because their script is interpreted every time they're called.

Trying to solve these problems using existing technologies can lead to other problems. For example, you could migrate large amounts of server-side script code into COM components that could be called from the ASP page. This would improve the maintainability of the ASP page, but you'd have a different maintenance headache because the server-side functionality would be separate from the ASP page. This brings us back to the earlier situation in which a static HTML page containing a form is separate from the Perl page that provides its functionality. The parts of the application begin to drift apart again.

What you need is an approach that provides one logical unit for the code and HTML that form this part of the application while also providing a simple and familiar development model. ASP.NET Web Forms provide this functionality.

I l @ ve RuBoard