Programming Microsoft ASP.NET 4 - Dino Esposito [208]
Custom error information You don’t use the ValidationSummary control, and you set the Display property of the individual validators to None. In addition, you collect the various error messages through the ErrorMessage property on the validation controls and arrange your own feedback for the user.
Enabling Client Validation
As mentioned earlier, the verification normally takes place on the server as the result of the postback event or after the Validate method is called. If scripting is enabled on the browser, though, you can also activate the validation process on the client, with a significant gain in responsiveness. In fact, there’s no real value in making a roundtrip to the server only to discover that a required field has been left empty. The sooner you can figure it out, the better. On the other hand, you certainly can’t rely exclusively on client-side validation. To run secure code and prevent malicious and underhanded attacks, you should validate any input data on the server too.
When client-side validation is turned on, the page doesn’t post back until all the input fields contain valid data. However, not all types of validation can be accomplished on the client. In fact, if you need to validate against a database, well, there’s no other option than posting back to the server. (AJAX facilities, which we’ll explore in Chapter 20, might provide relief for this problem.)
Client validation can be controlled on a per-validation control basis by using the EnableClientScript Boolean property. By default, the property is set to true, meaning client validation is enabled as long as the browser supports it. By default, the code in the BaseValidator class detects the browser’s capabilities through the Request.Browser property. If the browser is considered up-level, the client validation will be implemented. In ASP.NET 4, browsers and client devices that are considered up-level support at least the following:
ECMAScript version 1.2 or newer
W3C DOM Level 1 or greater
Today, nearly all browsers available meet these requirements. Generally, an up-level browser matches the capabilities of Internet Explorer 6 and newer. Consider that ASP.NET 4 checks the browser capabilities using the Request.Browser object. The information that this object returns is influenced by the value of the ClientTarget property on the Page class. The property indicates which set of browser capabilities the page assumes from the current browser. Specifying a value for the ClientTarget property overrides the automatic detection of browser capabilities that is normally accomplished. You can set the ClientTarget property via code, using the @Page directive, or in the configuration file.
What are the feasible values for ClientTarget?
In general, ClientTarget gets a string that refers to a user agent string. However, the root web.config configuration file defines a couple of default aliases that you can use as shorthand for common user-agent strings: uplevel and downlevel.
The uplevel alias specifies browser capabilities equivalent to Internet Explorer 6, whereas the downlevel alias refers to the capabilities of older browsers that do not support client script. You can define additional aliases in the clientTarget section of the application-level web.config file. (See Chapter 3.)
Validation Groups
By default, control validation occurs in an all-or-nothing kind of way. For example, if you have a set of input and validation controls and two buttons on the form, clicking either button will always validate all controls. In other words, there’s no way to validate some controls when one button is clicked and some others when the other button is clicked.
The CausesValidation property on button controls allows you to disable validation on a button, but that is not the real point here. What would be desirable is the ability to perform validation on a group of controls. This is exactly what the ValidationGroup