Without changing the thread-topic, the US Bank Code formats don't adhere to the ISO standard for Bank Number Formats. Most countries do adhere to the ISO standard (I think almost all countries except the US adhere to it).
It's hard to add validators that work across all countries, because almost all use some standard, but there are always a handful that do not. If I added a Bank Number validator, I would need one for the rest of the world (ISOBankNumberValidator) and one for the US (USBankNumberValidator). I could add different logic inside of a generic BankNumberValidator that asks whether the validation is for US Bank Account Numbers or Non-US Bank Account Numbers, but the class would become unwieldy and anyone trying to extend it would have to know intimate details about the class, suggesting the logic within the class violates the Single Responsibility principle. On Fri, Mar 2, 2012 at 11:52 AM, David Francis Buhler <davidbuh...@gmail.com > wrote: > "ZipCode" is a US-centric way of looking at US Postal codes. > > A Zip Code validator able to assess the validity of non-US postal codes > would be a "Postal Code Validator". > > > On Fri, Mar 2, 2012 at 9:27 AM, Nicholas Kwiatkowski <nicho...@spoon.as>wrote: > >> 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 >> > >> > >> > >
