Server Side Validation

Validation always fires on the server—even when validation has already fired on the client. This may seem odd, considering that you may have spent a lot of time making sure the client is unable to submit invalid values, but don't let that bother you. You may want to reuse the server-side code at some point— for example, you might inherit from your Web Form, or someone might submit a different form to your page. In any case, you don't have to let the controls validate on the client—you can force them to validate only on the server by setting the Web Form's clientTarget property to DownLevel or by setting the EnableClientScript property for any specific Validation control to false. Changing the clientTarget property prevents the page from generating any client validation script; instead, the Web Form submits all the values to the server, and the controls perform their validation tasks there. Changing the EnableClientScript property to false for a Validation control prevents only that control from firing client-side validation—again, the control still validates the data on the server when the user posts the form.

In some cases where you know the clients may consist of downlevel browsers, you may have to perform validation on the server. Another reason to validate on the server is when you want to closely control the position and content of the messages that appear. You can't easily alter the client-side validation code (although I'll show you how to work around that problem), but by writing a small amount of code in the code-behind class, you can change the messages that appear very easily.

Change the validation location to the server by entering DownLevel in the document clientTarget property field. You need to click the design surface to see the document properties. Next, double-click the OK button to open up the code-behind class. Double-clicking the control creates a cmdOK_cClick method stub—this is the event that fires each time the user clicks the OK button. Add the following code to the method stub:

private void cmdOK Click(object sender, System.EventArgs e) { Page.Validate(); if (!Page.IsValid) {

foreach (BaseValidator val in Page.Validators) { if (!val.IsValid) {

Response.Write(val.ErrorMessage + "<br>");

lblErrors.Visible = true; lblErrors.Text = sb.ToString();

Congratulations. Although the result isn't pretty, you've just coded a server-side loop that validates values entered on the client—and you didn't have to find the values, assign them to variables, or write any special validation code. By setting the clientTarget property to DownLevel, you turned off VS.NET's automatic client-side validation script generation. Therefore, when the user submits the form, the values return to the server—but you use the same validation controls to check the values. As I mentioned earlier, the server-side validation always occurs—even if you don't use it.

So when or why would you want to turn off client-side validation? First, you should turn it off when the target browser is not Internet Explorer. Ideally, in some utopian future state, all browsers would be equally capable of performing dynamic HTML operations and running the same version of client script code. Unfortunately, we haven't yet reached that state. Second, you may have noticed that VS.NET translates Validator controls into HTML <span> tags. Each <span> tag defines a specified area of the browser window where the Validator control can display its error messages. But the tags are transparent; therefore, you can't stack them on top of one another unless you're sure that only one Validator control can fire at a time—and as you've seen, you can easily create a form that fires multiple validation errors when submitted. Therefore, a third reason to validate on the server is to control the way the validators display error messages. Finally, with little effort, a malevolent user could post a request directly to the server.

Note Microsoft chose to use a <span> rather than a <div> tag for the error messages because <div> tags always begin on a new line in downlevel browsers, whereas <span> tags do not necessarily begin on a new line. This lets you put the error messages on the same line as the control that contains the invalid input.

The simple example you just created writes the error messages at the top of the screen, but you can easily change that. Drag a Label control onto the Web Form and place it underneath the table. Edit the label's id property so it reads lblErrors, and set the Color property to Red, leaving the Text property blank. Next, change the code in the method so you concatenate all the error messages during the cmdOK_Click method and set the lblErrors.Text property to the concatenated string. Listing 5.4 shows the code. Finally, change the Display property for the two

RegularExpressionValidator controls to None and change their EnableClientScript property to false.

Was this article helpful?

0 0

Post a comment