introduction
validating user input is a common scenario in a web-based application. for production applications, developers often end up spending a lot more time and code on this task than we would like. in building the asp+ page framework, it was important to try and make the task of validating input a lot easer than it has been in the past.
the problem
in html 3.2, validating data is a difficult process. each time you get a request, you need to write code to check the input and write any errors the user has made back to the page to help the user to correctly fill in the validation form. this is a taxing process for end users, developers, and servers alike.
dthml and scripting languages improve things somewhat. it is possible to provide the user with immediate feedback on bad input and to prevent them from posting a page until it has been corrected. however, it can be almost impossible to guarantee that every user of your site has the required scripting environment. this usually means that if you want to use script to improve the interface of your pages, you have to write the same validation logic twice, once on the client, and again on the server, just in case the client code cannot be executed.
the objective
our objective with validation is as follows:
- provide components that can perform 90 percent or more of the typical input validation tasks for data entry pages.
- have these components perform rich script-based validation on modern browsers that can also effectively fall back to pure html 3.2 server-based validation, if required.
- provide a flexible api so that any validation tasks not covered by the components are easy to complete.
we visited a large number of real pages to determine the sort of scenarios these components needed to be able to handle. we wanted to dramatically reduce the amount of validation code needed for future applications.
the solution—overview
the validator controls are the main elements of the solution. a validator is a visual asp+ control that checks a specific validity condition of another control. it generally appears to the user as a piece of text that displays or hides depending on whether the control it is checking is in error. it can also be an image, or can even be invisible and still do useful work. there are five types of validator controls that perform different types of checks.
another element in our solution is the validationsummary control. large data entry pages generally have an area where all errors are listed. the validationsummary automatically generates this content by gathering it up from validator controls on the page.
the final element is the page object itself. it exposes the all-important "isvalid" property, which you check in server code to determine if all of the user input is ok.
client features
most web sites do all of their validation checks on the server. you need to write the server-based checks anyway for clients without script, so it can be hard to justify writing it all over again for rich clients.
validation controls change all that, because almost all the duplicated logic is encapsulated in the controls. if a client with internet explorer 4.0 or later uses your page, it can do the same input validation that takes place on the server without you having to write any special client script.
the client side validation has a number of features:
- errors can appear and disappear immediately after the bad input is entered/corrected. this immediate feedback makes it much easier to correct bad input.
- post-back is prevented if there are errors that are detectable on the client, saving the user time and reduces hits on the server.
- the validationsummary updates itself without posting back if it detects errors.
- the validationsummary can optionally display a message box to the user if there are errors.
- the client logic is all contained in a jscript library, so no activex components or java applets are used.
- can optionally use vbscript to perform checks involving localized date and number comparison.
- an object model is exposed on the client to allow enhancement of client-side validation and behavior.
what is a validator?
in order to use validators effectively, it helps to have a firm definition of what they are. lets refine our previous definition a little:
"a validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."
this is an important definition, because it means that you frequently need to use more than one validator control for each input control.
for example, if you want to check whether or not user input in a text box is (a) nonblank, (b) a valid date between a particular range and (c) less than the date in another text input control, you would want to use three validators. while this might seem cumbersome, remember that to be helpful to the user, you would want to have three different text descriptions for all these cases.
the different types of validators are listed as follows:
| requiredfieldvalidator | checks that the user has entered or selected anything. |
| regularexpressionvalidator | checks user input against a regular expression. this allows a wide variety of checks to be made and can be used for things like zip codes and phone numbers. |
| comparevalidator | compares an input control to a fixed value or another input control. it can be used for password verification fields, for example. it is also possible to do typed date and number comparisons. |
| rangevalidator | much like comparevalidator, but can check that the input is between two values or the values of other input controls. |
| customvalidator | this allows you to write your own code to take part in the validation framework. |
validator walk-through
to demonstrate validation, we will walk through the process of adding validation to an existing page. here are some example requirements:
write a web page to collect a new user id and password. the user id must contain 6-10 alpha characters and must not already be in use. the password must contain 4-12 letters, at least one number and at least one of the characters "@#$%^&*/". the user must re-enter the password to make sure they entered it correctly.
i am going to start with an html page that has been minimally converted to work with the asp+ page framework.
the process of converting the page includes the following steps:
- change the extension from ".html" or ".asp" to ".aspx".
- change the form and all the input tags to be "runat=server".
- use "id" instead of "name".
starting code:
<html><head><title>validation sample</title></head><body><p>please enter a new user id and password:</p><form runat=server><table> <tr> <td>user id:</td> <td><input type=text runat=server id=txtname></td> </tr> <tr> <td>password:</td> <td><input type=password runat=server id=txtpword></td> </tr> <tr> <td>re-enter password:</td> <td><input type=password runat=server id=txtrepword></td> </tr><table><br><input type=submit runat=server id=cmdsubmit value=submit></form></body></html>
starting page:
its not voluntary
the first thing we need to enforce is that the fields get filled in at all.
in front of each field, we add a requiredfieldvalidator. if the input field is blank, we want to display an asterisk (*) in front of the field and report a text error in a summary area. here is how we add a requiredfieldvalidator to the user id field:
<tr> <td> <asp:requiredfieldvalidator runat=server controltovalidate=txtname errormessage="user id is required."> * </asp:requiredfieldvalidator> </td> <td>user id:</td> <td><input type=text runat=server id=txtname></td> </tr>
the * is displayed next to the label if the input is blank. the error message is reported in a summary. the "controltovalidate" property specifies the id of the control to validate. the final step is to add a validation summary to the top of the page like so:
<asp:validationsummary runat=server headertext="there were errors on the page:" />
here is how it looks on the page:
getting regular
next we need to enforce the character requirements for the user id and password fields. for these we will use regularexpressionvalidator controls. regular expressions can be very powerful in concisely expressing checks for this sort of information, as well as zip codes, phone numbers, and e-mail addresses.
here is how we specify the restrictions on user id:
<td> <input type=text runat=server id=txtname> <asp:regularexpressionvalidator runat=server controltovalidate="txtname" errormesage="id must be 6-10 letters." validationexpression="[a-za-z]{6,10}" /> </td>note that in this case we did not specify any inner content within the tag. the inner text is equivalent to the text property of the control. if it is blank, it error message will be displayed where the control is positioned, as well as appearing in the summary.
the password checks can be done with the following two validators. if you use more than one, they must all match before the input is considered valid.
<asp:regularexpressionvalidator runat=server display=dynamic controltovalidate="txtpword" errormessage="password must contain one of @#$%^&*/." validationexpression=".*[@#$%^&*/].*" /> <asp:regularexpressionvalidator runat=server display=dynamic controltovalidate="txtpword" errormessage="password must be 4-12 nonblank characters." validationexpression="[\s{4,12}" />]here is the form in action with the expressions:
comparing apples and apples
we need to make sure the password re-entry field matches the password. we will use the comparevalidator to do this, since it is capable of working with two input controls at a time:
<asp:comparevalidator runat=server controltovalidate=txtrepword controltocompare=txtpword errormessage="passwords do not match." />
by default, comparevalidator does a simple string match comparison. if required, it can do more complex comparisons involving dates and numbers.
custom fit
the final thing we need to check is that the name is not already taken in our hypothetical site. this is going to require looking at some data on the server. to simulate this, i will create a dummy function in server-side code that checks that the first character is not an "a." the following visual basic function is defined on the page:
public function checkid(source as object, value as string) as boolean return value.substring(0, 1).tolower() <> "a"end function
to call this function, i will add a customvalidator, which is designed to call developer code to perform its check. here is the declaration:
<asp:customvalidator runat=server controltovalidate="txtname" errormessage="id is already in use." onservervalidationfunction="checkid" />
this can also call custom functions in client script, although that would not be practical if this really had to look up a value in a database. on a client with script, all the other validators do their checks on the client first before allowing the submit to take place. if there are errors detected by server-only checks like this one, page will be sent back to the user indicating those errors.
the finale
now, the only thing left is to make use of the nicely validated data. all you need to do is check the isvalid property of page to work out if you can proceed to update your database. here is how your submit handler might look:
public sub onsubmit(source as object, e as eventargs) if page.isvalid then now we can perform our transaction. end ifend sub
as you can see, this handler will allow your data entry pages to consist of code that is specific to your application instead of being full of code to deal with mundane input checking.
here is some more of the final page in action:
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
