Professional ASP.NET 3.5 in C# and Visual Basic Part 25 pps

Evjen c04.tex V2 - 01/28/2008 12:45pm Page 194
Chapter 4: Validation Server Controls
As you work through this chapter, you see the different types of validation rules that you can apply to
your form elements. Remember that you have no way to validate the truthfulness of the information you
collect; instead, you apply rules that respond to such questions as
❑ Is something entered in the text box?
❑ Is the data entered in the text box in the form of an e-mail address?
Notice from these questions that you can apply more than a single validation rule to an HTML form
element (you’ll see examples of this later in this chapter). In fact, you can apply as many rules to a single
element as you want. Applying more rules to elements increases the strictness of the validation applied
to the data.
Just remember that data collection on the Internet is one of the Internet’s most important features, so you
must make sure that the data you collect has value and meaning. You ensure this by eliminating any
chance that the information collected does not abide by the rules you outline.
Client-Side versus Ser ver-Side Validation
If you are new to Web application development, you might not be aware of the difference between
client-side and server-side validation. Suppose that the end user clicks the Submit button on a form after
filling out some information. What happens in ASP.NET is that this form is packaged in a request and
sent to the server where the application resides. At this point in the request/response cycle, you can run
validation checks on the information submitted. If you do this, it is called server-side validation because it
occurs on the server.
On the other hand, it is also possible to supply a script (usually in the form of JavaScript) in the page
that is posted to the end user’s browser to perform validations on the data entered in the form before the
form is posted back to the originating server. If this is the case, client-side validation has occurred.
Both types of validation have their pros and cons. Active Server Pages 2.0/3.0 developers (from the
classic ASP days) are quite aware of these pros and cons because they have probably performed all
the validation chores themselves. Many developers spent a considerable amount of their classic ASP
programming days coding various validation techniques for performance and security.
Client-side validation is quick and responsive for the end user. It is something end users expect of the
forms that they work with. If something is wrong with the form, using client-side validation ensures
that the end user knows this as soon as possible. Client-side validation also pushes the processing power

