incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: [Proposal] Add PostCodeValidator and PostCodeFormatter to the SDK
Date Sat, 10 Mar 2012 03:22:17 GMT
Hi,

> Couldn't you just use var invalidFormat: Number = 0 or 1 ?
I could but then I would be casting a Number to boolean on the other fields.

>>> *) You mix "brace in new line" (left) with "brace in current line" (right), afaik
its in the current line.
> PostCodeValidator - 499 & 513 just as one example
Think I've fixed them all. When some work is done of the Flex formatter I'll run the code
through that.

> Personally I see bad sides in the one with the missing else ... however: again: What
did the Flex Gui
The SDK code is inconsistent in this case and uses both forms.

> 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 think the readability is fine and it has been improved in the latest checked in version.

> The question is how this util is defined
Personally it more how people want to use it, standards are only as good as how much they
are used eg country code should in some cases be used in postcodes but is generally ignored.
I've added support and test cases for it.

> This is a big problem for all number validation in japan. Oh: They also have double width
A-Z ABC...XYZ: try to build a search engine around that!
May need to support that down the track if any country postcodes contain alpha characters
and use wide characters. Currently I'm not aware of any.

> I see thanks! And thinking about it further: shouldn't the "result" have a error-weight?
To be compared with other errors?
It could be. By default only the first error is shown to the user when validating forms and
the like. Also none of the other validators do that.

> 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 think it does need to be consistent with the current validators. Forms will often use a
variety of validators and often place them into a single array so the entire form can be validated
in one go. Having them all work and look the same makes them easier to use.

> I attached three examples how it think it could work else. All have less dependencies
and better performance.
Better performance is not really an issue here - how fast do you need to validate a post code
as a use types?

> Then my question would be: Why is it private?
It's not private it's public the "@private" comment is for the documentation so it handles
setters and getters correctly.

Thanks,
Justin
Mime
View raw message