Some input HTML forms don't require more than a plain submit button; other forms require submit and reset buttons. The HTML standard syntax covers both of these scenarios effectively. The HTML 4.x standard provides two kinds of special input buttons—Submit and Reset—that browsers know how to deal with. Sometimes, however, you require multiple submit buttons on the same HTML form, and you also have to trigger different operations on the server, depending on which button was clicked. For example, a given input form might display details about a given customer, and the form might also offer two options: Update and Delete.
As you can see, each button is going to trigger a distinct operation and require its own special handling code on the server. How would you address this code requirement? Interestingly, implementing this type of code was never perceived as a problem in ASP.NET Web Forms because of the more abstract programming interface that Web Forms offers. But what about ASP.NET MVC?
In ASP.NET MVC, you can afford much more freedom in the way in which you organize and express the view. However, you lose some of the infrastructure capabilities that characterize ASP.NET Web Forms. In the end, it's a tradeoff. Still, ASP.NET MVC includes its own full bag of programming goodies that, properly used, simplify form programming.
Multi-Button Forms in ASP.NET Web Forms
Imagine a classic two-button form in ASP.NET Web Forms in which you have a couple of submit buttons in addition to several input fields. For example, you have one button to save the current content and one to delete it. Figure 1 shows some sample code.
For a Web Forms developer, this code is a no-brainer. The code that handles the act of any user clicking the Update button or the Delete button is explicitly written through the handler methods that are associated with the OnClick event. For example, when the user clicks to update the database by using the current content of the form, the btnUpdate_Click method runs. The method is typically defined in the code-behind class of the page, such as in the following example.
void btnUpdate_Click(Object sender, EventArgs e)
{
:
}
The ASP.NET Web Forms markup actually produces a markup that's similar to the following example.
<form action="...">
<input type="text" ... />
<input type="text" ... />
:
<input type="submit" value="Save" name="btnUpdate" />
<input type="submit" value="Delete" name="btnDelete" />
</form>
When the browser processes the post, it serializes the content of the form's input fields to a string. This string is then uploaded as the body of the resulting HTTP packet. The form's content includes the name of the button that the user clicked to post the form. Based on that piece of information, the ASP.NET runtime determines which server component is responsible for handling the event, and invokes any code that is associated with the OnClick handler. In summary, the runtime infrastructure in ASP.NET Web Forms figures out which button was clicked and what code is associated with it. In Web Forms, you don't have to know which button was clicked.
The Form Action Mechanism
In ASP.NET MVC, you usually express the form by using plain HTML syntax. This process is both good and bad news. Good because it allows you to control exactly what's going on; bad because you are responsible for setting any of the attributes, and because you can't rely on any of the high-level facilities of Web Forms.
When the user posts a form in ASP.NET MVC, the action URL typically points to a controller method that takes control of the operation on the server. You help ASP.NET MVC find the controller method by using the parameters of the <form> tag. The following is an example of such code.
<% Html.BeginForm("demo1", "Home"); %>
<input type="text" ... />
<input type="text" ... />
:
<input type="submit" value="Update" name="btnUpdate" />
<input type="submit" value="Delete" name="btnDelete" />
<% Html.EndForm(); %>