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 22:21:35 GMT
Hi,

> Well the conversion game from boolean to number is best *read* like this:
So on one hand with have 4 if statements (an extra error condition has been added) and a extra
variable vs a single line of code. IMO the single line of code is just as readable even if
it does uses casts.

Number(invalidFormat) + Number(invalidChar) + Number(incorrectFormat) + Number(wrongLength)
* 1.5

>  // I wouldn't use "count" as it doesn't mean anything
Take your point with "count" and I've renamed it.

> Actually double width characters can be typed in accidentally easily.
Currently the only case where this might occur would be for  validation of a from by a Japanese
user for a locale with alpha numeric postcodes (eg Canadian postcodes). I guess that while
unlikely is possible. May require changes to the Validator base class I'll look into it.

> However: This "validator" usually sits in front of a server-side validation - right?
Some server-side validation accepts full width, some doesn't. It should optional.
Validatiors don't do any data conversion that just say if it is valid or not. I'll give some
though on how to have wide characters optional.

> How about using the character "N" instead of "N" to check for double width numbers
The combination of formats you would have to supply would be too large. eg "NNNN" would expand
in 13 odd combination of N and wide N's (assuming mixed normal and wide format characters
are valid).

Currently the existing mx validators do not support wide characters so anything to support
that  would be a bonus.

> Typo on my part: I will *note* a refactoring of the current signatures :)
They currently work and until we have tests and see what coverage they give I'm very reluctant
to make any changes to them. While we as programmers may care about how the code is written
(and for many good reasons) the users of the SDK just want to it work and for it not contain
any surprises.

> I have never had that problem without the "@private" statement but I admit that I started
from a late version of flex to use asdoc.
It's how the methods are marked up in the existing classes so I don't see a need to change
it. I'll see if I can get ASdocs to generation from these new classes cleanly.

Thanks,
Justin


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message