required of validation to the client meaning that you don’t need to spin CPU cycles on the server to
process the same information because the client can do the work for you.
With this said, client-side validation is the more insecure form of validation. When a page is generated in
an end user’s browser, this end user can look at the code of the page quite easily (simply by right-clicking
his mouse in the browser and selecting View Code). When he does this, in addition to seeing the HTML
code for the page, he can also see all the JavaScript that is associated with the page. If you are validating
your form client-side, it doesn’t take much for the crafty hacker to repost a form (containing the values
he wants in it) to your server as valid. There are also the cases in which clients have simply disabled the
client-scripting capabilities in their browsers — thereby making your validations useless.
194
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 195
Chapter 4: Validation Server Controls
Therefore, client-side validation should be considered a convenience and a courtesy to the end user and
never as a security mechanism.
The more secure form of validation is server-side validation. Server-side validation means that the
validation checks are performed on the server instead of on the client. It is more secure because these
checks cannot be easily bypassed. Instead, the form data values are checked using server code (C# or VB)
on the server. If the form isn’t valid, the page is posted back to the client as invalid. Although it is more
secure, server-side validation can be slow. It is sluggish simply because the page has to be posted to a
remote location and checked. Your end user might not be the happiest surfer in the world if, after waiting
20 seconds for a form to post, he is told his e-mail address isn’t in the correct format.
So what is the correct path? Well, actually, both! The best approach is always to perform client-side
validation first and then, after the form passes and is posted to the server, to perform the validation
checks again using server-side validation. This approach provides the best of both worlds. It is secure
because hackers can’t simply bypass the validation. They may bypass the client-side validation, but
they quickly find that their form data is checked once again on the server after it is posted. This vali-
dation technique is also highly effective — giving you both the quickness and snappiness of client-side
validation.
ASP.NET Validation Server Controls
In the classic ASP days, developers could spend a great deal of their time dealing with different form

validation schemes. For this reason, with the initial release of ASP.NET, the ASP.NET team introduced a
series of validation server controls meant to make it a snap to implement sound validation for forms.
ASP.NET not only introduces form validations as server controls, but it also makes these controls rather
smart. As stated earlier, one of the tasks of classic ASP developers was to determine where to perform
form validation — either on the client or on the server. The ASP.NET validation server controls eliminate
this dilemma because ASP.NET performs browser detection when generating the ASP.NET page and
makes decisions based on the information it gleans.
This means that if the browser can support the JavaScript that ASP.NET can send its way, the validation
occurs on the client-side. If the client cannot support the JavaScript meant for client-side validation, this
JavaScript is omitted and the validation occurs on the server.
The best part about this scenario is that even if client-side validation is initiated on a page, ASP.NET
still performs the server-side validation when it receives the submitted page, thereby ensuring security
won’t be compromised. This decisive nature of the validation server controls means that you can build
your ASP.NET Web pages to be the best they can possibly be — rather than dumbing-down your Web
applications for the lowest common denominator.
Presently, six validation controls are available to you in ASP.NET 3.5. No new validation server controls
have been added to ASP.NET since the initial release of the technology, but ASP.NET 2.0 introduced
some new features, such as validation groups and new JavaScript capabilities. Both these features are
discussed in this chapter. The available validation server controls include
❑ RequiredFieldValidator
❑ CompareValidator
195
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 196
Chapter 4: Validation Server Controls
❑ RangeValidator
❑ RegularExpressionValidator
❑ CustomValidator
❑ ValidationSummary
Working with ASP.NET validation server controls is no different from working with any other ASP.NET
server control. Each of these controls allows you to drag and drop it onto a design surface or to work

with it directly from the code of your ASP.NET page. These controls can also be modified so that they
appear exactly as you wish — ensuring the visual uniqueness that your applications might require. You
see some aspects of this throughout this chapter.
If the ASP.NET Validation controls don’t meet your needs, you can certainly write
your own custom validation controls. However, there are third-party controls
available such as Peter Blum’s Validation and More (VAM) from
www.peterblum.com/VAM
, which includes over 40 ASP.NET validation controls.
The following table describes the functionality of each of the available validation server controls.
Validation Server C ontrol Description
RequiredFieldValidator Ensures that the user does not skip a form entry field.
CompareValidator Allows for comparisons between the user’s input and another
item using a comparison operator (equals, greater than, less than,
and so on).
RangeValidator Checks the user’s input based upon a lower- and upper-level
range of numbers or characters.
RegularExpressionValidator Checks that the user’s entry matches a pattern defined by a
regular expression. This is a good control to use to check e-mail
addresses and phone numbers.
CustomValidator Checks the user’s entry using custom-coded validation logic.
ValidationSummary Displays all the error messages from the validators in one specific
spot on the page.
Validation Causes
Validation doesn’t just happen; it occurs in response to an event. In most cases, it is a button click event.
The Button, LinkButton, and ImageButton server controls all have the capability to cause a page’s form
validation to initiate. This is the default behavior. Dragging and dropping a Button server control onto
your form will give you the following initial result:
<
asp:Button ID="Button1" Runat="server" Text="Button" /
>

196
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 197
Chapter 4: Validation Server Controls
If you look through the properties of the Button control, you can see that the
CausesValidation
property
is set to
True
. As stated, this is the default behavior — all buttons on the page, no matter how many there
are, cause the form validation to fire.
If you have multiple buttons on an ASP.NET page, and you don’t want each and every button to initiate
the form validation, you can set the
CausesValidation
property to
False
for all the buttons you want to
ignore the validation process (for example, a form’s Cancel button):
<
asp:Button ID="Button1" Runat="server" Text="Cancel" CausesValidation="False" /
>
The RequiredFieldValidator Server Control
The RequiredFieldValidator control simply checks to see if something was entered into the HTML
form element. It is a simple validation control, but it is one of the most frequently used. You must
have a RequiredFieldValidator control for each form element on which you wish to enforce a
value-required rule.
Listing 4-1 shows a simple use of the RequiredFieldValidator control.
Listing 4-1: A simple use of the RequiredFieldValidator server control
VB
<
%@ Page Language="VB" %

>
<
script runat="server"
>
Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs)
If Page.IsValid Then
Label1.Text = "Page is valid!"
End If
End Sub
<
/script
>
<
html xmlns=" />>
<
head runat="server"
>
<
title
>
RequiredFieldValidator
<
/title
>
<
/head
>
<
body
>

