#17419: Add a JSON template filter
-----------------------------------+-------------------------------------
Reporter: lau | Owner: aaugustin
Type: New feature | Status: new
Component: Template system | Version: master
Severity: Normal | Resolution:
Keywords: json template tag | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+-------------------------------------
Comment (by natevw):
The suggested patch has rather surprising behavior to me, with its custom
escaping. Normally an HTML attribute is the *best* place to put JSON-
formatted data:
- plays nicely most template language's default HTML escaping (i.e. the
usual `"` behaves correctly)
- provides a safe place for data to live _as data_, rather than as code
- just as easy to get to from an external script file as an inline one
- assuming it is placed in a `data-` attribute (as it should be), access
can still be very convenient:
{{{
<script type="x-data/x-config" id="variables" data-my-info="{{
info|to_json }}">
<script>
// with jQuery
var myInfo = $('#variables').data('myInfo');
// without, one simple option
var myInfo =
JSON.parse(document.getElementById('variables').getAttribute('data-my-
info'));
</script>
}}}
Obviously this is very different usage than intended by django-argonauts,
as evidenced by the examples [https://github.com/fusionbox/django-
argonauts/blob/593656e710b6aca3ca15368b2ca7cd1cae655b47/README.rst their
current README], which are using the output as JavaScript literals
directly within an inline script.
The argonauts approach isn't necessarily wrong, but feels more like its
intended to be used as "generate some JavaScript" tag rather than one for
"output JSON content [safely in an HTML context]". Granted, the former
(inline JavaScript) could very well be what many developers want, and the
latter (HTML-safe JSON) ends up being a bit of a pain anywhere *but* in an
attribute.
Hopefully my 2ยข on an alternative consideration is helpful feedback.
There's certainly some irony in proposing a solution that only works one
place, up against a solution that is convenient everywhere *except* that
same place where it happens to be unsafe. For me it was a tradeoff: fully
escaped output is _safe_ anywhere it ends up. Unfortunately it's only
_useful_ when extracted from an attribute value, but that's a habit I was
willing to settle on; I can use the same pattern across pretty much any
platform's template engine. YMMV.
--
Ticket URL: <https://code.djangoproject.com/ticket/17419#comment:25>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/061.eb40cae15062c5a04b41740bd8d84577%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
