[Django] #24425: Cross Backend template includes are not supported
Django
---------------------------------+----------------------
Reporter: phalt | Owner: nobody
Type: Bug | Status: new
Component: Template system | Version: 1.8beta1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+----------------------
Attempting to render Jinja templates with an include tag in a Django
template results in the Django template backend parsing the jinja
template.
For example:
templates/django.html:
{{{
Django Template!
{% include 'include.jinja' %}
}}}
jinja2/include.jinja:
{{{
Jinja Template!
{% set jinja = 1 %}
}}}
Will cause a template rendering error as `set` is not a valid tag in
Django templates.
This used to work fine as the `SsiNode` that powers the include tag would
search using all configured loaders but since 1.8 it has changed to
maintain the current engine context.
This seems like an obvious behaviour to want 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24425>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: phalt | Owner: nobody
Type: Bug | Status: new
Component: Template system | Version: 1.8beta1
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 phalt):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
> Attempting to render Jinja templates with an include tag in a Django
> template results in the Django template backend parsing the jinja
> template.
>
> For example:
>
> templates/django.html:
> {{{
> Django Template!
> {% include 'include.jinja' %}
> }}}
>
> jinja2/include.jinja:
> {{{
> Jinja Template!
> {% set jinja = 1 %}
> }}}
>
> Will cause a template rendering error as `set` is not a valid tag in
> Django templates.
>
> This used to work fine as the `SsiNode` that powers the include tag would
> search using all configured loaders but since 1.8 it has changed to
> maintain the current engine context.
>
> This seems like an obvious behaviour to want 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.
New description:
Attempting to render Jinja templates with an include tag in a Django
template results in the Django template backend parsing the jinja
template.
For example:
templates/django.html:
{{{
Django Template!
{% include 'include.jinja' %}
}}}
jinja2/include.jinja:
{{{
Jinja Template!
{% set jinja = 1 %}
}}}
Will cause a template rendering error as `set` is not a valid tag in
Django templates.
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.
This seems like an obvious behaviour to want 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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24425#comment:1>
Django
Reporter: phalt | Owner: nobody
Type: Bug | Status: closed
Component: Template system | Version: 1.8beta1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 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
Reporter: phalt | Owner: nobody
Type: Bug | Status: closed
Component: Template system | Version: 1.8beta1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by public):
> 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.
That's an acceptable solution. Thanks for the help :)
--
Ticket URL: <https://code.djangoproject.com/ticket/24425#comment:3>