<
form id="form1" runat="server"
>
<
div
>
<
asp:TextBox ID="TextBox1" Runat="server"
><
/asp:TextBox
>
<
asp:RequiredFieldValidator ID="RequiredFieldValidator1"
Runat="server" Text="Required!" ControlToValidate="TextBox1"
>
<
/asp:RequiredFieldValidator
>
<
br /
>
<
asp:Button ID="Button1" Runat="server" Text="Submit"
OnClick="Button1_Click" /
>
<
br /
>
<
br /

>
<
asp:Label ID="Label1" Runat="server"
><
/asp:Label
>
Continued
197
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 198
Chapter 4: Validation Server Controls
<
/div
>
<
/form
>
<
/body
>
<
/html
>
C#
<
%@ Page Language="C#" %
>
<
script runat="server"
>
protected void Button1_Click(Object sender, EventArgs e) {

if (Page.IsValid) {
Label1.Text = "Page is valid!";
}
}
<
/script
>
Build and run this page. You are then presented with a simple text box and button on the page. Don’t
enter any value inside the text box, and click the Submit button. The result is shown in Figure 4-1.
Figure 4-1
Now look at the code from this example. First, nothing is different about the TextBox, Button, or Label
controls. They are constructed just as they would be if you were not using any type of form validation.
This page does contain a simple RequiredFieldValidator control, however. Several properties of this
control are especially notable because you will use them in most of the validation server controls
you create.
The first property to look at is the
Text
property. This property is the value that is shown to the end user
via the Web page if the validation fails. In this case, it is a simple
Required!
string. The second property
to look at is the
ControlToValidate
property. This property is used to make an association between this
validation server control and the ASP.NET form element that requires the validation. In this case, the
value specifies the only element in the form — the text box.
As you can see from this example, the error message is constructed from an attribute within the
<
asp:RequiredFieldValidator
> control. You can also accomplish this same task by using the

Text
attribute, as shown in Listing 4-2.
198
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 199
Chapter 4: Validation Server Controls
Listing 4-2: Using the Text attribute
<
asp:RequiredFieldValidator ID="RequiredFieldValidator1"
Runat="server" Text="Required!" ControlToValidate="TextBox1"
>
<
/asp:RequiredFieldValidator
>
You can also express this error message between the <
asp:RequiredFieldValidator
> opening and
closing nodes, as shown in Listing 4-3.
Listing 4-3: Placing values between nodes
<
asp:RequiredFieldValidator ID="RequiredFieldValidator1"
Runat="server" ControlToValidate="TextBox1"
>
Required!
<
/asp:RequiredFieldValidator
>
Looking at the Results Generated
Again, the RequiredFieldValidator control uses client-side validation if the browser allows for such an
action. You can see the client-side validation for yourself (if your browser allows for this) by right-clicking
on the page and selecting View Source from the menu. In the page code, you see the JavaScript shown in

Listing 4-4.
Listing 4-4: The generated JavaScript
page markup removed for clarity here
<
script type="text/javascript"
>
<
!
function WebForm_OnSubmit() {
if (ValidatorOnSubmit() == false) return false;
return true;
}
//
>
<
/script
>
page markup removed for clarity here
<
script type="text/javascript"
>
<
!
var Page_Validators = new
Array(document.getElementById("RequiredFieldValidator1"));//
>
<
/script
>
<

script type="text/javascript"
>
<
!
var RequiredFieldValidator1 = document.all ?
document.all["RequiredFieldValidator1"] :
document.getElementById("RequiredFieldValidator1");
Continued
199
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 200
Chapter 4: Validation Server Controls
RequiredFieldValidator1.controltovalidate = "TextBox1";
RequiredFieldValidator1.text = "Required!";
RequiredFieldValidator1.evaluationfunction =
"RequiredFieldValidatorEvaluateIsValid";
RequiredFieldValidator1.initialvalue = "";
//
>
<
/script
>
page markup removed for clarity here
<
script type="text/javascript"
>
<
!
var Page_ValidationActive = false;
if (typeof(ValidatorOnLoad) == "function") {
ValidatorOnLoad();

}
function ValidatorOnSubmit() {
if (Page_ValidationActive) {
return ValidatorCommonOnSubmit();
}
else {
return true;
}
}
//
>
<
/script
>
In the page code, you may also notice some changes to the form elements (the former server controls)
that deal with the submission of the form and the associated validation requirements.
Using the InitialValue Property
Another important property when working with the RequireFieldValidator control is the
Initial-
Value
property. Sometimes you have form elements that are populated with some default properties
(for example, from a data store), and these form elements might present the end user with values that
require changes before the form can be submitted to the server.
When using the
InitialValue
property, you specify to the RequiredFieldValidator control the initial
text of the element. The end user is then required to change that text value before he can submit the form.
Listing 4-5 shows an example of using this property.
Listing 4-5: Working with the InitialValue property
<

