2008/5/12 Robert A. Rosenberg <[EMAIL PROTECTED]>: > If you accept only cards that use 4 4-character fields, you can also have 4 > windows (each 4 characters wide) and auto-advance the cursor after the 4th > character (I have seen this done but it may need JavaScript). AJAX (or > JavaScript) will allow you to generate the fields after the Card Type Radio > Button is selected so other formats (like AMEX [4-6-5]) can be handled. Use > of AJAX or JavaScript also allows Client Side checking of the Card Type (the > first characters key to the Card Type) as well as the Check Digit Check.
Well... Some very cute things can indeed be done this way, but many of them can go wrong because the implementor didn't think through the possibilities, or the possibilities changed after the app was written, or incorrect assumptions were made. Over editing is often worse than under, and there is a tradeoff between ensuring data is at least safe (e.g. stripping out SQL injection and the like) vs disallowing valid but unanticipated data. Pet peeves of mine on websites: Disallowing valid characters in email addresses. I'd say the majority of sites won't allow a plus sign, but it's perfectly valid. Same goes for all-numeric domain names. Refusing phone numbers in international standard format, e.g. +1 212 555-1212. Many sites first try to determine the country you're in, and then force the phone number to match what they think that country uses. Some even force in a bogus access code, e.g. 00 for Europe. Phones themselves generally get this right - the UI may format the number as you key it in according to local rules (local to where you bought the phone, that is), but if you enter it in the +cc format then they store it that way without bogus formatting. And then you can use your phone's address book when you travel. Assuming local date formats. Sigh - why can't everyone at least accept ISO 8601 on input? It's unambiguous and universal. Formatting names according to some assumed standard, e.g. changing the first letter of each part to upper case. Enough said on this, except to remark on the sheer number of homegrown and experimental schemes deployed out there, almost all of them wrong for some quite common names! Playing cute games with ZIP codes. Do not use the ZIP code to "correct" the address that was entered, particularly if the "ZIP" code is actually some other country's postal code. Squishing blanks out of postal codes. Many countries' codes contain a blank. And worst of all... Rejecting part of the entered data for some (often wrong) reason, and forcing re-entry of everything else! Tony H ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
