[Agavi-Dev] AgaviNumberValidator integer behavior in 1.0.3
David Zülke
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