What are your thoughts about adding this functionality to the ZipCodeValidator instead of having it as a separate component? I have to check against multiple countries, and it seems silly to have to load two different components that do basically the same thing (except for locale). Another option would be to add the US Zip validation ruleset into your component and leave the ZipCodeValidator alone.
-Nick On Wed, Feb 29, 2012 at 10:09 PM, Justin Mclean <jus...@classsoftware.com>wrote: > Hi there, > > I've created a first pass at an mx style post code validator. It still > needs some work. It can be found in my white board area here: > http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/validators/ > > It supports either a single postcode format or an array of postcode > formats. Formats are defined as strings consisting of N,A,CC,- or space > where is N is a number, A is a letter, CC is country code (optional) and > "-" or space for formatting. eg "NNNN" is a 4 digit postcode. "NNNN AA" is > 4 digits, followed by a space followed by 2 letters. > > It doesn't validate for ranges of numbers or exact letters. I've > considered a way of setting a call back that calls a user defined function > to do this. > > Would anyone like to see this added to the SDK at some point in the future? > > doValidate is a static method which required the formats array and the > country code to stored in static variables. It may be possible to add an > extra optional parameter to doValidate to get around this. Can anyone think > of another way of doing it? The ZipCodeValidator gets around this by hard > coding exact lengths and formats in the code but I don't thank that's > viable for a more generic class like this. > > For contribution like this what should the namespace be? mx.validators or > org.apache.flex.mx.validators or something else? > > Any interest in a similar spark version? > > Anyone want to help out by reviewing the code, writing more unit test (a > set of test for UK style postcodes would be useful) or any other way please > do so. > > Thanks, > Justin > >
