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:

3 Likes

New version of django-template-partials v23.3 that incorporates all the feedback thus far is available now.

I wrote a small post covering the highlights.

https://noumenal.es/posts/django-template-partials-release/Jmv/

As I say there, I don’t think there’s anything more to do here – apart from see how it goes — until the Django 5.2 release cycle.

Thanks all for your input! :gift:

I watched your DjangoCon presentation about your django-templates-partials package and love it.

One little beautiful thing I noticed is that you use the fragment component of a URL (URI = scheme ":" ["//" authority] path ["?" query] ["#" fragment]), when you want to render only that. You also use that term in the title of this thread. I’m not sure if that was intentional or a little happy accident, but it fits quite well. Much better than partial, if I may say so :slight_smile:

1 Like

@doom Glad you liked it.

Hope you’re enjoying django-template-partials. (I have to say I am. There’s no way back for me now :stuck_out_tongue_winking_eye:)

Yep, naming :sweat_smile: Both terms are used in various discussions so IDK :woman_shrugging: