flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: mx PostCode validator class
Date Tue, 06 Mar 2012 06:50:36 GMT

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.


PS Opps it's flash.globalization not flash.globalisation. Sigh - g11n is used for a reason.
View raw message