I was recently looking at the fancy client-side form validation by DHTML Goodies (
http://dhtmlgoodies.com/scripts/dhtml-form-validation/dhtml-form-validation.html) and also thinking about extending eForm to validate credit card numbers and future expiration dates for ShopX. When I looked at their script it struck me that the same method could make eForm infinitely flexible by allowing people to add their own custom patterns for validation. This seems like it would be simpler than adding every possible desired form type into the script, and additionally it seems as if it would be a quick jump from there to reformatting the input to normalize it and make it more aesthetically-pleasing before sending the results.
So for example, I might add something like this to the beginning of my eform snippet:
customType['phone']['pattern'] = '^(?:\([2-9]\d{2}\)\ ?|[2-9]\d{2}(?:\-?|\ ?|\.?))[2-9]\d{2}[- \.]?\d{4}$;
customType['phone']['output_mask'] = 'whatever the regex would be to format any matched pattern to (123) 456-7890 - I'm too lazy to do it now';
customType['phone']['error_msg'] = ' does not appear to be a valid phone number. Please enter your complete phone number (including area code).';
Then I could declare a field to be customType[’phone’] in my snippet call and it could be validated and reformatted as specified. So for example I could have a credit card number pattern match that would be specific to my needs (we take Visa, MC, and AmEx, but not Discover). And since the match pattern is set in the snippet itself you could have PHP-scripted patterns (for example, any future date).
Does that seem like it could be a useful way of extending eForm’s functionality in terms of validation?