Hi there! > Florian, I know that the benefits of this solution. But I see the > detriments too. I think that if we allow that a app template > overwrite with self-reference another app template the template > development will be a chaos. I thought alot about it
Well, I agree that if miss used, this feature could be more of a burden than of
a feature. After giving it some thought, three possibilities come to mind. Here
they are, listed in what I think is from most to less preferable:
- Trust that the app developers aren't going to play nasty with it. Clear
miss use warning could be stated in the docs.
- Include (de)activation flags in the loaders. When, for example, the app
loader's flag is deactivated, no app could self-reference an other. For easy
of use, a subclass could be created for every loader class switching the flag
so that you could decide simply by (un)commenting loaders in settings.
- Change the "extends" template tag and add the possibility to provide kwargs
to it. Something like:
{% extends 'some/template.html' from app 'django.contrib.admin' %}
{% extends 'some/template.html' from dir 'some/template/dir' %}
"app" and "dir" here could be aliases defined as some loader's attribute. If
nothing specified, it could fall back to standard self-reference behaviour.
The positive part of this is that you could exactly decide what template to
extend. The negative one, that it is just a lot more of code on the template
layer and that it would (IMO) overcomplicate things.
My two cents! I'll work on the self-referencing code today and tomorrow.
Best regards,
Unai Zalakain
signature.asc
Description: PGP signature
