Hi @carltongibson,
I’m applying to GSoC 2025 and I’m interested in the django-template-partials integration project. I have drafted a proposal, available here, and would appreciate any feedback before submitting it to my application!
Looking forward to contributing to this amazing framework!
Hi @loop-index — thanks for the proposal.
It’s a perhaps a little schematic still. You might want to go into more depth before submitting. (It’s targeting a 350hr project — I think that’s realistic, but, if it’s just copying some code and tests, how’s that the case?)
I was interested by your stretch goal… I’ve always considered partials being local to the template they’re defined on as being part of the idea, so resolving the linked ticket there would be a documentation thing. (Rather than needing a code solution.)
HTH
Thank you for the feedback! I understand how this might not look a whole lot like 350 hours, however, I am also struggling to come up with tasks outside of the main porting + merging. template-partials is already small code-wise and well-defined, so I figured that this integration would not spread in scale. Without venturing into out-of-scope land, what direction may you suggest me look deeper into?
I’m also interested in your decision to keep partials local - I understand that Locality of Behavior is the philosophy driving this package in the first place. However, you should still be able to include partials from the base template - I would imagine partials inheritance to be opt-in. Is it just a conventional choice or is there deeper reasonings (performance overhead,…) for it?
I think there’s more in the details of the port for an observant eye. I don’t want to tell you what I think here: I want to see if someone thinks similar themselves. (I’m hoping that one or two proposals will clearly stand out from the crowd.)
There’s more in the documentation than anyone yet has mentioned.
Ref the Why… — A good API will guide you in its usage — it will have a grain. (Being such is one of the main reasons Django has been so successful. That’s why folks are vested in not undermining that.)
Partials have proven to be a kind of missing abstraction for the DTL — they’re wonderful, and I wouldn’t go back to not having them. Having partials as template local gives clear guidance as to where they should (must) be defined. They’re not includes (though they’re compatible with includes), and they’re not blocks. If I can suddenly be using a partial from a parent template then it seems like freedom. More likely it’s chaos. Or such. (That’s schematic, I know.)
Thank you for the clarification! Lots of interesting insights here.
Re: Partials being local, I think that is a reasonable viewpoint. Using includes to use partials from parents is indeed more explicit than magically pulling it out of nowhere. But perhaps for some it’s a bit unclear on the view layer to fetch “base.html#fragment” on a child view for example. Should there be a (default off) switch for anyone wishing to experiment with that chaos?
I’m going to smile and say no. The APIs job is to guide you into correct usage. Toggles are a cop-out. 