Hello everybody,Agavi 1.0.3-RC1 comes with a bunch of changes, fixes and enhancements to the number validator.
One of them may require further discussion, so I'm asking for your input here.
At the moment, AgaviNumberValidator (the shortcut "number" sets the "type" parameter to "int") accepts:
- integers when "type" is "int" - integers and floats when "type" is "float" - integers and floats for all other values of "type"Since 1.0.3-RC1, it also performs a cast to the given "type" unless "cast_to" is defined.
The rationale for also allowing integers when "type" is "float" is that an integer is a subset of "floats", in a more accurate representation.
However, no floats are accepted when "type" is "int", even when they could be converted to an int without loss of precision; i.e. "1.00" will be rejected when "type" is "float".
This is a change from previous versions of Agavi, where "1.00" was accepted as an "int", but *only if* the number was parsed without locale awareness, i.e. without translation on or with parameter "no_locale" set to true.
Clearly, that behavior was inconsistent, and is now changed. The question is... should we keep it this way, or should we allow "1.00" and friends to pass as "int"?
I'm leaning towards keeping the stricter behavior now. The only reason I could see is people with legacy systems that expect integers, but in float representation. It wouldn't be possible to accept these values anymore. But that's probably a minority, and they could always write their own validator for this case.
Looking forward to your input, - David
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Agavi Dev Mailing List [email protected] http://lists.agavi.org/mailman/listinfo/dev
