Chapter 8. Validation


As you have seen in the preceding chapters, 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, for example, if a credit card number is entered incorrectly or an address is omitted, so it is imperative to validate user input.

Traditionally, it takes a great deal of time and effort to write reliable validation code. Each field must be checked, and routines must be created for ensuring data integrity. If bad data is found, error messages must be displayed so the user knows there is a problem and how to correct it.

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.

In addition, you usually want all of this validation to happen client side so you can avoid the delay of repeated round trips to the server while the user is tinkering with his input. In the past, this was solved by writing client-side JavaScript to validate the input, and then writing server-side script to handle input from browsers that don't support client-side programming. In addition, as a security check, you may want to do server-side validation even though you have client-side validation, since users can circumvent validation code deliberately spoofing. Traditionally, this involved writing your validation code twice, once for the client and once for the server.

As you can see, in traditional Internet programming, validation requires extensive custom programming. The ASP.NET framework simplifies this process by providing rich controls for validating user input. The validation controls allow you to specify 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.NET server controls.

You add validation controls to your ASP.NET document 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 even write your own custom validation controls 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 ultimately validated server side as well as a security measure.


Because client-side validation will prevent your server-side code from ever running if the control is invalid, you may at times, want to force server-side validation. In that case, add a ClientTarget attribute to the @Page directive:

 <%@ Page Language="C#"    AutoEventWireup="true"    CodeFile="Default.aspx.cs"    Inherits="Default_aspx"  ClientTarget="downlevel"  %> 

This directive will cause the validation to happen on the server even if your browser would have supported DHTML and client-side validation.

Sometimes you don't want any validation to occur, such as when a Cancel button is clicked. To allow this, many postback controls, such as Button , ImageButton , LinkButton , ListControl , and TextBox , have a CausesValidation property, which dictates if validation is performed on the page when the control's default event is raised.

If CausesValiation is set to true , which is the default value, the postback will not occur if any control on the page fails validation. If CausesValiation is set to false , however, no validation will occur when that button is used to post the page.

ASP.NET supports the following validation controls:



RequiredFieldValidator

Ensures the user does not skip over your input control. A RequiredFieldValidator can be tied to a text box to force input into the text box. With selection controls, such as a drop-down or radio buttons , the RequiredFieldValidator ensures the user makes a selection other than the default value you specify. The RequiredFieldVali-dator does not examine the validity of the data but only ensures that some data is entered or chosen .



RangeValidator

Ensures that the value entered is within a specified lower and upper boundary. You can check the range within a pair of numbers (greater than 10 and less than 100), a pair of characters (greater than D and less than K), or a pair of dates (after 1/1/01 and before 2/28/01).



CompareValidator

Compares the user's entry against another value. It can compare against a constant you specify at design time or against a property value of another control. It can also compare against a database value.



RegularExpressionValidator

One of the most powerful validators, it compares the user's entry with a regular expression you provide. You can use this validator to check for valid Social Security numbers, phone numbers, passwords, and so forth.



CustomValidator

If none of these controls meets your needs, you can use the CustomValidator . This checks the user's entry against whatever algorithm you provide in a custom method.

In the remainder of this chapter, we'll examine how to use each of these controls to validate data in ASP.NET applications.



Programming ASP. NET
Programming ASP.NET 3.5
ISBN: 0596529562
EAN: 2147483647
Year: 2003
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net