Anthony Moore
Microsoft Corporation
October 2000
Summary: A detailed explanation on using ASP+ to verify web controls
Introduction
This article explains in detail how ASP+ verification controls work. If you want to generate a complex page with verification controls, or you want to extend the verification framework, you are advised to read this article. If you want to learn to use verification controls, or to decide whether to use verification controls, see "User Input Verification in ASP+ (English)".
getting Started
We know that throughout the ASP+ development process, it is important to understand verification. Looking at most commercial web sites today, you will see that there are many forms in these sites that are obviously validated by executing a lot of handwritten code. Writing verification code is not an interesting job. It might be engaging if you want to write code to display data tables or generate charts on the fly, but no one can confirm to his colleagues that this "cool" approach can forbid null values into the name field.
For other reasons, verification of web applications is also very troublesome. HTML 3.2 has many restrictions on content you can control or feedback you can get from users, so it cannot apply techniques that can be used on more fully functional clients, such as forbidding users to enter certain characters or beep. Using browser scripts may result in more powerful verification. However, this method is difficult to prove because there are not necessarily scripts in the client's browser, and malicious users can bypass it. Therefore, in order to ensure the site's security, it is necessary to perform the same inspection on the server.
When developing ASP+, our original intention was to use only one control to handle verification, which might have been a TextBox control that could display errors. But when I was designing the control, I found that this wish could not be realized. We looked at a large number of data entry forms, trying to find a solution that could work with as many forms as possible. We found that data entry forms have many interesting features:
Although error messages or icons are often adjacent to the input element, they are almost always located in different cells of the table.
There is often an area in the page to summarize all errors.
Many sites include client scripts to provide faster feedback while preventing vain from going back and forth with the server.
Many sites that contain client scripts display information boxes when errors occur.
Not only does text input validate, but also drop-down lists and radio buttons.
If a field is empty, the site will usually display a different message or icon than when the entry is invalid.
Many validity checks are good replacements for commonly used expressions.
Verification is usually based on the comparison between two inputs.
90% or more of the verification tasks are common operations such as checking names or postal codes. Most sites still seem to be doing these work repeatedly.
Because the differences between sites are often too large to obtain a perfect solution to handle all verification tasks for each site.
Taking all of the above into account, the final solution included five validator controls, the ValidationSummary control, and integration with the Page object. It is also obvious that the solution needs to be extended, and an API is needed on both the client and the server to cooperate.
We found through various validations conducted in our research that we seemed to need a larger toolbox. In most component environments, such as Microsoft® ActiveX®, we might have attempted to integrate all the functionality of the verification control into one control, handling different properties in different modes. Fortunately, however, there is magical inheritance in the Microsoft® .NET framework, which provides a set of controls to perform specific validation of specific properties, because the extra effort required to derive each new control is very small.
Most of the work done by these controls is implemented in their common parent BaseValidator. You can also derive from BaseValidator or other controls to do all the work. In fact, even BaseValidator is too lazy to implement its own Text property, but inherits from the Label property.
When and what happened?
Understanding the sequence of events is very effective when working with pages containing validation web controls. If a verification condition is optional, you need to know exactly when verification is performed on the client and server. If you want to write your own verification routine, it can be very time-consuming or have side effects. At the same time, it is also important to understand the timing of calling the verification routine.
First, let's take a look at the server.