Anthony Moore
Microsoft Corporation
October 2000
Introduction
This article explains in detail the work mode of the ASP verification control. If you want to generate a complex page containing the verification control, or to extend the verification framework, it is recommended that you read this article. If you want to learn to use the verification control, or to decide whether to use the verification control, see "User Enter Validation in ASP ".
getting Started
We know that it is very important to understand verification throughout the ASP development process. Take a look at most commercial web sites, you will find that there are many forms in these sites, which is obvious to perform verification by performing a large number of handwritten code. Writing a verification code is not an interesting job. If you want to display a data sheet or a dynamically generated chart by writing code, it may be attractive, but no one can confirm that this very "cool" method can prohibit you in the name field.
For other reasons, the verification of web applications is also very troublesome. HTML 3.2 is much limited to the content you can control or can be limited from the feedback, so you cannot use the skills you can use in more fully functions, such as prohibiting users from entering certain characters, or emitting a beep. Using a browser script may produce more powerful verification. But this method is hard to confirm because the customer browser is not necessarily a script, and the malicious user can bypass. Therefore, in order to ensure the safety of the site, it is necessary to perform the same check on the server.
When developing ASP , our original intention is to use only one control to handle verification, which may be a TextBox control that can display errors. However, when designing the control, it is found that this aspiration cannot be achieved. We have studied a large number of data input forms, trying to find a solution that can be applied to the form as possible. We found that the data input form has many interesting features:
Although error messages or icons are often adjacent to the input elements, they are almost always located in different cells. There will often be a region in the page to summarize all errors. Many sites contain client scripts to provide faster feedback while preventing circulatory and trip between white places. Many sites containing client scripts will display an information box when an error occurs. Not only will the text input, but also verify the drop-down list and the radio button. If a field is empty, the site usually displays different information or icons when the entry is invalid. Many effectiveness checks can replace common expressions well. Verification is usually based on two inputs between the two inputs. 90% or more verification tasks is some common operations, such as check names or postal codes. Most sites seem to still be repeated. Because the difference between the site is usually too big, a perfect solution cannot be obtained to handle all verification tasks for each site.
Considering all of the above situations, the final solution considers five verifier controls, validationsummary controls, and integration with the Page object. At the same time, it is obvious that the solution needs to be extended, and there is an API to cooperate on the client and server.
We find that we seem to need a larger toolbox when we have verified. In most component environments, such as Microsoft® ActiveX®, we may have tried to integrate all validation controls into a control, handle different properties in different modes. However, fortunately, there is a magical inheritance in the Microsoft® .NET framework, you can provide a set of controls to perform specific validations for specific properties, because the extra workload required to derive each new control is very small.
Most of these controls are implemented in their public parent basevaliDator. You can also derive from BasevaliDator or other controls to complete your work. In fact, even if the basevaliDator is too lazy to implement its own text attribute, it is inherited from the Label property. What happened?
Understanding the event sequence is very effective when processing the page containing the verification web control. If a verification condition is optional, you need to accurately understand when verification on the client and server. If you want to write a verification routine you, it may be very time consuming, or some side effects. At the same time, it is also important to understand the timing of the call verification routine.
First, let's take a look at the server.
Server-side verification sequence
It is very important to understand the validity of the page. If you are accustomed to handling your form in a Visual Basic or a fully fully equipped client tool, you need to take a certain time to understand. All objects on the pages and pages are not effective when interacting with the user, although sometimes it is like this.
The following is a simplified event sequence when accessing a page for the first time:
Create a page and its controls based on an ASPX file. Trigger the Page_Load event. The page and control properties are saved in a hidden field. Pages and controls are converted to HTML. Discard all content.
Now, when a user clicks a button or similar control, the server will return, and then perform a similar event sequence. This sequence is called a returned sequence:
Create a page and its controls based on an ASPX file. Recover the page and control properties from the hidden field. Input update page controls according to user input. Trigger the Page_Load event. Trigger a change notification event. The page and control properties are saved in a hidden field. Pages and controls are converted to HTML. Discard all content again.
Why don't we keep all objects in memory? Because the Web site created using the ASP cannot handle the number of users. Therefore, only the contents of the server will be processed immediately.
When is server-side verification? When you get the page information for the first time, you will not perform server-side authentication. Most end users are very serious, we allow users to confirm that the information fill in in the form is correct, then we will use the red text to notify the user to fill in the wrong information.
In the return event sequence, verification is performed between steps 3 and 4. That is to say, verification is after being replaced by the data from the user, but before most of the code executes. This means that you can usually take advantage of the verified verification when writing user event code. In general, you will want to do this.
The disadvantage of verifying at this moment is that if you want to modify some properties that affect the verification by programming, this moment is too late. For example, you will find that any impact will not be seen if the verification control is enabled or disabled by writing code or change the properties of the validation control. This problem can be avoided by two ways:
Modify the properties before verify. Re-authenticate the control after the attribute changes.
Both of these methods require valid verification properties and methods on the PAGE object.
Page API
Page objects contain some important properties and methods related to server-side verification. These properties and methods are summarized in Table 1:
Table 1. Properties and methods of Page object
Properties or Method Description IsValid properties This is the most useful properties. This property can check if the entire form is valid. This check is usually performed before updating the database. Only all objects in the Validators set are all valid, this property is true and does not store this value into the cache. Validators Property This page All validation objects are set. This is a collection of objects that implement the IVALIDATOR interface. Validate method is called when verifying. The default execution method on the PAGE object is to each validator and require each verifier to evaluate it.
Validators collection is very useful for many tasks. This collection is a collection of objects that implement the Ivalidator interface. The word used to use the object, not using the control, because the Page object only follows the iValidator interface. Since all verifiers are usually used to implement some visual controls for IValidator, anyone should be able to use any verification object and add the verification object to the page. The iValidator interface contains the following properties and methods:
Table 2. Attributes and methods of the iValidator interface
Properties or Method Description IsValid Attribute indicates whether the validity check of separate verification objects is passed. You can change this value after verifying. ErrorMessage Attributes This section describes the errors to authenticate and the error that may be displayed to the user. The Validate method performs a validity check for verification objects to update its IsValid value.
You can use this interface to perform some interesting tasks. For example, to reset the page to a valid state, use the following code (as shown in the example in C #):
Ivalidator Val;
Foreach (Val in Validators) {
Val.issalid = True;
}
To re-execute the entire verification sequence, use the following code:
Ivalidator Val;
Foreach (Val in Validators) {
Val.validate ();
}
If there is a beta version 1 or higher, you can only call the validate method for the Page object, which can complete the same task. To make some changes before verification, you can override the validate method. This example shows a page containing the validator, where the validator is open or closed according to the value of the check box:
Public class conditional: Page {
Public HTMLINPUTCHECKBOX CHKSAMEAS;
Public RequiredfieldValidator Rfvalshipaddress;
protected override void validate () {
// only check the delivery address (if the payment address is different)
Bool enableship =! chksameas.checked;
Rfvalshipaddress.enabled = enableship;
/ / Now verify
Base.validate ();
}
}
Client verification
If your page enables client authentication, a completely different event sequence occurs during the round-trip process. The client's verification is implemented using the client JScript®. Realizing this verification does not require any binary components.
Although the standardization of JScript language is well done, the document object model (DOCUMENT MODEL, DOM) for HTML document interaction with the browser is not widely used. Therefore, the client's verification is only performed in Internet Explorer 4.0 and later because the validated object is Internet Explorer DOM.
From the server's point of view, the client's verification means that the verification control will be sent to the HTML. In addition, its event sequence is exactly the same. The server check is still executed. Despite it seems to be redundant, it is very important because:
Some verification controls may not support client scripts. There is a good example: If you want to use the CustomValidator and server authentication functions, there is no client verification function. Safety precautions. Some people can easily get a page containing scripts and disable or change the page. You should not use scripts to prevent bad data from entering your system, but should only be faster than users. Therefore, if you want to use CustomValidator, you should not provide a client verification function without the corresponding server verification function. Each verification control ensures that a standard client script block is sent to the page. In fact, this is just a small piece of code that contains references to code in the script WebuiValidation.js. This script library file contains all logic of client authentication, which is available separately, and can be stored in the browser's cache.
About script library
Because the Web Control Script is in the script library, you don't have to send all the client authenticated code directly to the page, although it seems to be done on the surface. The main script file is quoted like this:
