In -depth explanation ASP+ verification
Anthony Moore
Microsoft Corporation
October 2000
Summary: Detailed explanations to the use of ASP+ verification web control.
Table of contents
Brief introduction
getting Started
When does it happen?
Verification sequence on the server side
Client verification
Effective rules and useful error information
ENabled, Visible and Display Properties' functions
CustomValidator control
Which controls can be verified?
End
------------------------------------------------ ----------------------------------------------------------------------------
Brief introduction
This article explains the working method of ASP+ verification control in detail. If you want to generate a complex page that contains the verification control, or to expand the verification framework, it is recommended that you read this article. If you want to learn to use the verification control or decide whether to use the verification control, see "ASP+ User Enter Verification (English)".
getting Started
We know that it is important to understand verification during the entire ASP+ development process. Look at most of today's commercial web sites, you will find that there are many forms in these sites, which are obviously executed by executing a large number of handwritten code. Writing verification code is not an interesting job. If you write a code to display the data table or dynamically generate charts, it may be very attractive, but no one can confirm with his colleagues that this "cool" method can prohibit the empty value in the name field.
For other reasons, the verification of web applications is also very troublesome. HTML 3.2 has a lot of restrictions on the content you can control or feedback that you can get from the user, so it cannot be applied to the techniques that can be used on a more fulfilling client, such as prohibiting users from entering certain characters or making a sound. Using browser script may produce more powerful verification. However, this method is difficult to confirm, because the customer's browser is not necessarily script, and malicious users can bypass it. Therefore, in order to ensure the safety of the site, it is necessary to perform the same inspection of the server.
When developing ASP+, our original intention is to use only one control to process verification. It may have been a TextBox control that can show wrong. But when it was designed, I found that this desire could not be achieved. We have researched a large number of data input forms to find a solution that can be applied to as many forms as possible. We found that the data input table has many interesting features:
Although error information or icons are often adjacent to the input elements, they are almost always located in different cells of the table.
There is often a area on the page to summarize all errors.
Many sites include client scripts to provide faster feedback while preventing traveling between the server in vain.
Many sites containing client scripts display information boxes when there is an error.
Not only will the text input be verified, but also the drop -down list and single -selection button will be verified.
If a field is empty, the site usually shows different information or icons when the entry is invalid.
Many effective examinations can be well replaced by commonly used expressions.
Verification is usually based on comparison results between two inputs.
90% or more than 90% of the verification tasks are some common operations, such as checking name or postal code. Most sites still seem to be repeating these tasks.
Because the difference between sites is usually too large, a perfect solution cannot be obtained to handle all the verification tasks of each site.
Considering all the above situations, the final solutions include five verification device controls, ValidationSummary controls, and integration with Page objects. At the same time, it is obvious that the solution needs to be expanded, and a API is needed to cooperate on the client and server.
We found that we seemed to need a larger toolbox during the various verifications of research. In most component environments, such as Microsoft® ActiveX®, we may have tried to integrate the functions of all verification controls into a control to process different attributes in different modes. Fortunately, there is magical inheritance in the Microsoft® .NET framework. It can provide a set of controls to verify specific attributes because the extra workingload required for each new control is very small.
Most of these controls are implemented in their public parent -level Basevalidator. You can also complete various tasks from Basevalidator or other controls. In fact, even if Basevalidator is too lazy to achieve its own text attributes, it is inherited from Label attributes.
When does it happen?
It is very effective to understand the event sequence when processing the page containing the page of the web control. If a verification condition is optional, you need to accurately understand when the client and server are verified. If you want to write a verification routine yourself, it may be very time -consuming or side effects. At the same time, it is also important to understand the timing of calling verification routine.
First, let's take a look at the server.
Verification sequence on the server side
It is important to understand the validity period of the page. If you are accustomed to processing the form in the Visual Basic or similar functional client tools, you need to spend a certain time to understand. All objects on the page and page are not effective when interacting with users, although sometimes this is the same.
The following is a simplified event sequence when visiting a page for the first time:
Create a page and its control based on the ASPX file.
Triggering the page_load event.
Page and control attributes are stored in a hidden field.
Pages and controls are converted to HTML.
Discard everything.
Now, when the user clicks a button or a similar control, it will return to the server and then execute a similar event sequence. This sequence is called the return sequence:
Create a page and its control based on the ASPX file.
Restore the page and control attributes from the hidden field.
Enter the update page control according to the user.
Triggering the page_load event.
Trigger changes notification events.
Page and control attributes are stored in a hidden field.
Pages and controls are converted to HTML.
Discard everything again.
Why don't we keep all objects in memory? Because web sites established with ASP+ cannot handle very large number of users. Therefore, the server's memory only retains the content to be processed immediately.
When is the server -side verification? When obtaining page information for the first time, server -side verification will not be performed at all. Most end users are very serious. We allow users to confirm whether the information filled in in the form is correct, and then we use the red text to inform the user to fill in the wrong information.
In the return event sequence, verification will be performed between step 3 and step 4. In other words, verification is after the data loading control attributes from the user, but before most of the number of code execution. This means that when writing user events, it can usually be used for verification. Under normal circumstances, you will want to do this.
The disadvantage of verification at that moment is: If you want to modify some attributes that affect the verification by programming, it will be too late. For example, you will find that if you use the code to enable or disable the attributes of the verification control or modify the verification control, you will not see any effect before processing the page. This problem can be avoided through the following two methods:
Modify the attribute before verification.
Re -verify the control after the attribute change.
Both methods need to use effective verification attributes and methods on the Page object.
Page API
Page objects include some important attributes and methods related to the server -side verification. Table 1 summarizes these attributes and methods:
Table 1. Page object's attributes and methods
Attribute or method description
The Isvalid attribute is the most useful attribute. This attribute can check whether the entire form is effective. This check is usually performed before updating the database. Only all the objects of Validators are valid, the attribute is true, and the value is not stored in the cache.
Validators attributes The collection of all verification objects of this page. This is a collection of objects that implement the IVALIDATOR interface.
The value method calls a method when verification. The default execution method on the Page object is to turn to each verification device and require the verification device to evaluate itself.
The Validators collection is very useful for many tasks. This set is a collection of objects that implement the IVALIDATOR interface. The reason why I use the object is not the control of the control because the Page object only pays attention to the Ivalidator interface. Since all the verifications are usually used to achieve some visual controls of Ivalidator, anyone should be able to use any verification object and add the verification object to the page.
Ivalidator interface contains the following attributes and methods:
Table 2. The attributes and methods of the ivalidator interface
Attribute or method description
The ISVALID attribute pointed out whether the validity test performed by a separate verification object has passed. You can manually change the value after verification.
ErrorMessage attribute introduces the error to verify the object to be verified and the errors that may be displayed to the user.
The Validate method is checked for the validity of the verification object to update its ISVALID value.
You can use this interface to perform some interesting tasks. For example, to reset the page to an effective state, use the following code (such as the example shown in C#):
Ivalidator value;
FOREACH (Val in Validators) {
valuevalid = TRUE;
}
To re -execute the entire verification sequence, use the following code:
Ivalidator value;
FOREACH (Val in Validators) {
Val.validate ();
}
If you have Beta 1 edition or higher versions, you can also call the value method only for the Page object, so that the same task can be completed. To make some changes before verification, the value method can be covered. This example shows a page containing the verification device, which is opened or off according to the value of the check box:
Public Class Conditional: Page {
public htmlinputcheckbox chksameas;
public researchFieldValidator rfvalshipaddress;
Protected Override Void Validate () {) {)
// Just check the delivery address (if different from the payment address)
BOOL Enableship =! Chksameas.checked;
rfvalshipaddress.enabled = enableship;
// Now executing verification
base.validate ();
}
}
Client verification
If your page is enabled by client verification, a completely different event sequence will occur during the round trip. The client's verification uses the client JSCRIPT®. The verification does not require any binary components.
Although the standardization of the JSCRIPT language is well done, the document object model (DOM) used in the HTML documentation in the browser (DOM) has not widely used standards. Therefore, the client verification is only performed in the Internet Explorer 4.0 and higher versions, because the verified object is the Internet Explorer DOM.
From the perspective of the server, the verification of the client only means that the verification control sends different content to HTML. In addition, the incident sequence is exactly the same. The server -side check is still performed. Although it seems redundant, it is very important because:
Some verification controls may not support the client script. There is a good example: if you want to use the CustomValidator and server verification functions at the same time, but there is no client verification function.
Safety precautions. Some people can easily get a page containing a script, and then disable or change the page. You should not use your script to prevent bad data from entering your system, but only for users to get faster feedback. Therefore, if you want to use CustomValidator, you should not provide a client verification function without corresponding server verification functions.
Each verification control can ensure that a standard client script block is sent to the page. In fact, this is just a small part of the code, which contains a reference to the code in the script library webuivalidation.js. This script library file contains all logic verified by the client. This file needs to be downloaded separately and can be stored in the cache of the browser.
About script library
Because the verification of the web control script is in the script library, the code verified by all clients is not necessary to directly send it to the page, although it seems to be done on the surface. The main script file references is similar to the following:
<script language = javascript
src =/_ASPX/1.0.9999/Script/Webuivalidation.js> </Script>
By default, the script file will be installed in the default root directory in the _ASPX directory, and uses a script Include instruction to be called, which starts with a positive diagonal line. The reference shows that each individual object does not need to include the script library, and all pages on the same computer can reference the same file. You will notice that there is also a public language version number in this path, so that different runtime versions can run on the same computer.
If you look at your default virtual root directory, you will find the file and view the content. The position of these files is specified in the config.web file. Config.web file is an XML file for most ASP+ settings. The following is the definition of the position in this file:
<webcontrols
ClientScriptsLocation =/_ ASPX/{0}/script/
/>
Encourage you to read the script so that you can understand the events that occur in depth. However, it is recommended that you do not modify these scripts, because their functions are closely linked to specific runtime versions. When the version is updated, these scripts may also need to be updated accordingly. You will give up changes, or face the problem of not working. If specific projects must be changed, first backup these scripts, and then point your project to the backup file, the method is to use a private config.web file to replace the position of these files. If the string contains the format instruction {0}, the version number will replace the instruction when the runtime version number will be replaced. It is best to change this position to a relative reference or absolute reference.
Disable client verification
Sometimes you may not want to verify clients. If the number of input fields is small, the client verification may not be very useful. After all, you have to have a logic that requires one round -trip server every time. You will find that the dynamic information on the client will have a negative impact on your layout.
To disable client verification, use the page instruction clientTarget = DOWNLEVEL. This instruction is similar to the beginning of the ASPX file:
< %@page Language = C# ClientTarget = DOWNLEVEL %>
The default value of this instruction is Auto, indicating that you only verify the client of the Microsoft Internet Explorer 4.0 or higher versions.
Note: Unfortunately, in Beta 1, this instruction is not just disabled for verification, and at the same time, all web controls use HTML 3.2 tags to process, which may have unexpected results. The final version provides a better way to control this problem.
Client event sequence
This sequence is an event sequence that occurs when the page containing the client verification:
When loading the browser on the page, you need to initialize each verification control. These controls are sent as the <span> mark, and their HTML features are closest to the features on the server. Most importantly, all input elements referenced by the verification device will be "hanged" at this time. The referenced input element will modify its client event to call the verification routine when entering the change.
The code in the script library will be executed when the user uses the TAB key to switch between each field. When a certain independent field is changed, the verification conditions will be re -evaluated, and the verification device will be visible or invisible as needed.
When the user tries to submit the form, all the verifications will be evaluated. If all these verificationrs are effective, the form will be submitted to the server. If there is an error in one or more places, the following situation will occur:
The submission was canceled. The form is not submitted to the server.
All invalid verifications are visible.
If a verification summary contains Showsummary = True, all errors from the verification control will be collected and the content is updated with these errors.
If a verification summary contains ShowmessageBox = TRUE, it will collect errors and display these errors in the client's information box.
Because the client verification control is performed when the client verification control is performed at each input change or when submitting, these verification controls are usually evaluated twice or more than twice on the client. Please note that after submission, these verification controls will still be re -evaluated on the server.