Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#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:3 by Tim Graham, 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 Sassan Haradji, 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.

Last edited 6 years ago by Sassan Haradji (previous) (diff)

comment:5 by Claude Paroz, 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 Sassan Haradji, 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).

Last edited 6 years ago by Sassan Haradji (previous) (diff)

comment:7 by Claude Paroz, 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 Sassan Haradji, 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:

  1. 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.)
  2. Support DECIMAL_SEPARATOR and similar settings "completely" which means solving the issue described in this ticket and other possible problems setting DECIMAL_SEPARATOR may cause.

comment:9 by Claude Paroz, 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 Tim Graham, 6 years ago

Triage Stage: UnreviewedAccepted

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 Mariusz Felisiak, 4 years ago

Needs tests: unset
Owner: changed from nobody to Claude Paroz
Status: newassigned
Version: 2.13.1

comment:12 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In 51250d2f:

Refs #30134 -- Added test for {% localize off %} tag with format settings.

comment:13 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

Resolution: fixed
Status: assignedclosed

In 9e57b1e:

Fixed #30134 -- Ensured unlocalized numbers are string representation in templates.

comment:14 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In 810e656a:

[3.1.x] Refs #30134 -- Added test for {% localize off %} tag with format settings.

Backport of 51250d2f123b694ab7e09c119cb72d4878266688 from master

comment:15 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In acaa2015:

[3.1.x] Fixed #30134 -- Ensured unlocalized numbers are string representation in templates.

Backport of 9e57b1efb5205bd94462e9de35254ec5ea6eb04e from master

Note: See TracTickets for help on using tickets.
Back to Top