Hi, I've taken a look at the newer spark validators and formatters. The differ from the mx classes in that: 1. They use flash.globalisation classes to obtain the locale (which can be overridden) and format according to that locale. 2. They are bindable so if the locale changes the format/validation changes 3. They use the same public methods as the mx code does (ie doValidation and format)
The flash.globalisation classes do not support postcodes only numbers, datetimes and currency. Postcodes (as far as I can tell) only use letters (A-Z) and numbers (0-9) and are independent from locale in that regard. Re binding postcodes It's more of an edge use case than with the spark validators/formatters. If you have a postcode you generally want it to be formatted to the locale it came from not the current locale. You may want to have an input field that accepts the correct post code based on the current users locale but you then you would probably need to deal with other address parts as well. StateValidator or CityValidator anyone? :-) There's probably no spark ZipCodeValidator for those reasons. So as far as I can see there's not much point in using spark/flash.globalisation style validators or formatters for postcodes. Anyone think differently? I guess that does cut down the selection of namespaces for these new classes to either org.apache.flex.validators / org.apache.flex.formatters or the existing mx namespaces. It may be useful to: 1. Add a user defined function for further validation (eg check character ranges for Canadian or Norwegian postcodes or numeric ranges to exclude PO boxes). 2. Add a method that returns a suggested format for the current (or a given) local. Thanks, Justin PS Opps it's flash.globalization not flash.globalisation. Sigh - g11n is used for a reason.