asp:TextBox ID="TextBox1" Runat="server"
>
My Initial Value
<
/asp:TextBox
>
&nbsp;
<
asp:RequiredFieldValidator ID="RequiredFieldValidator1"
Runat="server" Text="Please change the value of the textbox!"
ControlToValidate="TextBox1" InitialValue="My Initial Value"
>
<
/asp:RequiredFieldValidator
>
200
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 201
Chapter 4: Validation Server Controls
In this case, you can see that the
InitialValue
property contains a value of
My Initial Value
.When
the page is built and run, the text box contains this value as well. The RequiredFieldValidator control
requires a change in this value for the page to be considered valid.
Disallowing Blank Entries and Requiring Changes at the Same T ime
In the preceding example of the use of the
InitialValue
property, an interesting problem arises. First, if
you run the associated example, one thing the end user can do to get past the form validation is to submit

the page with no value entered in this particular text box. A blank text box does not fire a validation error
because the RequiredFieldValidator control is now reconstructed to force the end user only to change the
default value of the text box (which he did when he removed the old value). When you reconstruct
the RequiredFieldValidator control in this manner, nothing in the validation rule requires that something
be entered in the text box — just that the initial value be changed. It is possible for the user to completely
bypass the form validation process by just removing anything entered in this text box.
There is a way around this, however, and it goes back to what we were saying earlier about how a form
is made up of multiple validation rules — some of which are assigned to the same form element. To
both require a change to the initial value of the text box and to disallow a blank entry (thereby mak-
ing the element a required element), you must put an additional RequiredFieldValidator control on
the page. This second RequiredFieldValidator control is associated with the same text box as the first
RequiredFieldValidator control. This is illustrated in the example shown in Listing 4-6.
Listing 4-6: Using two RequiredFieldValidator controls for one form element
<
asp:TextBox ID="TextBox1" Runat="server"
>
My Initial Value
<
/asp:TextBox
>
&nbsp;
<
asp:RequiredFieldValidator ID="RequiredFieldValidator1" Runat="server"
Text="Please change value" ControlToValidate="TextBox1"
InitialValue="My Initial Value"
><
/asp:RequiredFieldValidator
>
<
asp:RequiredFieldValidator ID="RequiredFieldValidator2" Runat="server"

Text="Do not leave empty" ControlToValidate="TextBox1"
>
<
/asp:RequiredFieldValidator
>
In this example, you can see that the text box does indeed have two RequiredFieldValidator controls
associated with it. The first,
RequiredFieldValidator1
, requires a change to the default value of the
text box through the use of the
InitialValue
property. The second RequiredFieldValidator control,
RequiredFieldValidator2
, simply makes the
TextBox1
control a form element that requires a value.
You get the behavior you want by applying two validation rules to a single form element.
Validating Drop-Down Lists with the RequiredFieldValidator Control
So far, you have seen a lot of examples of using the RequiredFieldValidator control with a series of text
boxes, but you can just as easily use this validation control with other form elements as well.
For example, you can use the RequiredFieldValidator control with an
<
asp:DropDownList
> server
control. To see this, suppose that you have a drop-down list that requires the end user to select her
profession from a list of items. The first line of the drop-down list includes instructions to the end user
about what to select, and you want to make this a required form element as well. The code to do this is
shown in Listing 4-7.
201
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 202

