#24425: Cross Backend template includes are not supported
---------------------------------+--------------------------------------
Reporter: phalt | Owner: nobody
Type: Bug | Status: closed
Component: Template system | Version: 1.8beta1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Changes (by aaugustin):
* status: new => closed
* resolution: => wontfix
Comment:
Replying to [ticket:24425 phalt]:
> Attempting to render Jinja templates with an include tag in a Django
template results in the Django template backend parsing the jinja
template.
That's the intended behavior. The support for multiple template engines
was designed that way because it isn't possible to mix arbitrary templates
engines in general.
> This used to work fine as the `IncludeNode` that powers the include tag
would search using all configured loaders but since 1.8 it has changed to
maintain the current engine context.
I'm not really buying this argument. Django 1.7 didn't have built-in
support for Jinja2. Perhaps it worked with some third-party library, but
as far as Django is concerned, the `{% include %}` tag was never
documented to load anything other than Django templates.
> This seems like an obvious behaviour to want
To me this seems like an obvious behavior not to want because it isn't
symmetrical. Unless I missed something or you're using a library I don't
know about, you can include Jinja templates from Django templates but you
can't include Django templates from Jinja templates. I wouldn't call this
asymmetry obvious.
> and we've relied on it heavily while porting our templates from Django
to Jinja2 but this is now blocked by this change in 1.8.
I'm sorry, but I disagree with some aspects of the design of the third-
party library I suspect you're using. Switching from that library to the
built-in support requires some changes.
In my opinion, the correct design for your use case is to implement a `{%
jinja2_include %}` tag that makes it explicit that you're switching
engines. It appears that you're identifying templates by their file
extensions. It shouldn't be too hard to implement such a tag and run a big
replace-all to use it wherever necessary.
One of the goals of refactoring the template engine was to make it a
standalone library. It works without Django settings. The `{% include %}`
tag cannot know which template engines are configured without breaking
this property. That's another reason for preferring a distinct `{%
jinja2_include %}` tag.
For all these reasons, I'm rejecting the idea of changing the behavior of
the Django template language's `{% include %}` tag.
If you aren't convinced and you want to continue this discussion, I
recommend taking it to the django-developers mailing-list in order to get
a wider audience. Thanks !
--
Ticket URL: <https://code.djangoproject.com/ticket/24425#comment:2>
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/063.e59081ebeb8f540d4e070672870ce00f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
