Add localization support for all number fields (Issue #4584) #4586
Conversation
…r, Float,Decimal) that handles a localize and coerce_to_string parameter as it was done in the DecimalField. Add API settings to handles default values.
| @@ -873,20 +875,28 @@ def to_internal_value(self, data): | |||
|
|
|||
| # Number types... | |||
|
|
|||
| class IntegerField(Field): | |||
|
|
|||
| class NumberField(Field): | |||
There was a problem hiding this comment.
The change footprint of this pull request is fairly large given that it introduces a new base class here. I'd be interested in seeing the equivalent pull request without introducing a new base class. We could then consider if we want a NumberField as a separate feature request, since that's really a different issue to numeric localisation support.
There was a problem hiding this comment.
Not sure I clearly understand what you mean... You'll prefer that I just patch the FloatField (which is the starting point of the localization problem) to work like the DecimalField with possible code duplication than using a new base class? I agree that will have a lower impact and it could be a less "risky" change. Do I understand right?
There was a problem hiding this comment.
That's right, yup. We could consider a new base class, but that's a separate issue.
tomchristie
modified the milestones:
3.5.4 Release,
3.6.1 Release,
3.6.2 Release,
3.6.3 Release
|
Closing in favor of #4925. |
Description
Full description of the issue can be found here: Issue #4584.
The goals of this pull request is add the localize and coerce_to_string parameters, which are available with the DecimalField, to the IntegerField and the FloatField.
By creating a base NumberField, with this patch, now all number fields can generate localized string values as representation, and can parse localized numbers by sanitizing the text input the same way it was done in the DecimalField.
refs #4584