In-depth introduction to ASP + verification (2)

Server verification sequence

It is very important to understand the validity period of the page. If you are used to processing forms in Visual Basic or similar client tools, it takes some time to understand. All objects on pages and pages are not always valid when interacting with users, although sometimes on the surface.

The following is a simplified event sequence when a page is accessed for the first time:

Create a page and its controls based on the ASPX file.
Trigger the Page_Load event.
The page and control attributes are stored in a hidden field.
Convert pages and controls to HTML.
Discard all content.
Now, when a user clicks a button or similar control, it returns to the server and executes a similar event sequence. This sequence is called the return sequence:

Create a page and its controls based on the ASPX file.
Restore page and control properties from hidden fields.
Update the page control based on user input.
Trigger the Page_Load event.
A change notification event is triggered.
The page and control attributes are stored in a hidden field.
Convert pages and controls to HTML.
Discard all content again.
Why don't we keep all objects in the memory? The Web site created using ASP + cannot process a large number of users. Therefore, the server's memory only keeps the content to be processed immediately.

When Will server-side verification be performed? Server-side authentication is not performed at all when the page information is obtained for the first time. Most end users are very serious. We allow users to confirm whether the information entered in the form is correct, and then we use red text to notify users of the entered error information.

In the returned event sequence, verification is performed between Step 1 and step 2. That is to say, verification is performed after the data from the user is loaded back to the control property, but before most code is executed. This means that the verification that has been performed can usually be used when writing user Event code. Generally, you want to do this.

The disadvantage of verification at this time point is that if you want to program some attributes that affect the verification, it will be too late. For example, if you write code to enable or disable the verification control or change the properties of the verification control, you will not see any impact until the next page is processed. You can avoid this problem using the following two methods:

Modify attributes before verification.
Verify the control again after the property is changed.
Both methods use valid Verification attributes and methods on the Page object.

Page API

The Page object contains important attributes and methods related to server-side verification. Table 1 summarizes these attributes and methods:

Table 1. attributes and methods of the Page Object

Attribute or method description
IsValid is the most useful property. This attribute checks whether the entire form is valid. This check is usually performed before the database is updated. This attribute is true only when all objects in the Validators set are valid and this value is not stored in the cache.
Validators properties a set of all verification objects on this page. This is a collection of objects that implement the IValidator interface.
The Validate method is called during verification. On the Page object, the default execution method is to go to each validator, and each validator is required to evaluate it on its own.

The Validators set is useful for many tasks. This set is a set of objects that implement the IValidator interface. The reason why I use the word "object" instead of "control" is that the Page object only follows the IValidator interface. Since all validators are usually visual controls used to implement IValidator, anyone should be able to use any verification object and add the verification object to the page.

The IValidator Interface contains the following attributes and methods:

Table 2. IValidator interface attributes and Methods

Attribute or method description
The IsValid attribute indicates whether the validation object has passed the validity check. You can manually change the value after verification.
The ErrorMessage attribute describes the error to be verified and the error that may be displayed to the user.
The Validate method checks the validity of the verification object to update its IsValid value.

You can use this interface to execute some interesting tasks. For example, to reset the page to a valid status, use the following code (as shown in the example in C ):

IValidator val;
Foreach (val in Validators ){
Val. IsValid = true;
}

To re-execute the entire verification sequence, use the following code:

IValidator val;
Foreach (val in Validators ){
Val. Validate ();
}

If Beta 1 or later is available, you can only call the Validate method on the Page object to complete the same task. To make some changes before verification, You can override the Validate method. In this example, a page containing the validators is displayed. The validators enable or disable the validators Based on the check box values:

Public class Conditional: Page {
Public HtmlInputCheckBox chkSameAs;
Public RequiredFieldValidator rfvalShipAddress;

Protected override void Validate (){
// Only check the arrival address (if it is different from the payment address)
Bool enableShip =! ChkSameAs. Checked;
RfvalShipAddress. Enabled = enableShip;
// Verify now
Base. Validate ();
}
}