Provide new template tag to capture internal block output as a template variable ("simple block tag").

[Jake Howard]

Django's template system allows creating custom tags, but they don't allow taking content:

{% mysimpletag foo="bar" %}

However there are plenty of use-cases where it'd be useful to also collect content along with the tag, turning it into a "block" tag:

{% mysimpletag foo="bar" %}
  This content gets captured too
{% endmysimpletag %}

This currently requires using complex internals of the template system (some documented, some not) to achieve. The ​cache tag is a good example of this kind of "simple" block, which requires some parser internals.

I propose adding a @register.simple_block method to allow easy registering of custom block tags. The API would be similar to simple_tag, however with a required content argument containing the (rendered) template content:

@register.simple_block(takes_context=True)
def mysimpletag(context: Context, content: str, foo: str) -> str:
    return f"foo = {foo}"

(Types added for reference)

I have a working demo of this I can push up.

[Sarah Boyce]

Hi Jake👋 thank you for raising this, I can see why this could be useful.

For a feature request to be accepted, we want to see some discussion on the ​forum first to confirm/validate the feature with the community and get some feedback.
I'll close the ticket for now, but if there is a community agreement for this, you are welcome to come back linking the forum topic, so we can then re-open it.
For more details, please see ​the documented guidelines for requesting features 👍

[Jake Howard]

For now, I've now raised this on the forum: ​https://forum.djangoproject.com/t/feature-proposal-simple-block-tag/32229. Will collect feedback, and then return!

[Jake Howard]

Following a few conversations on the forum thread, I've opened a [PR ​https://github.com/django/django/pull/18343].

[Natalia Bidart]

Thank you Jake for following up on this. I think the forum post shows enough agreement, and I personally also think this is a useful adding. I also agree with related comments from #6378, specifically:

I do think there are cases where the "capture" model is the appropriate one, and it ought to be built-in.

I considered reopening #6378 and closing this as a dupe, but I decided not to because the older ticket is a bit confusing in how the problem is described because there is a mix of requirements which some were solved by #18651.

[Natalia Bidart]

Hello Sushmita Palikhe! Thank you for your interest in contributing to Django, but this ticket is already owned by Jake and their work is still active.

[Jake Howard]

Yes, definitely still active. The draft PR is linked above though, and I'd definitely welcome any comments / suggestions you may have.

[Sarah Boyce]

Note that #6378 was recently closed as a duplicate to this ticket.

[Jake Howard]

I do think there are cases where the "capture" model is the appropriate one, and it ought to be built-in.

Currently, the simple block is added with a related implementation. It should be simple enough to use it to implement a capture tag, but I wasn't going to add it to the existing PR to avoid scope-creep. I can if you think it'd be better?

[Carlton Gibson]

@Jake I’d keep the scope as is. Let’s let folks build with the new tag (IMO)

[Natalia Bidart]

I gave this another top-bottom pass. Once the minor nitpicks are fixed, I need to do a in-depth review in terms of test coverage and functionality.