神马文学网ASP.NET: Selectively Enable Form Validation When Using ASP.NET Web Controls -- MSDN Magazine, April
来源：百度文库 编辑：神马文学网 时间：2024/04/30 14:50:35
ASP.NETSelectively Enable Form Validation When Using ASP.NET Web Controls
James M. Venglarik, II
This article assumes you‘re familiar with ASP.NET and Visual Basic .NETLevel of Difficulty 1 2 3 Download the code for this article:Valid.exe (38KB)SUMMARY Sometimes the extra controls thatcome with Visual Studio .NET can be a bit inflexible or they just don‘tprovide enough functionality or flexibility for all situations. TheASP.NET form validation controls, while powerful and easy to use,require that the entire page be valid before it‘s submitted back to theserver. Through the use of the new object-oriented features of VisualBasic .NET, it is possible to extend their functionality to overcomethis limitation.
Thisarticle tells you how and helps you decide when it‘s a good idea tokeep validation on the client and when you‘d be better off disablingit.
nASP.NET, you can include validation controls that automatically checkuser input on a page. While this is not a new function (it wasavailable through JavaScript include files), the implementationcertainly is. You no longer have to worry about where to do validation(on the server or client), nor do you have to worry about theclient-side code. It‘s all provided by means of using the five built-invalidation controls: Regular Expression, Required Field, Range,Comparison, and Custom.
Muchhas already been written about the use of the validation controls, so Iwon‘t go into the functionality of each. For those details, see AnthonyMoore‘s articles "User Input Validation in ASP.NET" and "ASP.NET Validation in Depth".Suffice it to say that it‘s fairly easy to include the controls on yourpage; simply specify any parameters that are needed (the control tovalidate, the regular expression to validate against, and so on), andlet it run. That is the beauty of the new controls. You don‘t have toworry about how they are implemented, just that they are there andfunctioning.
However,by including those validation controls on your page, you are implyingthat you want all of the user‘s input validated before acting upon it.Even if this isn‘t the intended effect, you might find out that it iseasiest to include these controls to check all the input. In thisarticle, I will explain why you might want to disable those controlsand how to do so. I will show you how to disable controls for an entirepage, how to disable them from the server, and how to disable them incertain instances on both the client and the server.
The Validation Process
The following is a simplified description of the process that happens when a validation control is used on a page.
When a page containing validation controls is requested, the user‘s browser type and version is evaluated to determine if client-side validation routines should be used.
If the browser supports client-side validation, the page loads with the appropriate routines being called from the validation controls. This is handled through a JScript® include file.
When the user moves between controls on a client-side validated form after changing a control‘s value, the validation events for the control that lost the focus are fired and appropriate error messages (if any) are displayed.
If the user generates a form submit on a client-side validated form, the entire form is evaluated for any validation controls that are not valid. If even one control is not valid, the form will not be submitted.
When the form is posted back to the server through a postback event, it is evaluated for validity on the server. This occurs even if the form was already evaluated on the client.
If any of the validation controls are found to be invalid through the server-side check, the page is redisplayed with the appropriate error messages included.
If the form passes all validation on both the server and client, the page processing sequence continues with the event that triggered the postback firing.
Asyou can see, the validation can occur multiple times on the client aswell as on the server. This provides enough validation so that ifimplemented properly, almost no erroneous data will be passed. Attimes, however, you might want to circumvent this process. Let‘s seewhy.
Reasons to Disable Form Validation
Whileform validation is a great tool for making sure that invalid orincorrectly formatted data is never acted upon, there are certainsituations in which you might want the data to pass through. Oneinstance, as Anthony Moore‘s ASP+ Validation article suggests, is whenyou leave the form by means of a Cancel button. Frequently, whenentering an order, updating an FAQ, or registering, the user will wantto back out of what they are doing. You can provide a link on the pagethat navigates elsewhere, thereby discarding all of the entered data,but for consistent design every Submit button should have a matchingCancel button.
Anotherexample is a multipart form. Since you can only have one server-sideform (runat=server), you cannot divide the page into multiple formsthat will generate postback events. If you have a page that lists FAQsat the top for editing, but at the bottom of the page you provide themeans to add a new FAQ, you do not want the errors in editing toprevent someone from adding a new FAQ to the page.
The trick in these instances is to know when to allow validation and when to prevent it.
Disabling Client-Side Validation on the Entire Form
Aneasy way to disable all client-side form validation is to provide theclienttarget=downlevel attribute in the Page directive at the top ofyour page. The directive looks like this:
<%@ Page Language="VB" codebehind="MyPage1.vb" InheritsMyApp.MyPage1" clienttarget=downlevel>You need to be careful when you do this because it not only disablesall client-side validation, it also disables any other client-sideserver control functionality. You can also disable client-side formvalidation for all validation controls by setting the global pagevariable Page_PostIfValidationError to True.
Theonly time you would do either of these is when you have included somevalidation controls through a common include for the page or embeddedthem in a custom control. Alternately, you can opt not to include thevalidation controls on the page.
Youcan disable all client-side form validation using a number of differentmethods depending upon the type of control that the user activates. Fora regular HTML control, you can set the Page_ValidationActive propertyto false. For example:
Please note that it is important to set the onServerClick event toequal the event you have defined in the codebehind page for thecontrol; otherwise, the event won‘t fire since you have overridden theonClick event.
For a server-side control, disabling all form validation requires some client-side code, like this:
James M. Venglarik, II
This article assumes you‘re familiar with ASP.NET and Visual Basic .NETLevel of Difficulty 1 2 3 Download the code for this article:Valid.exe (38KB)SUMMARY Sometimes the extra controls thatcome with Visual Studio .NET can be a bit inflexible or they just don‘tprovide enough functionality or flexibility for all situations. TheASP.NET form validation controls, while powerful and easy to use,require that the entire page be valid before it‘s submitted back to theserver. Through the use of the new object-oriented features of VisualBasic .NET, it is possible to extend their functionality to overcomethis limitation.Thisarticle tells you how and helps you decide when it‘s a good idea tokeep validation on the client and when you‘d be better off disablingit.nASP.NET, you can include validation controls that automatically checkuser input on a page. While this is not a new function (it wasavailable through JavaScript include files), the implementationcertainly is. You no longer have to worry about where to do validation(on the server or client), nor do you have to worry about theclient-side code. It‘s all provided by means of using the five built-invalidation controls: Regular Expression, Required Field, Range,Comparison, and Custom.Muchhas already been written about the use of the validation controls, so Iwon‘t go into the functionality of each. For those details, see AnthonyMoore‘s articles "User Input Validation in ASP.NET" and "ASP.NET Validation in Depth".Suffice it to say that it‘s fairly easy to include the controls on yourpage; simply specify any parameters that are needed (the control tovalidate, the regular expression to validate against, and so on), andlet it run. That is the beauty of the new controls. You don‘t have toworry about how they are implemented, just that they are there andfunctioning.However,by including those validation controls on your page, you are implyingthat you want all of the user‘s input validated before acting upon it.Even if this isn‘t the intended effect, you might find out that it iseasiest to include these controls to check all the input. In thisarticle, I will explain why you might want to disable those controlsand how to do so. I will show you how to disable controls for an entirepage, how to disable them from the server, and how to disable them incertain instances on both the client and the server.The Validation Process
The following is a simplified description of the process that happens when a validation control is used on a page.When a page containing validation controls is requested, the user‘s browser type and version is evaluated to determine if client-side validation routines should be used.
If the browser supports client-side validation, the page loads with the appropriate routines being called from the validation controls. This is handled through a JScript® include file.
When the user moves between controls on a client-side validated form after changing a control‘s value, the validation events for the control that lost the focus are fired and appropriate error messages (if any) are displayed.
If the user generates a form submit on a client-side validated form, the entire form is evaluated for any validation controls that are not valid. If even one control is not valid, the form will not be submitted.
When the form is posted back to the server through a postback event, it is evaluated for validity on the server. This occurs even if the form was already evaluated on the client.
If any of the validation controls are found to be invalid through the server-side check, the page is redisplayed with the appropriate error messages included.
If the form passes all validation on both the server and client, the page processing sequence continues with the event that triggered the postback firing.
Asyou can see, the validation can occur multiple times on the client aswell as on the server. This provides enough validation so that ifimplemented properly, almost no erroneous data will be passed. Attimes, however, you might want to circumvent this process. Let‘s seewhy.Reasons to Disable Form Validation
Whileform validation is a great tool for making sure that invalid orincorrectly formatted data is never acted upon, there are certainsituations in which you might want the data to pass through. Oneinstance, as Anthony Moore‘s ASP+ Validation article suggests, is whenyou leave the form by means of a Cancel button. Frequently, whenentering an order, updating an FAQ, or registering, the user will wantto back out of what they are doing. You can provide a link on the pagethat navigates elsewhere, thereby discarding all of the entered data,but for consistent design every Submit button should have a matchingCancel button.Anotherexample is a multipart form. Since you can only have one server-sideform (runat=server), you cannot divide the page into multiple formsthat will generate postback events. If you have a page that lists FAQsat the top for editing, but at the bottom of the page you provide themeans to add a new FAQ, you do not want the errors in editing toprevent someone from adding a new FAQ to the page.The trick in these instances is to know when to allow validation and when to prevent it.Disabling Client-Side Validation on the Entire Form
Aneasy way to disable all client-side form validation is to provide theclienttarget=downlevel attribute in the Page directive at the top ofyour page. The directive looks like this:<%@ Page Language="VB" codebehind="MyPage1.vb" InheritsMyApp.MyPage1" clienttarget=downlevel>You need to be careful when you do this because it not only disablesall client-side validation, it also disables any other client-sideserver control functionality. You can also disable client-side formvalidation for all validation controls by setting the global pagevariable Page_PostIfValidationError to True.
Theonly time you would do either of these is when you have included somevalidation controls through a common include for the page or embeddedthem in a custom control. Alternately, you can opt not to include thevalidation controls on the page.Youcan disable all client-side form validation using a number of differentmethods depending upon the type of control that the user activates. Fora regular HTML control, you can set the Page_ValidationActive propertyto false. For example:Please note that it is important to set the onServerClick event toequal the event you have defined in the codebehind page for thecontrol; otherwise, the event won‘t fire since you have overridden theonClick event.
For a server-side control, disabling all form validation requires some client-side code, like this: