Introduction to Data Validation in ASP.NET

There are two types of data validation: client-side data validation and server-side validation. They are both 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. Right now (before the official release of ASP.NET) the developer writes the script, which must evaluate the data to ensure it is correctly evaluated. For years , developers have done this as they create robust Web applications. Unfortunately, though, they end up writing the same code 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 ." That's true, but many times the code must be altered for a slightly different situation. It would be much nicer to do this without having to drop down and write some JavaScript code that validates data (this is no easy matter and can be painful). 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. This is data validation code that 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 ASP code looks at the data; and then a decision is made whether the data is valid. If the data is valid, the form continues on 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 there is some sort of error in the data. As in the client-side validation, there is a lot of duplicated work here. Developers tend to re-invent the wheel over and over and over again. Even though they might be able to copy code they have used into the past into their new projects, they still end up doing work that could be avoided 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 be sure that data is valid before the form is submitted to the server. The client-side code catches the error in the data before the form is submitted. This cuts down on the amount of traffic to and from the server. But there are some inherent problems to a client-side-only approach.

One problem might be that users could figure out how to get around it. They might even create their own form code and submit it, defeating your entire data validation scheme to your server side. So, you should use both client-side and server-side data validation, to ensure that the data you get is valid.

It's time now to create some simple examples to show you how the ASP.NET data validation controls work. For the first example, I am going to create a label and a text box. The label asks the user to type in a name and the text box gives them the opportunity to type it in. Then I have a Submit button for the user to click after the name has been typed. Figure 12.1 shows the simple application I have created.

Figure 12.1. This application asks for a user name.

What if I want to just be sure they have typed something in the editable text field? It is going to be hard to evaluate whether the name actually is a valid name, but I do want to be sure they have at least typed something. For these situations, ASP.NET provides the RequiredFieldValidator control. To use this for my application, all I do is drag it from the toolbox onto the form, and then edit its properties so that the ControlToValidate property is set to the Web form control that must be validated. In this case, because my editable text field has an ID of TextBox1, I will set the RequiredFieldValidator 's ControlToValidate property to TextBox1, as shown in Figure 12.2. The following code shows the RequiredFieldValidator in the aspx code:

Figure 12.2. The ControlToValidate property is set for TextBox1.

 <asp:TextBox id="TextBox1" runat="server"></asp:TextBox>  <asp:RequiredFieldValidator id="RequiredFieldValidator1" runat="server"    ErrorMessage="This is a required field!"    ControlToValidate="TextBox1"></asp:RequiredFieldValidator> 

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

Figure 12.3. This is a more user-friendly message.

There is one other very important property for these validation controls that you should pay attention to. It is the display property, and this indicates whether the ErrorMessage of the control should occupy space when it is not visible. ASP.NET also gives you further control so that from anywhere in your ASP code you can determine whether the fields in your page are valid. The page class maintains a list of all the validation controls. Each of these validation controls implements its own interface that does the validation. But the most important of these 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 gives you a great way to programmatically determine whether any of the fields are invalid. This might be important so that you can catch data validation errors even before the validation controls take over and display warning 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. Figure 12.4 shows the result of this code.

Figure 12.4. The IsValid property was used to verify data validation in all fields.

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

Server-side data validation occurs during a PostBack sequence. It is done immediately before the page load event is fired . But client-side validation normally is 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.