One of the best things that was added to Tango was the <@KEEP> tag. I use it to handle many entry fields, phone number is one that is a must. I learned quite early that it is much easier to strip away all but the actual digits, and store only the raw numeric characters in the database. Then let the FORMAT attribute handle the display on the other end.
All of my phone number inserts use something like this: <@KEEP "<@ARG NAME='phonenumber'>" CHARS="0123456789">. Most times there is also a validation routine that is processed just prior to the insert. Parts of this verification could include things like:
<@ASSIGN "l_phonenumber" <@KEEP <@ARG " ' >
<@IF <@ARG = 1) OR (<@ARG = 2)'>
<@IF <@LENGTH = 10'>
<@ASSIGN "l_verifyphonenumber" "pass" >
<@ELSE>
<@ASSIGN "l_verification" "fail" >
<@ASSIGN "l_verifyphonenumber" "fail" >
where Canada=1 and USA=2 and the stripped down phone number entered has been assigned to local$l_phonenumber. On behalf of the rest of the world, please don't put in any kind of arrogant North American verification that won't allow other phone numbers.
For Zips and Postal Codes I use this:
<@ASSIGN "l_zippostal" <@UPPER <@ARG " >
<@ASSIGN "l_zippostal" <@OMIT local$l_zippostal" " "' >
<@IF <@ARG = 1">
<@IF <@KEEP local$l_zippostal" = >
<@ASSIGN "l_verifyzippostal" "pass" >
<@ELSE>
<@ASSIGN "l_verification" "fail" >
<@ASSIGN "l_verifyzippostal" "fail" >
</@IF>
<@IF <@LENGTH = 6'>
<@ASSIGN "l_verifyzippostal" "pass" >
<@ELSE>
<@ASSIGN "l_verification" "fail" >
<@ASSIGN "l_verifyzippostal" "fail" >
</@IF>
<@ELSEIF <@ARG = 2">
<@IF <@KEEP <@ARG " = <@ARG >
<@ASSIGN "l_verifyzippostal" "pass" >
<@ELSE>
<@ASSIGN "l_verification" "fail" >
<@ASSIGN "l_verifyzippostal" "fail" >
</@IF>
<@IF <@LENGTH <@KEEP <@ARG ' = 5) OR (<@LENGTH <@KEEP <@ARG ' CHARS='0123456789-'>"> = 10) AND (<@ARG country> = 2)'>
<@ASSIGN "l_verifyzippostal" "pass" >
<@ELSE>
<@ASSIGN "l_verification" "fail" >
<@ASSIGN "l_verifyzippostal" "fail" >
</@IF>
</@IF>
This starts by taking any Cdn Postal Code and forcing it to upper case (it's amazing how many lazy people enter information in all lower case). Then I strip out the spaces if there are any. Then I check to make sure that the KEEP version (allowing only uppercase alpha characters and numbers) matches the raw submission. Then I can check that the length is correct. The reason I leave the length check until last is to get the data into only allowable characters first. This way if someone's fingers have slipped and they've hit the ';' or ':' key instead of an 'L' it will fail because the incorrect character will first be stripped away, leaving only 5 characters. The entry will fail based on length.
For US Zip Codes I do a similar KEEP check allowing only numeric characters and the dash '-'. Then I check the length to see if it is either 5 or 10 (for extended zips with the dash included).
If you plan on implementing this for Zip Codes, as a Canadian I ask that you please have the routine run on submissions where US is the country selected. It is extremely frustrating to be able to enter my address, even select my province from a list of states, but be unable to submit because the page only allows numeric values in the zip code field. Either add something for Canadian Postal Codes or skip the verification on Canadian addresses.
Note that if something fails in either phone or zippostal I set two variables. One to indicate that I have a failure, and one to let me know what the specific failure(s) was(were). Note that I'm also checking ONLY North American entries. Right now, if a user selects any other country then can enter whatever they want in either the phone number or zippostal fields. I am doing the <@KEEP "<@ARG NAME='phonenumber'>" CHARS="0123456789"> with the phone number but I haven't had the opportunity to add additional logic to handle the format checking for other countries. I then use a variation of the ELSE_IF_MISSING_FIELDS logic. If 'local$l_verification' is set to fail, the error/missing fields page is displayed. I then display the appropriate messages based on which of the other 'local$l_verifyxxx' variables are set to fail.
Now what this doesn't do is check the correct positioning for Canadian postal codes which is 'alpha, number, alpha, space, number, alpha, number' as in 'N1R 6Z5'. I'm planning on adding that to future work. I'd also like to start adding similar routines for other countries/regions such as the UK. If someone could either provide me with the official information or point me in the right direction, I'd be grateful. I'm looking for lists of states and provinces and/or for formatting of postal or mail codes for countries outside of North America
Hope this helps,
Steve Smith
Oakbridge Information Solutions
Office: (519) 624-4388
GTA: (416) 606-3885
Fax: (519) 624-3353
Cell: (416) 606-3885
Email: [EMAIL PROTECTED]
Web: http://www.oakbridge.ca
On Monday, December 8, 2003, at 09:56 AM, Wilcox, Jamileh (HSC) wrote:
Jeff - thanks for the replies. I tried this on my production server,
which runs T2K rather than W5, and got the same results.
The code doesn't seem to be working as written, unless you got different
results than I did.
It does sometimes work using an OR, but an OR won't do what I need. I
want it to go to the "Test Page for Telephone Validation" (where I would
have error messages telling them what to fix) only if the field contains
alpha characters. An all-numeric entry or an empty field should bypass
the validation and go to the html that says "Next Page" (under the Else
action).
It's a moot point for me now, since I figured out a method to use the
regex metatag (which also doesn't work in an IF action), but I'll post
my testing results below for future reference, in case someone else
tries to use this.
Scenario 1) (original setup)
Use "string is not empty AND isnum(string) = 0"
-no data entered: string is empty, so should go to "Next Page" - WORKS
-alpha characters entered: string is not empty and isnum=0, so should
go to "Test Page" - WORKS
-numeric characters entered: string is not empty and isnum=1, so should
go to "Next Page" - DOES NOT WORK, goes to "Test Page"
Scenario 2) (change AND to OR)
Use "string is not empty OR isnum(string) = 0"
-no data entered: string is empty; isnum=0, so should go to "Test Page"
- WORKS
-alpha characters entered: string is not empty, so should go to "Test
Page" - WORKS
-numeric characters entered: string is not empty, so should go to "Test
Page" - WORKS
Scenario 3) (change isnum=0 to isnum=1)
Use "string is not empty OR isnum(string) = 1"
-no data entered: string is empty; isnum=0, so should go to "Next Page"
- WORKS*
-alpha characters entered: string is not empty, so should go to "Test
Page" - WORKS
-numeric characters entered: string is not empty, so should go to "Test
Page" - WORKS
Scenario 4) (change OR to AND)
Use "string is not empty AND isnum(string) = 1"
-no data entered: string is empty, so should go to "Next Page" - WORKS
-alpha characters entered: string is not empty and isnum=0, so should
go to "Next Page" - WORKS
-numeric characters entered: string is not empty and isnum=1, so should
go to "Test Page" - DOES NOT WORK, goes to "Next Page"
*I tested everything a couple times before this round & this did NOT
work; all 3 scenarios went to the "Test Page". I started completely
over to document results for this email & it worked this time around.