Chapter 4: Validation Server Controls
Listing 4-7: Drop-down list validations
<
asp:DropDownList id="DropDownList1" runat="server"
>
<
asp:ListItem Selected="True"
>
Select a profession
<
/asp:ListItem
>
<
asp:ListItem
>
Programmer
<
/asp:ListItem
>
<
asp:ListItem
>
Lawyer
<
/asp:ListItem
>
<
asp:ListItem
>
Doctor

<
/asp:ListItem
>
<
asp:ListItem
>
Artist
<
/asp:ListItem
>
<
/asp:DropDownList
>
&nbsp;
<
asp:RequiredFieldValidator id="RequiredFieldValidator1"
runat="server" Text="Please make a selection"
ControlToValidate="DropDownList1"
InitialValue="Select a profession"
>
<
/asp:RequiredFieldValidator
>
Just as when you work with the text box, the RequiredFieldValidator control in this example associates
itself with the DropDownList control using the
ControlToValidate
property. The drop-down list to
which the validation control is bound has an initial value —
Select a profession
. You obviously don’t

want your end user to retain that value when she posts the form back to the server. So again, you use
the
InitialValue
property of the RequiredFieldValidator control. The value of this property is assigned
to the initial selected value of the drop-down list. This forces the end user to select one of the provided
professions in the drop-down list before she is able to post the form.
The CompareValidator Server Control
The CompareValidator control allows you to make comparisons between two form elements as well as
to compare values contained within form elements to constants that you specify. For instance, you can
specify that a form element’s value must be an integer and greater than a specified number. You can also
state that values must be strings, dates, or other data types that are at your disposal.
Validating Against Other Controls
One of the more common ways of using the CompareValidator control is to make a comparison between
two form elements. For example, suppose that you have an application that requires users to have pass-
words in order to access the site. You create one text box asking for the user’s password and a second text
box that asks the user to confirm the password. Because the text box is in password mode, the end user
cannot see what she is typing — just the number of characters that she has typed. To reduce the chances
of the end user mistyping her password and inputting this incorrect password into the system, you ask
her to confirm the password. After the form is input into the system, you simply have to make a com-
parison between the two text boxes to see if they match. If they match, it is likely that the end user typed
the password correctly, and you can input the password choice into the system. If the two text boxes
do not match, you want the form to be invalid. The following example, in Listing 4-8, demonstrates this
situation.
Listing 4-8: Using the CompareValidator to test values against other control v alues
VB
<
%@ Page Language="VB" %
>
<
script runat="server"

>
202
Evjen c04.tex V2 - 01/28/2008 12:45pm Page 203
Chapter 4: Validation Server Controls
Protected Sub Button1_Click(sender As Object, e As EventArgs)
If Page.IsValid Then
Label1.Text = "Passwords match"
End If
End Sub
<
/script
>
<
html xmlns=" />>
<
head runat="server"
>
<
title
>
CompareFieldValidator
<
/title
>
<
/head
>
<
body
>

<
form runat="server" id="Form1"
>
<
p
>
Password
<
br
>
<
asp:TextBox ID="TextBox1" Runat="server"
TextMode="Password"
><
/asp:TextBox
>
&nbsp;
<
asp:CompareValidator ID="CompareValidator1"
Runat="server" Text="Passwords do not match!"
ControlToValidate="TextBox2"
ControlToCompare="TextBox1"
><
/asp:CompareValidator
>
<
/p
>
<
p

>
Confirm Password
<
br
>
<
asp:TextBox ID="TextBox2" Runat="server"
TextMode="Password"
><
/asp:TextBox
>
<
/p
>
<
p
>
<
asp:Button ID="Button1" OnClick="Button1_Click"
Runat="server" Text="Login"
><
/asp:Button
>
<
/p
>
<
p
>
<

asp:Label ID="Label1" Runat="server"
><
/asp:Label
>
<
/p
>
<
/form
>
<
/body
>
<
/html
>
C#
<
%@ Page Language="C#" %
>
<
script runat="server"
>
protected void Button1_Click(Object sender, EventArgs e) {
if (Page.IsValid)
Label1.Text = "Passwords match";
}
<
/script
>

Looking at the CompareValidator control on the form, you can see that it is similar to the Required-
FieldValidator control. The CompareValidator control has a property called
ControlToValidate
that
203