Re: [Django] #6378: Capture arbitrary output as a template variable
Django
-------------------------------------+-------------------------------------
Reporter: kcarnold | Owner: nobody
Type: New | Status: closed
feature | Component: Template system
Milestone: | Severity: Normal
Version: SVN | Keywords:
Resolution: wontfix | Has patch: 1
Triage Stage: Design | Needs tests: 0
decision needed | Easy pickings: 0
Needs documentation: 1 |
Patch needs improvement: 1 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by carljm):
* status: new => closed
* ui_ux: => 0
* resolution: => wontfix
* easy: => 0
Comment:
This needs a stronger use-case justification. Many of the use-cases for
this are indications that the template should be re-structured, or an {%
include %} could be used instead. Capturing output like this is yet
another entirely different mental model for organizing and reusing
template code, and we already have at least two of those - we need strong
justification to add another to core (especially since it can work just
fine as an external snippet/library).
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: kcarnold | Owner: nobody
Component: Template system | Version: SVN
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 1
Easy pickings: 0 | Patch needs improvement: 1
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anonymous):
Does this justify as a general use-case?
{{{
{% capture as subject %}
{% if user = request.user %}My{% else %}{{ user.first_name }}'s{%
endif %}
{% endcapture %}
...
<div id="profile-photo">
My Photo
<img />
</div>
...
<div id="profile-friends">
<h3>{{ subjects }} Friends</h3>
List of friends...
</div>
<div id="profile-groups">
<h3>{{ subjects }} Groups</h3>
List of groups...
</div>
<div id="profile-friends">
<h3>{{ subjects }} Friends</h3>
List of friends...
</div>
...
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: kcarnold | Owner: nobody
Severity: Normal | Resolution:
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 1
Easy pickings: 0 | Patch needs improvement: 1
| UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => reopened
* resolution: wontfix =>
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:13>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 1
Easy pickings: 0 | Patch needs improvement: 1
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by anonymous):
* owner: nobody => carljm
* status: reopened => new
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:14>
Django
Type: New feature | Status: new
Component: Template system | Version: SVN
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
Changes (by carljm):
* stage: Design decision needed => Accepted
Comment:
I've changed my opinion on this; I do think there are cases where the
"capture" model is the appropriate one, and it ought to be built-in.
Particularly in cases like the above example, where a non-trivial block of
template should be repeated. Inheritance doesn't support this. Includes
could be used, but impose a significant performance penalty, both for
doing the include and because the repeated block has to be evaluated
multiple times. Otherwise you're reduced to a custom template tag.
Marking accepted, pending any argument from other core developers :-)
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:15>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: SVN
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
---------------------------------+------------------------------------
Comment (by aaugustin):
The use case doesn't seem that compelling to me — the logic calculating
"subject" /could/ be handled in the view.
That said, I don't have a strong opinion on this feature.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:16>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: SVN
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
---------------------------------+------------------------------------
Comment (by carljm):
Replying to [comment:16 aaugustin]:
> The use case doesn't seem that compelling to me — the logic calculating
"subject" /could/ be handled in the view.
It could be, but it shouldn't be. Display logic in the view is ugly, just
like business logic in a template. And HTML in strings in the view is even
uglier.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:17>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: SVN
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
---------------------------------+------------------------------------
* cc: charette.s@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:18>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
Comment (by aaron@…):
Another use-case
cmsplugin_zinnia/templates/cmsplugin_zinnia/entry_detail.html:
{{{
{% load i18n placeholder_tags %}
{% for entry in entries %}
{% captureas content %}
{% render_placeholder entry.content_placeholder %}
{% endpatureas %}
{% with object=entry object_content=content continue_reading=1 %}
{% include "zinnia/_entry_detail.html" %}
{% endwith %}
{% empty %}
<p class="notice">{% trans "No entries yet." %}</p>
{% endfor %}
}}}
This is because rendering entry.content_placeholder generates sekizai_tags
that need to get picked up.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:19>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
* cc: oss@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:20>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
* cc: cmawebsite@… (added)
Comment:
This would make the template language turing-complete. I would use it.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:21>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
* cc: loic84 (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:22>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
Comment (by anonymous):
Any work on this ?
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:23>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
* cc: cmawebsite@… (removed)
Comment:
Btw, if we did this, we would need to remove the line in philosophy docs
about intentionally not allowing assignment to variables.
https://docs.djangoproject.com/en/dev/misc/design-
philosophies/#don-t-invent-a-programming-language
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:24>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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 collinanderson):
* cc: cmawebsite@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:25>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
Comment (by prestontimmons):
Isn't the assignment to variables line kinda wrong anyway? Most template
tags accept the "as" argument, and the with tag also assigns variables,
albeit in a scoped manner.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:26>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
Comment (by dracos):
Repeated includes hopefully no longer impose a significant performance
penalty since #23516, and blocktrans has a variable setting argument since
#21695, which was a reason given for this functionality (see e.g. similar
#14078).
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:27>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Type: New feature | Status: new
Component: Template system | Version: master
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
---------------------------------+------------------------------------
Comment (by collinanderson):
Fascinating. It sounds like #21695 actually solves this ticket, doesn't
it? The blocktrans tag should take care of any use case here, right? You
just need to do a null translation?
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:28>
Django
---------------------------------+------------------------------------
Reporter: kcarnold | Owner: carljm
Component: Template system | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
Also #18651 enables optional assignments for `simple_tag()`.
I guess "wontfix" is the best resolution since we didn't really address
the issue directly as described in the original description.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:29>
Django
Reporter: Kenneth Arnold | Owner: Carl Meyer
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
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 Carlton Gibson):
* cc: Carlton Gibson (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:30>
Django
---------------------------------+--------------------------------------
Reporter: Kenneth Arnold | Owner: Carl Meyer
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
* 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.
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
---------------------------------+--------------------------------------
Reporter: Kenneth Arnold | Owner: Carl Meyer
Type: New feature | Status: new
Component: Template system | Version: dev
Severity: Normal | Resolution:
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
* stage: Accepted => Unreviewed
Comment:
Grrr, reopening a ticket after 9 years without a clear consensus first
being reached is pretty strong. Ideally that would have happened on the
Forum first. (If I were still Fellowing I would re-close and insist on
that.
I'm going to mark this as Unreviewed so the Fellows get to see it,
otherwise there's a danger it just sits here as Accepted.
I'm (on the record as) leaning towards doing something here — it DOES keep
coming up — but it's at least related to the new #35535, which has a PR,
and for which the Forum discussion linked back here too, so there's some
Triage to be done as to whether there's a separate ticket to be
implemented here too or not.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:32>
Django
---------------------------------+--------------------------------------
Reporter: Kenneth Arnold | Owner: Carl Meyer
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
* resolution: => duplicate
Agree that work here is supersede by #35535 and so closing as a duplicate.
--
Ticket URL: <https://code.djangoproject.com/ticket/6378#comment:33>