But couldn't one component cover the logic of both the "us" way and the
"iso" way, using some sort of locale property? A locale property would
then also be able to have some presets in it..
switch (locale)
{
case "US":
{ mask = "nnnnn-nnnn"; }
case "CA":
{ mask = "xxxx xxxx"; }
....
....
}
This would allow for us to have a single component that we could easily
switch between if we have an internalized application.
-Nick
On Fri, Mar 2, 2012 at 11:58 AM, David Francis Buhler <davidbuh...@gmail.com
> wrote:
> 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
> >> >
> >> >
> >>
> >
> >
>
