Data Validation

In this section, I talk about data validation in ASP.NET. ASP.NET provides a group of validation controls that will make your job as a Web Forms developer much easier. These controls easily handle the task of data validation in form elements, and provide a consistent programming model for developers.

When do you need data validation in an HTML form? Any time you need to ensure that the user data is either present or in a specific format. For instance, if you are asking the user to enter an e-mail address, and he types XYZ, that is not a valid e-mail address. The user might have purposely entered an invalid e-mail address, or he might have inadvertently entered it. If the e-mail address is not valid, your database will contain an invalid e-mail address. If, for example, you have to notify users via e-mail of upcoming events, this invalid address will cause a problem.

The problem becomes even worse when users enter invalid data, that data is put in your database, and some sort of ODBC error or ADO error is generated. Then you have to handle the database error, which adds a lot of extra code. Of course, many applications don't even handle the database errors correctly. If you surf the Internet, you can see that they don't, by the SQL errors that are displayed on many Web pages.

Data validation has two types. The first type is client-side data validation, and the second is server-side data validation. Both are valuable techniques, and they both have their place.

Client-side validation happens inside the browser. Before a form is submitted back to the server, a piece of client-side script looks at the data and decides whether it is valid. Before the release of ASP.NET, the developer would write the JavaScript, which had to evaluate the data to ensure it was correctly evaluated. For years, developers have been writing such script as they create robust Web applications. Unfortunately, though, they end up writing the same code over and over and over again, which is a very inefficient way to go about developing Web applications. Now you might say, "Well, they can simply reuse the same code as they create new forms that need data to be validated." Yes, that is true, but many times the code must be altered for a slightly different situation. To be able to do this without having to drop down and write some JavaScript code that validates data would be much nicer.

And as a matter of fact, the ASP.NET validation controls automatically generate the client-side JavaScript code that does data validation. Developers don't even have to think about JavaScript; all they have to do is set the ASP.NET data-validation-control properties to validate the data in the way that they want.

The other type of data validation is server-side validation. With server-side validation, data validation code is executed on the server. For server-side data validation to be accomplished, the form must be submitted to the server first. Then the code is executed on the server side for validation. Server-side validation is not a new thing it is being done every day in most Web applications. Forms are submitted; some code looks at the data; and then a decision is made about whether or not the data is valid. If the data is valid, the form continues to be processed. But for each Web application, a developer must decide how invalid data is to be handled and how to notify the user that the data has some sort of error. As in the client-side validation, a lot of duplicated work goes on here. Developers tend to reinvent the wheel over and over and over again. Even though they might be able to copy code they have used in the past into their new projects, they still end up doing work they could avoid if there were some easy and unified way to take care of server-side data validation.

It is important to note that a good application needs both client-side and server-side data validation. On the client side, you want to make sure that data is valid before the form is submitted to the server that the client-side code catches the error in the data before the form is submitted. This insurance cuts down on the amount of traffic to and from the server. But a client-side-only approach has some inherent problems. One problem might be that users could figure out how to get around the problem. They might even create their own form code and submit code to your server side that defeats your entire data-validation scheme. So you should use both client-side and server-side data validation, to ensure that the data you get is valid. Any client-side validation should be duplicated on the server. The only reason to do client-side validation is to save round trips (to cover the 99.9 percent of the cases). For the other 0.1 percent, those who have malicious intent, server-side validation is also required

RequiredFieldValidator

What if I just want to make sure that users have typed something in the editable text field? To evaluate whether their names are actually valid names is going to be difficult. But I do want to make sure they have at least typed something in. For these situations, ASP.NET provides the RequiredFieldValidator control. To use this control for my application, all I do is drag it from the Toolbox onto the form, then edit its properties so that the ControlToValidate property is set to the Web Forms control that must be validated.

If I run my application now, and I submit with nothing in the editable field, I get a message in red text saying RequiredFieldValidator. If I type something in the editable field, then I do not get that message. Actually, for this message to come up with the text RequiredFieldValidator to alert the user of some sort of an error is not very user friendly. Instead, I should edit the ErrorMessage field so the user gets something a lot more meaningful. If I take a look at the RequiredFieldValidator's properties, I will see an ErrorMessage property. To change the ErrorMessage, I simply edit this to something that is more suitable to my application. Now, when I run my application and don't have anything in the editable field, I see a more user-friendly message.

You should pay attention to one other very important property for these validation controls. That property is the Display property, which indicates whether the ErrorMessage of the control should occupy space when it is not visible. ASP.NET also gives you further control so that you can determine from anywhere in your ASP code whether the fields in your page are valid. The Page class maintains a list of all the validation controls. Each validation control implements its own interface that does the validation. But the most important of these interfaces is the IsValid property. The IsValid property determines the validity of any given validator control on the page. When you look at the page's IsValid property, it returns True if all fields on the page are valid and False if any are invalid. This property gives you a great way to programmatically determine whether any of the fields are invalid. Doing this might be important so that you can catch data-validation errors even before the validation controls take over and display warnings or error messages to the user. The following code shows how easy it is to determine whether the validation controls in a page are valid:

C#

 if( IsValid ) {     Label2.Text = "Page fields are all valid."; } else {     Label2.Text = "Page fields are not all valid."; } 

VB

 If IsValid Then     Label2.Text = "Page fields are all valid." Else     Label2.Text = "Page fields are not all valid." End If 

Server-side data validation occurs during a post-back sequence. The validation is done immediately before the page load event is fired. But client-side validation is normally used because it is always implemented on up-level browsers. That is, if a Web Form validation control detects that a browser is capable of handling the JavaScript code necessary for client-side validation, the HTML that is emitted will contain the client-side validation.

Other Validation Controls

ASP.NET offers more validation controls than the one we have already talked about, the RequiredFieldValidator. It offers in addition the ValidationSummary, the CompareValidator, the RangeValidator, the RegularExpressionValidator, and the CustomValidator controls. The ValidationSummary control is used to display a summary of all the ErrorMessages on a given form. So if you want to somehow summarize for the user the data-validation errors that have occurred in a form, you could use the ValidationSummary control. The CompareValidator control is used to compare the value of one field to another field. The RangeValidator control is used to verify that the field value falls within a given range. For instance, if you are asking a user for some sort of number that falls between the values of 5 and 25, the RangeValidator control verifies that the value the user typed is truly in this range. The RegularExpressionValidator might be the most powerful of all validation controls. This control can use regular expressions to verify the contents of a field. And last, the CustomValidator control is used to build your own validation algorithm on the client side, in case even regular expressions are not enough.