#6378: Capture arbitrary output as a template variable
---------------------------------+--------------------------------------
Reporter: Kenneth Arnold | Owner: Carl Meyer
Type: New feature | Status: new
Component: Template system | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Changes (by Sébastien Corbin):
* cc: Sébastien Corbin (added)
* resolution: wontfix =>
* status: closed => new
Comment:
> I guess "wontfix" is the best resolution since we didn't really address
the issue directly as described in the original description.
Allow me to reopen this since the original issue has not really been dealt
with.
I made a summary of the arguments found in this issue, and
[https://forum.djangoproject.com/t/adding-template-fragments-or-partials-
for-the-dtl/21500/23 in this discussion] as well, with some additions from
myself after [https://github.com/wagtail/wagtail/discussions/12135 coming
from this]:
- it is a simple tag in terms of implementation, hence that should not be
complex to maintain
- [https://code.djangoproject.com/ticket/6378#comment:12 it solves simple
situations] where an `{% include %}` tag would maybe be too much
- it allows to factorize and reuse a variable, scoped to the current
template (preserving template directory cleanness)
- `{% tag_name as var %}` (previously
[https://code.djangoproject.com/ticket/14262 known as assigment_tag]),
does not solve complex (conditional) blocks
- `{% include %}` or `{% with %}` can't even solve everything, e.g.
making a variable from a complex (eg: conditional, multiline, etc.) block
that can be passed to `{% blocktranslate %}` afterwards
{{{
{% fragment as script_textarea %}
<div>
<textarea {{ copy_attrs }} rows="4"><script>const sc =
document.createElement("script");sc.setAttribute("src", "{{ FRONT_BASE_URL
}}{% static 'overlay.js'
%}");document.head.appendChild(sc);</script></textarea>
{% if something %}
some contextual text
{% endif %}
</div>
{% endfragment %}
<div class="w-help-text">
{% blocktrans with settings_url=settings_url
script=script_textarea trimmed %}
After <a href="{{ settings_url }}" target="_blank">adding your
site as allowed to display the overlay</a>,
add the following script tag to your site (preferably in the
<code><head></code> tag):
{{ script }}
then add a link to your page with the CSS class <code>overlay-
button</code>, for example:
{% endblocktrans %}
</div>
}}}
- in a [https://code.djangoproject.com/ticket/6378#comment:17 MVT
paradigm], the manner to render HTML should be independent from the data
sent by the view
- no business should be put in the template
- but no HTML in the view either, and calculation logic may be too
nested to be put in the view
- even [https://code.djangoproject.com/ticket/6378#comment:28 if it could
solve this,] `{% blocktrans %}` is meant for translation, not reusing HTML
- although I would retain some of the blocktranslate arguments, like
`trimmed`
- make some code more readable, for example, do we prefer:
{{{
{% dialog id="modal-cell-"|add:column.name|add:"-row-"|add:row.index
title=column.label classname="large" %}
{{ dialog_content }}
{% enddialog %}
}}}
or
{{{
{% fragment as dialog_id %}modal-cell-{{ column.name }}-row-{{ row.index
}}{% endfragment %}
{% dialog id=dialog_id title=column.label classname="large" %}
{{ dialog_content }}
{% enddialog %}
}}}
- it can work just fine as an
[https://code.djangoproject.com/ticket/6378#comment:11 external template
library]
- it already exists in the contrib community, for example :
[https://pypi.org/project/django-capture-tag/ django-capture-tag],
[https://github.com/mixxorz/slippers/blob/645bbaa5a9b6f0c50c5c7fae14c39dce633c3b8f/slippers/templatetags/slippers.py#L264
django-slippers],
[https://github.com/wagtail/wagtail/blob/98705762bf4385c40e3560ba7ee35c102281c051/wagtail/admin/templatetags/wagtailadmin_tags.py#L972
wagtail admin],
[https://github.com/rafalp/Misago/blob/7109be43d6123752241d4119f34f0a3d29d8e7c5/misago/core/templatetags/misago_capture.py#L17
misago], [https://github.com/nathanborror/django-basic-
apps/blob/master/basic/tools/templatetags/capture.py django-basic-apps],
[https://github.com/Nigel2392/globlocks/blob/00d259d83caed8a42d1a77ea561baa3991b12f32/globlocks/templatetags/globlocks/__init__.py#L147
globlocks], [https://github.com/unfoldadmin/django-
unfold/blob/c7dbd1cbc375c10ef7f11565343ceccb5a9feaf3/src/unfold/templatetags/unfold.py#L95
django-unfold], [https://github.com/PragmaticMates/django-
pragmatic/blob/89bf7ecc64f36292c27d41ee19d56804973b364f/pragmatic/templatetags/pragmatic_tags.py#L435
django-pragmatic], [https://github.com/lukasvinclav/django-
nucleus/blob/f25c6d517ff0ecff0a3e50aa07d815f5b0e0e7ae/nucleus/templatetags/nucleus_tags.py#L42
django-nucleus], a non-exhaustive list not counting non-community-oriented
projects or boilerplate/template projects
- having it in core would mean reducing code duplication across the
ecosystem
- that would make [https://code.djangoproject.com/ticket/6378#comment:21
DTL turing-complete], but that argument is disputable, at the end it is a
matter of what the template designer choose to do
- Jinja [https://jinja.palletsprojects.com/en/3.1.x/templates/#block-
assignments allows this], use Jinja
- yes, but jinja is not always the choice made at the beginning of a
project, and that argument could be further pushed to "why DTL at all?"
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:31>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701910e43942a-da42cad0-d724-456f-a37c-6e5bcad16b6c-000000%40eu-central-1.amazonses.com.
