#30134 closed Bug (fixed)
Geodjango js template should use `|safe` for float values to avoid DECIMAL_SEPARATOR ruin the js syntax
Reported by: | Sassan Haradji | Owned by: | Claude Paroz |
---|---|---|---|
Component: | GIS | Version: | 3.1 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
contrib/gis/templates/gis/admin/openlayers.js
should use |safe
on float values to avoid DECIMAL_SEPARATOR (and probably other settings in this category) ruin the js syntax by adding unexpected characters instead of dot.
Change History (14)
comment:1 by , 6 years ago
comment:3 by , 6 years ago
Has patch: | set |
---|---|
Needs tests: | set |
It looks to me like {% localize off %}
is meant to prevent formatting of the value. Can you add a test that demonstrates how the issue happens?
comment:4 by , 6 years ago
localize off
turns off l10n
(look at django/templatetags/l10n.py
) in my case l10n
is already turned off in my settings.
When DECIMAL_SEPARATOR
is manually set in settings, localize off
has no effect on it, look at this comment copied from line 117 of django/utils/formats.py
:
# The requested format_type has not been cached yet. Try to find it in any
# of the format_modules for the given lang if l10n is enabled. If it's not
# there or if l10n is disabled, fall back to the project settings.
fall back to the project settings, means falling back to DECIMAL_SEPARATOR
(and other settings in its family). But just cause I set a custom value for DECIMAL_SEPARATOR
doesn't mean gis should break on my django admin.
comment:5 by , 6 years ago
I think that for your use case, it would be better to activate l10n for your project and provide a custom format file (https://docs.djangoproject.com/en/stable/topics/i18n/formatting/#creating-custom-format-files). Is there anything preventing you applying this suggestion?
comment:6 by , 6 years ago
I don't know if something is preventing me applying this suggestion or not, I may be able to apply it, but it doesn't change the fact that setting DECIMAL_SEPERATOR
should not break js syntax in js templates in no circumstances. Currently settings DECIMAL_SEPARATOR
breaks above mentioned js template regardless of the value of L10N
(False
or True
).
comment:7 by , 6 years ago
This may be a documentation issue, we could warn that using the l10n
framework and maybe custom format files should be preferred over setting the global DECIMAL_SEPARATOR
which cannot be selectively deactivated with l10n
filters/tags.
comment:8 by , 6 years ago
If gis is not supposed to work with DECIMAL_SEPARATOR
set in global settings file, then this is indeed a documentation issue rather than a bug. But I think there's room for improvement here, current behavior even if documented is counter intuitive, because developer doesn't know necessarily about internals of gis admin panel and doesn't expect setting DECIMAL_SEPARATOR
to break it. Documenting this would be appropriate if it were some random php framework, but even if documented this behavior of setting some settings breaks another completely unrelated thing is not something I've ever seen in Django in my +9 years experience with it. I think what would be acceptable is one of these options:
- Remove/Deprecate things like
DECIMAL_SEPARATOR
in settings completely, if it's not something fully supported lets not have it when there are better alternatives that doesn't break things and do the same job (format files.) - Support
DECIMAL_SEPARATOR
and similar settings "completely" which means solving the issue described in this ticket and other possible problems settingDECIMAL_SEPARATOR
may cause.
comment:9 by , 6 years ago
I would be tempted to go the DECIMAL_SEPARATOR
deprecation route, but I may completely miss some real use cases...
comment:10 by , 6 years ago
Triage Stage: | Unreviewed → Accepted |
---|
I guess the ticket should be accepted, even if the path toward resolution is unclear. I think deprecating USE_L10N
and the corresponding formatting settings in favor of locale formatting files would simplify a lot of things, but I'm not knowledgeable enough on the ramifications to put together a proposal.
comment:11 by , 4 years ago
Needs tests: | unset |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Version: | 2.1 → 3.1 |
Fixed here: https://github.com/django/django/pull/10896