The project I'm working on uses a NumberField to solicit input for a "stock inventory" field. The form object's validation enforces NotBlank and Min(0) on the property.
I noticed an edge case where entering some non-numeric value (e.g. "asdf") into the field resulted in the object being saved with zero inventory. I traced the behavior of NumberField and realized that as its transformer uses NumberFormatter <http://php.net/NumberFormatter>, boolean false is returned when reverseTransform() attempts to parse the field input into a value to bind. My object/schema resulted in boolean false being cast to zero. I'm curious if NumberField is only intended to provide formatting convenience (w/ its transformer), or if it'd benefit by having an implied Numeric constraint. I suggest a constraint for the field class because I'm fond of casting scalars in my setter methods to their expected types. The case of the formatter returning false as its error case is also more in the realm of NumberField and its transformer than my model. Even in the former case (no implicit constraint on the field), I think a Number constraint would be useful to require numeric values, implement min/max and optionally enforce something like precision. Min/Max constraints currently exist, but using them both on the same field/property can lead to duplicat errors (they each error out if the field is not numeric) - allowing a Number constraint to also handle min/max would consolidate such errors. Thoughts? -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
