Chapter 8. Validation
As we saw in Chapter 3, many web applications involve user input. The sad fact is, however, that users make mistakes: they skip required fields, they put in six-digit phone numbers, and they return all manner of incorrectly formatted data to your application. Your database routines can choke on corrupted data, and orders can be lost if, for example, a credit card number is entered incorrectly or an address is omitted, so it is imperative that user input be validated.
Traditionally, it has taken a great deal of time and effort to validate user input. Each field must be checked and routines must be created for ensuring data integrity. In the event that bad data is found, error messages must be displayed so that the user knows how to correct the problem.
In a given application, you may choose to validate that certain fields have a value, that the values fall within a given range, or that the data is formatted correctly. For example, when processing an order, you may need to ensure that the user has input an address and phone number, that the phone number has the right number of digits (and no letters), and that the social security number entered is in the appropriate form of nine digits separated by hyphens.
Some applications require more complex validation, in which one field is validated to be within a range established by two other fields. For example, you might ask in one field what date the customer wishes to arrive at your hotel, and in a second field you might ask for the departure date. When the user books dinner, you'll want to ensure that the date is between the arrival and departure dates.
There is no limit to the complexity of the validation routines you may need to write. Credit cards have checksums built into their values, as do ISBN numbers. ZIP and postal codes follow complex patterns, as do international phone numbers. You may need to validate passwords, membership numbers, dollar amounts, dates, runway choices, and launch codes.
As you can see, in traditional Internet programming, validation requires extensive custom programming. The ASP.NET framework greatly simplifies this process by providing rich controls for validating user input that provide precise control over the validation routine while requiring far less custom coding. They also allow you to specify exactly how and where the error messages will be displayed; either inline with the input controls, aggregated together in a summary report, or both. These controls can be used to validate input for both HTML and ASP controls.
You add validation controls to your ASP document just as you would add any other control. Within the declaration of the validation control, you specify which other control is being validated. You may freely combine the various validation controls, and you may write your own, as you'll see later in this chapter.
With uplevel browsers that support DHTML, such as Internet Explorer 4 or better, .NET validation is done client-side, avoiding the necessity of a round trip to the server. With downlevel browsers your code is unchanged, but the code sent to the client ensures validation at the server. Even when client-side validation is done, the values are validated server-side as well.
Because client-side validation will prevent your server-side event handlers from ever running if the control is not valid, you may want to force server-side validation. In that case, set a page attribute:
<%@ Page language="c#" ClientTarget="downlevel " Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="Validation04.WebForm1" %>
This directive will cause the validation to happen on the server even if your browser would have supported DHTML and client-side validation.
ASP.NET supports the following validation controls:
In the remainder of this chapter, we'll examine how to use each of these controls to validate data in ASP.NET applications.