Adding template fragments or partials for the DTL

@carltongibson perhaps we’re talking about different things? The fragment tag I mentioned as an example is on the order of 20-40 lines of code, 90% of which are DTL tag declaration boilerplate (see fragment in Wagtail tags. That doesn’t strike me as something that would be hard to land (I’d happily make a separate proposal and PR for it if there’s interest).

AND I don’t want to turn the DTL into Jinja — just use Jinja is a legitimate position

Personally I’d recommend considering the aspects of Jinja (or any similar language) that DTL could benefit from regardless of whether Jinja is supported or not. As a dev, Jinja is only an option if you happen to be starting a new project and have enough of a say in the tech stack to go that way. The power of defaults and the inertia of existing software means there’s lots of devs who will benefit from small improvements to the template language in ways that stay compatible with their existing setup.

Hey @thibaudcolas,

I’d be in favour of some kind of capturing tag. See Django #6378 — that we’d have to re-open. It’s on my backlog to have that discussion but I see it as orthogonal to having named sub-templates (trying to avoid both “partials” and “fragments” in this sentence). Happy if you want to champion that discussion before I get there! :+1:

perhaps we’re talking about different things?

Likely :sweat_smile:

I was reacting to this: {{ forms.input('username') }} — at that point I’m (literally) Just use Jinja. (It’s perfectly feasible to migrate incrementatlly IMO) But (again IMO) it’s worth pulling whatever you need there back into Python, in the form of a custom tag, which is how the DTL will guide you…

Happy to discuss concrete cases, so we’re on the same page, rather than not!

1 Like

:+1: gotcha, yes, I shared forms.input('username') because it’s an example of a template exporting things for reuse. I wasn’t advocating for the Jinja-style macros calling we can see in that example – there’s a place for that but it’s a stretch well beyond what you’re proposing with reusable inline template partials.

1 Like

I’ve opened a ticket and PR with a first pass at the minimal first step here:

If we could merge this then django-template-partials would at least be using actual API. :sweat_smile:

1 Like