Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4F5AABD9.9060807@leichtgewicht.at>
Date: Sat, 10 Mar 2012 10:18:17 +0900
From: Martin Heidegger <mh@leichtgewicht.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: [Proposal] Add PostCodeValidator and PostCodeFormatter to the
 SDK
References: <503131DD-2947-4AF1-9815-DD4CFF6B028A@classsoftware.com>
 <1331309633.52878.YahooMailNeo@web110414.mail.gq1.yahoo.com>
 <4F5A5A44.20209@leichtgewicht.at>
 <FD189E1D-CFFC-4A1B-959F-D888371A4A56@classsoftware.com>
In-Reply-To: <FD189E1D-CFFC-4A1B-959F-D888371A4A56@classsoftware.com>
Content-Type: multipart/mixed;
 boundary="------------040306040506020604010608"

--------------040306040506020604010608
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 10/03/2012 09:03, Justin Mclean wrote:
> Couldn't find an instance of this can you point out which file?
Sorry, my fault, was browsing old version.

> I don't see it as an issue as the alternative would involve 3 if 
> statements and an extra variable.

Couldn't you just use var invalidFormat: Number = 0 or 1 ?

> I can't find any instances of that either. I used the "local" bracket style with the exception of single line if statements which was discussed (briefly) on the list the other week.
>
> if ()
>    doSomething();
> else
>    doSomethingElse();
>
> while compact without braces can lead to errors when modified at a later date.
PostCodeValidator - Line 560

>
>> *) You mix "brace in new line" (left) with "brace in current line" (right), afaik its in the current line.
> Again I can't find an instance of this in the formatter or validator classes. I find the  brace on current line more compact and have used that style in the unit tests.
I think there is a definite standard on that in the code guidelines of 
flex. however:
  PostCodeValidator - 499 & 513 just as one example


>> *) You have string checks like "if(value)" this also checks on "" but that is actually a valid "format", right?
> I had considered "" as a invalid format as it's not particularly interesting. I'll double check the unit tests around this.
It would be good to add that case to the documentation.

>
>> *) if() { return ... } return; is less good readable compared to if() { return } else {return} again: Not sure what the style guide says.
> The SDK use both styles.
Personally I see bad sides in the one with the missing else ... however: 
again: What did the Flex Gui

> It may be nice to know all errors for formats at a later date. We're 
> only talking about very small arrays here.

I made the experience that programming for possibilities is a very bad 
idea. I am not necessarily talking about the performance (which it also 
affects) but
also the readability.

>> *) I have seen Japanese people writing their postal code with the unicode character prefix: 〒 That is not an accepted Format
>  From what I've read the ITU only accepts A-Z and 0-9, but I certainly have no issue in expanding the character range.

The question is how this util is defined (documentation) if it validates 
to the ITU standard it should mention that.
But if its about usability: Japanese people certain

>
>> *) Japanese do have wide format numbers that they also like to use in postal adresses: ０１２３４５６７８９
> I'll also look into this.

This is a big problem for all number validation in japan. Oh: They also 
have double width A-Z ＡＢＣ．．．ＸＹＺ: try to build a search engine 
around that!

>> *) extraValidation is not sufficiently documented: No mention that the input can be null, no mention that the output has to be
>> one of the error types that it can deal with. I would expect following signature: extraValidation(postCode:String, baseField:String):Vector.<ValidationResult>;
> Will add more documentation. The existing mx class don't use arrays not vectors so changing it to use vectors could cause confusion in people using multiple validator classes.
I see thanks! And thinking about it further: shouldn't the "result" have 
a error-weight? To be compared with other errors?

> The signature is in the same format as the other mx validate classes 
> and is familiar to people who use them. I agree your signature is 
> better but it's probably not the time to be changing them all. 

I do not see a need for this to be consistent, does it? Anyways: I will 
not a refactoring of this signature for Flex X somewhere.

>> *) I would put the static functions in their own function file to reduce dependency hell.
> Again this is not the style of the currently validiators And I don't want to go down the path of rewriting all of them just yet:-)
Same here: not sure this it is necessary to continue that trend :-)

>> *) suggestFormat Should be separated from the Validator as it is not "necessary" to use the Validator (dependencies, dependencies)
> I think the connivence of having a single class is better. But happy to be convinced otherwise. Can you give a code sample?

I attached three examples how it think it could work else. All have less 
dependencies and better performance.

> Fp 10.2 is the earliest version the current 4.6 SDK will compile with (and that's only after I changed the build scripts)
Just because it compiles to this version doesn't mean it will work from 
this version on?! it is compilable with earlier SDK's as well ?!
>> *) @private
>> public function set formats
>>
>> What is this setter good for?
> For setting multiple formats: eg
> validator.formats = ["AN NAA", "ANN NAA", "AAN NAA", "ANA NAA", "AANN NAA", "AANA NAA"];
Then my question would be: Why is it private?

