Validating the date input
lients without script, so it can be hard to justify writing it all over again for rich clients.
Validation controls change all that, because almost all the duplicated logic is encapsulated in the controls. If a client with Internet Explorer 4.0 or later uses your page, it can do the same input validation that takes place on the server without you having to write any special client script.
The client side validation has a number of features:
- Errors can appear and disappear immediately after the bad input is entered/corrected. This immediate feedback makes it much easier to correct bad input.
- Post-back is prevented if there are errors that are detectable on the client, saving the user time and reducing hits on the server.
- The ValidationSummary updates itself without posting back if it detects errors.
- The ValidationSummary can optionally display a message box to the user if there are errors.
- The client logic is all contained in a JScript library, so no ActiveX components or Java applets are used.
- An object model is exposed on the client to allow enhancement of client-side validation and behavior.
What Is a Validator?
In order to use validators effectively, it helps to have a firm definition of what they are. Let’s refine our previous definition a little:
“A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem.”
This is an important definition, because it means that you frequently need to use more than one validator control for each input control.
For example, if you want to check whether or not user input in a text box is (a) nonblank, (b) a valid date between a particular range and (c) less than the date in another text input control, you would want to use three validators. While this might seem cumbersome, remember that to be helpful to the user, you would want to have three different text descriptions for all these cases.
The different types of validators are listed as follows:
|RequiredFieldValidator||Checks that the user has entered or selected anything.|
|RegularExpressionValidator||Checks user input against a regular expression. This allows a wide variety of checks to be made and can be used for things like ZIP codes and phone numbers.|
|CompareValidator||Compares an input control to a fixed value or another input control. It can be used for password verification fields, for example. It is also possible to do typed date and number comparisons.|
|RangeValidator||Much like CompareValidator, but can check that the input is between two fixed values.|
|CustomValidator||This allows you to write your own code to take part in the validation framework.|
You have wisely chosen separate textboxes for date and time. This makes validation much easier.
You can validate a date using the CompareValidator with Operator=DataTypeCheck and Type=Date. The CultureInfo.DateTimeFormat.ShortDatePattern determines the pattern; CultureInfo.DateTimeFormat.DateSeparator is the date separator.
There are only five validator controls offered by Microsoft and so many more cases that developers have discovered. (When designing my own product, I came up with 25 separate validators to cover the many validation rules found on web pages.) Generally this means developers have to use the CustomValidator to get the job done. Before you choose that, here are a few features developers often overlook about the existing validators and the CustomValidator.
The CompareValidator can check the format of dates and numbers
Every week, I see several people asking how to validate the date entered into a textbox. Some are already looking for the right regular expression to use with the RegularExpressionValidator.
Microsoft provides a validator to do this, but they don’t make it obvious. Use the CompareValidator with its Operator property set to DataTypeCheck and its Type property set to the desired format. This works much better than regular expressions because it actually checks for a valid date number, not just a format. The regular expression couldn’t tell you that 2/31/2004 is an invalid date. This validator can.
<asp:CompareValidator id="DateValidator" runat=server Operator="DataTypeCheck" Type="Date" ControlToValidate="DateTextBox" ErrorMessage="Bad format" />
Validators support for globalization
When you accept date and numeric entries in textboxes on the web, you are working with a world-wide audience whose date and number formats differ from your server’s format.
Microsoft developed the System.Globalization.CultureInfo class to describe the formats of dates, numbers, currencies, and text. The RangeValidator and CompareValidator use this object to support globalization.
Every page has a CultureInfo object assigned to the current thread in System.Threading.Thread.CurrentThread.CurrentUICulture. It gets its value from several places:
- You may set it programmatically in Page_Load, Page_Init, or Page.InitializeCulture (ASP.NET 2.0 only) method of the page, or the Application_BeginRequest method of Global.asax.
System.Threading.Thread.CurrentThread.CurrentUICulture = System.Globalization.CultureInfo.CreateSpecificCulture("id-ID")
- You may set it in the <@ Page> declaration as the Culture property:
<%@ Page Culture="id-ID" %>
- You set it for your entire site in web.config’s <globalization> section:
<globalization culture="id-ID" />
Where I’ve used id-ID above, you should use the appropriate culture. They are listed here.
Using validators with DropDownLists and ListBoxes
Validators look at the text value of the control they are validating. DropDownLists and ListBoxes have text values. They are assigned when you add ListItems like this:
<asp:DropDownList [properties] runat="server"> <asp:ListItem Value="[here is the value]">name</asp:ListItem> </asp:DropDownList>
Use the RequiredFieldValidator to detect an item for “No Selection” like this:
1. Add an item indicating no selection to the DropDownList with a specific value, like “No Selection”:
<asp:ListItem Value="NoSelection">--- No Selection --</asp:ListItem>
2. Assign the value to the InitialValue property of the RequiredFieldValidator. For example:
<asp:RequiredFieldValidator id="RequiredFieldValidator1" runat=server ControlToValidate="DropDownList1" InitialValue="NoSelection" ErrorMessage="Required" />
Make sure the InitialValue is a case-sensitive match to the ListItem’s Value.
Use the CompareValidator to determine if a single item is selected or not selected. Just determine the value of that item and assign it to the ValueToCompare property. Then set the Operator to Equal (for selected) or NotEqual (for not selected). In this example, the ListItem whose value is “Blue” must not be selected:
<asp:compareValidator id="NotBlue" runat=server ControlToValidate="DropDownList1" ValueToCompare="Blue" Operator="NotEqual" Type="String" ErrorMessage="Do not select blue" />
Making the CustomValidator support blank textboxes
As you work with the Validator controls, you will learn that only the RequiredFieldValidator will evaluate a blank textbox. Developers who build CustomValidators often want to evaluate blank textboxes too. You can! Do not assign anything to the ControlToValidate property. Instead, write your evaluation function to get the value of the textbox directly. For example, in server-side code, if your TextBox is called TextBox1, you can get the value from TextBox1.Text.