Form-level validation in Java

Make QR Code 2d barcode in Java Form-level validation

Sometimes you want to validate fields immediately, as soon as a user enters a value or tabs away from the field (Listing 12-4 shows you an example of independent field validation) But sometimes you want to wait until the user finishes entering information before you begin your validation For example, the Webmeister form allows users to specify whether they want to be contacted by e-mail or by telephone At least one option must be selected, but triggering validation the instant a user tabs away from the e-mail field would be useless (and annoying) After all, that user might very well be intending to select the phone number option; you have no way of knowing until the user finishes filling out the entire form

If you need to define a more rigid pattern than the telephone number example that I describe in Listing 12-6, take a look at the JavaScript code in this sidebar, which requires that users enter a phone number in the following format:

(512)555-1212

As you see in the following example, the substring() method associated with the built-in JavaScript string object lets you break a value into chunks and ensure that each chunk is valid For example, this code instructs the interpreter to extract and inspect the parentheses, area code, exchange, and line portions of the phone number separately

The benefit of this approach It ensures that users type exactly what you want them to type, which reduces the chance of miscommunication The drawback is that you re expecting a user to type a bunch of characters exactly the way you want a process that is difficult at best! (Keep in mind that the Web is global, and patterns that might be familiar to you might not be familiar at all to folks in other parts of the world) A good design rule to follow is this: If you absolutely must gather information in a specific format, by all means adapt this example of JavaScript code for your own purposes But if you can get by with fewer checks (like the phone number validation routine that I describe in Listing 12-6), go for it

function isAPhoneNumber(entry){ if (entry) { // Set openParen = to the first character of entry var openParen = entrysubstring(0,1) // Set areaCode = to the next 3 characters var areaCode = entrysubstring(1,4) // Set closeParen = to the 5th character var closeParen = entrysubstring(4,5) // Set exchange = to characters 6, 7, and 8 var exchange = entrysubstring(5,8) // Set dash = to the 9th character var dash = entrysubstring(8,9) // Set line = to the 10th through 13th characters var line = entrysubstring(9,13) // // // // // // The following if statement checks all the pieces, like so: if openParen is not equal to ( OR the areaCode is not a number OR the closeParen is not equal to ) and so on

if ( (openParen != ( ) || (!isANumber(areaCode)) || (closeParen != ) ) || (!isANumber(exchange)) || (dash != - ) || (!isANumber(line)) ){ alert( Incorrect phone number Please re-enter in the following format: (123)456-7890 ) } } } <FORM NAME= feedbackForm > <BR>Please enter your home phone number <BR>in the following format: (123)456-7890 <INPUT TYPE= text NAME= homePhone VALUE= SIZE=13 onBlur= isAPhoneNumber(thisvalue) >

Giving users appropriate, timely feedback can be the difference between a confusing Web site and one that is efficient and pleasant to use The following are a few things to keep in mind as you decide when and how to interact with your users DON T SHOUT!! Nobody likes being yelled at, and messages THAT ARE IN ALL UPPERCASE LIKE THIS AND END IN EXCLAMATION POINTS ARE YELLS! Say what you need to say; just use normal capitalization and punctuation In general, be specific Sometimes, you don t particularly care what a user types (for example, if you re asking for free-form comments on your product) At other times, what the user types is crucial For the times when it s crucial, be sure to let the user know up front, right on the page, what format is expected When you do need to pop up an error message, make sure that it tells users precisely what s wrong with their input (Invalid format Please retry doesn t count!) Give your users a break Just because you re now a card-carrying expert at validating user input doesn t mean you have to pop up an error message every time you detect an error In some cases, you might be able to massage (geekspeak for modify) the input data to suit yourself without bugging the user at all For example, just because you d like to see a value in uppercase letters doesn t mean the user has to enter it in uppercase letters Instead of displaying an error and requesting that the user retype the entry, for example, you can just as easily take the input and change it to uppercase yourself using the toUpperCase() method of the string object Pat your users on the back Don t reserve feedback for only those times when a user enters something incorrectly Reassuring users that things are proceeding as planned is just as useful For example, let users know when a form passes all validation checks Test til you drop Make sure (and this should go without saying, but you never know) that you test your form carefully for every conceivable error (and series of errors) that a user might reasonably be expected to make Few things are more frustrating to users than getting tangled in an endless loop of errors that refuse to go away, even after the user has figured out what s wrong and corrected it!

A better approach for dependent field validation is to wait until users try to submit their forms before executing your validation scripts, as shown in Listing 12-7 Now, if the user attempts to submit a form without entering either a phone number or an e-mail address, the script generates an error and prevents the form from being submitted To see how this code behaves at runtime, take a look at Figure 12-4