yours
Martin.

--------------040306040506020604010608
Content-Type: application/gzip;
 name="flex.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="flex.tar.gz"

H4sICNCqWk8CAGZsZXgudGFyAO1ZWXPaMBDmlfyKrZ+STPEVjtYhad0cvaEDpH3oMB1hBLg1
NmMLStrJf+/KJ5eBtIGZtt5JsCx9K6+8q08reTiVcrsWKMqVSgVywEVeuIY3ilJRyyVVkcsn
eF8sqUXIlXKZ7FrQ/xNimV3CHNfbUSjcx/8VtYL35Yp8kvl/HzLv/5HjMcPp0ocNhPv4v6yg
/xUZS5n/9yGr/e8XLrBw7bjvHINYVCRe7ndFkdf6X1FUNfJ/SS6VsaZYUlTIyblMdi0jYnwj
fQrDqZjEgRjFAfw8yJvDkeMy6FnEG4h9y+kg7AdhpmOLQWi8vjxdi2oy17T7LcexPARKx8cH
eTiGKu//fCnOqpJfj5AA9pyM2cBx4T1xmWnDK2p2ab9PXRgOnlvUNAasT7/zi0hYoOCZtkF5
UTrIj8YdyzSgN7YNbgosPe7Q8i9aYOOZPbasI013XXLLh56fEBdc2kfVEHEaVlrhyLWZV5DH
P7MHh4+CxiPeQ4BmOHZt5jXAGdj0O8zUHEb9iJdX1/rNu9bRKepy/ehJoU6EO+R9isRgY2JF
dTUypEfckDuglofOW6fv14dw/A9GiaAIL/Ypa/iVhz7Ix7Cxa8OHerP15aJ+efXlut54r7c+
B7ptRN0d3B3kMvmLJIX/PyQTZUjYn5D/FvwvV0oJ/5eLnP/lYsb/e5G983+yAmCMeWbHouAx
BBrgOdaYK8xzt4E9ejAfj9yssD1UTii+tyW1r+T2NeSOhi/T+wPw+28R/AzDb0fxnOO3IHm0
aBuaz99lVP+PSAr/Lzr/j1aATfxfLirx/u+kpALgb+Uk4/99yGb+Twj7lWN1PSCWBd9s5zv0
fC72oHMLJl5CcvF80lvgcMf22BKhaFDvfKUGk44hoOXCeUiZqIsk9fMOqYYz3BITCfqN0EbE
yrbLt+lttbrfhgUUoX26EvSiMQOqFQJkfiX0osahq824intZ97ALPYTpNR1qeiruqpn6pOvX
6U2N1KbXrdSm1qfQprWWv3wRW46G68JjwFJSnK3V4+IsIqxP6//Nh9iKwI7HvFRYZ9LbyHNz
GmsUau9mFCDdlsbNVs5sxj5PHg/p8JvmPBywEA9xT9upef4P5vAfkf39+R8qpXLE/6qsyv75
X7mc8f8+ZCX/c9rfYeIfZJx8/QA2oDDCBJ92wbTDtBSwvkt7ZGyxoCbtNCeI1lV5fnjz353h
8MR9ZXIfksmm+d+iHvsY3T4YDWya/8pJkv+VFL7/V+Vytv/fi6TO/4UN+FxkzO6/cW6EmaAW
pHH7WbcyeRjhfhWH06GV251s3v8l33/U4PuvrFay+b8PqT5D38OEuh6uE2eCIsoCUBv3fnwt
FcasV3giPDs/qHqaPhrhfCfBCR0q2Z7Wm54JA8ZGmiTZnki6ToeKhjOUeDxJqiw/FSLkEJGW
2XGJe7sI7ll0Kg2I5cRgbz3WGxH3WwyOWQu15jexx4gxbZOZPCOhZwIvC/hlqdqbak3DNUcM
b/LVR58vLvWW/hnLYTKTshkWFzP40y1U5s4tt1BY+kKVrhMkNdGx3VJ2xId7SLWrCbXZkTZx
zG54XEjEgK8xm1g45k/OTgVqC8GJYL6TwGPjVuGMGJd2dBig26cgSTC8hREGnWMTC3pk4oxd
k9HooLLd5m6SYj+FTrukuBa5fgR6vuuSl6HNr0/nVSmtbb2i2T0TiCAFgVEoQL0BhcJmlc79
VQxU4YNcGldVmptr57lMMskkk53IL+1rdHwAKgAA
--------------040306040506020604010608--