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 "Ｎ" 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
