Client verification
If your page has client authentication enabled, a completely different sequence of events occurs during the round trip. Client authentication is implemented using client Jscript®. No binary components are required to implement this verification.
Although the Jscript language is well standardized, there is no widely adopted standard for the Document Object Model (DOM) used to interact with HTML documents in the browser. Therefore, client authentication is only performed in Internet Explorer 4.0 and later because the authentication object is Internet Explorer DOM.
From a server perspective, client verification only means that the verification control sends different content to HTML. Other than that, its event sequence is exactly the same. The server-side check is still executed. Although it may seem redundant, it is very important because:
Some verification controls may not support client scripts. There is a good example: if you want to use both CustomValidator and server verification functions, but there is no client verification function.
Safety precautions. Some people can easily get a page with scripts and then disable or change that page. You should not use scripts to prevent bad data from entering your system, but just to get faster feedback from 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. Actually, this is just a small part of the code that contains references to the code in the script library WebUIValidation.js. This script library file contains all the logic for client verification. The file needs to be downloaded separately and can be stored in the browser's cache.
About the script library
Because the verification web control script is in the script library, it is not necessary to send all client-verified code directly to the page, although it seems to be doing so on the surface. The main script file references look like this:
<script language="javascript"
src="/_aspx/1.0.9999/script/WebUIValidation.js"></script>
By default, the script file is installed in the default root directory in the "_aspx" directory and is called with the root-relative script include directive, which begins with a forward slash. This reference indicates that each individual object does not have to contain a script library, and all pages on the same computer can reference the same file. You will notice that there is also a common language runtime 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 contents of it. The location of these files is specified in the config.web file. The config.web file is an XML file for most ASP+ settings. The following is the definition of the location in the file:
<webcontrols
clientscriptslocation="/_aspx/{0}/script/"
/>
You are encouraged to read the script to gain insight into what happened. However, it is recommended that you do not modify these scripts, as their functionality is closely linked to specific runtime versions. When the runtime version is updated, these scripts may also require corresponding updates, and you will either abandon the changes or face the problem that the script does not work. If a specific project must change these scripts, back up the scripts first and then point your project to the backup file by replacing the location of these files with a private config.web file. If the string contains the format instruction "{0}", the runtime version number will replace the instruction. It is best to change that location to a relative or absolute reference.
Disable client authentication
Sometimes you may not want client authentication. If the number of input fields is small, client verification may be of little use. After all, you have to have a logic that needs to travel to and from the server once every time. You will find that the information that appears dynamically on the client will have a negative impact on your layout.
To disable client authentication, use the Page directive "clienttarget=downlevel". This directive is similar to the beginning of the following ASPX file:
<%@ Page Language="c#" clienttarget=downlevel %>
The default value of this directive is "auto", which means that you only perform client authentication for Microsoft Internet Explorer 4.0 or later.
Note: Unfortunately, in Beta 1, this directive does not simply disable verification, but also causes all web controls to be processed using HTML 3.2 tags, which can produce unexpected results. The final version provides a better way to control this problem.
Client event sequence
This sequence is a sequence of events that occur when running a page containing client validation:
When the page loads into the browser, each verification control needs to be initialized some time. These controls are sent as <span> tags, and their HTML attributes are closest to those on the server. Most importantly, all input elements referenced by the validator are "mounted" at this time. The referenced input element will modify its client events so that the verification routine is called every time the input changes.
The code in the script library will be executed when the user switches between fields using the tab key. When a separate field changes, the verification condition is re-evaluated, making the validator visible or invisible as needed.
When the user tries to submit a form, all validators are re-evaluated. If all of these validators are valid, the form will be submitted to the server. If there are one or more errors, the following situations will occur:
Submission was cancelled. The form is not submitted to the server.
All invalid validators are visible.
If a verification summary contains ShowSummary=true, all errors from the verification control are collected and their contents are updated with those errors.
If a verification summary contains ShowMessageBox=true, errors are collected and displayed in the client's information box.
Because client verification controls are executed each time a change is entered or submitted, these verification controls are usually evaluated on the client twice or more times. Please note that after submission, these verification controls will still be re-evaluated on the server.
Client API
There is a small API that can be used on the client machine to achieve various effects in your own client code. Because some routines cannot be hidden, in theory, you can leverage the client to verify all variables, features, and functions defined by the script. However, many of these are implementation details that can be changed. The following summarizes the client objects we encourage you to use.
Table 3. Client Objects
Name type description
The Page_IsValid Boolean variable indicates whether the page is currently valid. The verification script always keeps the variable up to date.
Page_Validators Element array This is an array containing all validators on the page.
The Page_ValidationActive Boolean variable indicates whether verification should be performed. Setting this variable to False can be turned off by programming.
isvalid Boolean property Each client validator has this property indicating whether the validator is currently valid. Note that in the PDC version, this property is mixed with upper and lower case ("IsValid").
Bypassing client authentication
One task you often need to perform is to add a Cancel button or navigation button on the page. In this case, you may want to submit the page using the button, even if there is an error on the page. Because the client button "onclick" event occurs before the "onsubmit" event of the form, it may avoid submitting checks and bypassing verification. The following describes how to complete the task using the HTML Image control as the Cancel button:
<input type=image runat=server
value="Cancel"
OnServerClick=cmdCancel_Click >
Executing this task using the Button or ImageButton control will cause some confusion because the "onclick" event is assumed to be a server-side event with the same name. You should set the event in the client script:
<asp:ImageButton runat=server id=cmdImgCancel
AlternateText="Cancel"
OnClick=cmdCancel_Click/>
<script language="javascript">
document.all["cmdImgCancel"].onclick =
new Function("Page_ValidationActive=false;");
</script>
Another way to solve this problem is to set the Cancel button so that it does not trigger the commit event in the client script when it returns. The HtmlInputButton and LinkButton controls are examples of this.
Special effects
Another common requirement is that in the event of an error, in addition to the error message displayed by the validator itself, there are other effects required. In this case, any modifications you make must be made simultaneously on the server or client. Suppose you need to add a Label to change the color depending on whether the input is valid or not. Here is how to implement this task on the server:
public class ChangeColorPage : Page {
public Label lblZip;
public RegularExpressionValidator valZip;
protected override void OnLoad(EventArgs e) {
lblZip.ForeColor = valZip.IsValid? Color.Black : Color.Red;
}
}
All of the above methods are perfect, but as long as you modify the verification as mentioned above, you will find that unless you do the same on the client, it will look very inconsistent. The verification framework will prevent you from many of these dual effects, but it cannot avoid other effects that you must achieve simultaneously on both the client and the server. Here is a snippet of performing the same task on the client:
<asp:Label id=lblZip runat=server
Text="Zip Code:"/>
<asp:TextBox id=txtZip runat=server
/></asp:TextBox><br>
<asp:RegularExpressionValidator id=valZip runat=server
ControlToValidate=txtZip
ErrorMessage="Invalid Postal Code"
ValidationExpression="[0-9]{5}" /><br>
<script language=javascript>
function txtZipOnChange() {
//If client authentication is not active, no action is performed
if (typeof(Page_Validators) == "undefined")return;
//Change the color of the label
lblZip.style.color = valZip.isvalid ? "Black" : "Red";
}
</script>
Beta 1 Client API
For Beta version 1, some functions that can be called from client scripts can cause other situations.
Table 4. Functions called from client scripts
Name Description
ValidatorValidate(val) takes a client validator as input. Make the validator check its input and update its display.
ValidatorEnable(val, enable) Gets a client validator and a Boolean value. Enable or disable client validator. If disabled, the client validator will not be evaluated and the client validator will always appear as valid.
ValidatorHookupControl(control, val) Gets an input HTML element and a client validator. Modify or create the change event for that element so that the validator is updated when it changes. This function is suitable for custom validators based on multiple input values.
Its special purpose is to enable or disable the validator. If you want the verification to be effective only in a specific situation, you may need to change the activation status on both the server and the client, otherwise you will find that the user cannot submit the page.
The following is the example above plus a field that is validated only when a check box is unchecked.
public class Conditional : Page {
public HtmlInputCheckBox chkSameAs;
public RequiredFieldValidator rfvalShipAddress;
protected override void Validate() {
bool enableShip = !chkSameAs.Checked;
rfvalShipAddress.Enabled = enableShip;
base.Validate();
}
}
Here is the client equivalent code:
<input type=checkbox runat=server id=chkSameAs
>Same as payment address<br>
<script language=javascript>
function OnChangeSameAs() {
var enableShip = !event.srcElement.status;
ValidatorEnable(rfvalShipAddress, enableShip);
}
</script>