#24338: {%extends%}-ing a file-based template object is broken by deprecation
path
indirection
---------------------------------+--------------------------------------
Reporter: spectras | Owner: nobody
Type: Uncategorized | Status: new
Component: Template system | Version: 1.8alpha1
Severity: Normal | Resolution:
Keywords: template | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Comment (by spectras):
I do not control that, as I am working on a library module.
The user-code defines the parent template, and may override none to all of
the templates as the developer sees fit. Therefore, all of the following
may happen:
* they completely override the template (child template does not extend
anything). Point is moot.
* they use django template engine and extend the parent template specified
in the context.
* they use some other template engine that also supports inheritance, and
still want to extend the parent template specified in the context.
For this reason I cannot know what engine is used, and I believe I should
not know at this stage anyway.
For now, I resorted to the exact same hack you just linked, only using
duck typing:
{{{#!python
if hasattr(context['base_template'], 'template'):
context['base_template'] = context['base_template'].template
}}}
But it is not unthinkable to allow extending templates across languages.
As long as they both have the concept of inheritance of course. I
seriously doubt the utility would warrant the effort though.
Anyway, this is beyond this issue. The issue here is I have to either add
a hard connection to a specific template engine in the view, forcing the
developer to inherit and override it if they use another template engine;
or not use inheritance at all. Both options are inconvenient to the user,
and the very existence of this hack shows the inherent possibility to make
it work cleanly.
To the very least, I believe {%extends%} should be able to receive the
result of '''get_template''' and not choke on it when it is indeed a
Django template.
That would have the added benefit of not breaking all the projects that
fed {%extends%} some preloaded templates before version 1.8.
And of course, it would allow third-party modules to manipulate templates
in an agnostic way, which I believe was the point of the new templating
system.
--
Ticket URL: <https://code.djangoproject.com/ticket/24338#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.4ba451d3b38643f129e349e35f838ada%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
