G'day,
There are several open tickets (some getting quite old now) that all
stem from the inconsistent behaviour of the {% include %} tag. When a
quoted string is used for the path, it is treated as a special case
and the include is executed at compile time. Otherwise, it is executed
as the template is rendered.
The docs don't seem to mention this special case, and a few examples
of buggy behaviour and confusion stemming from this include:
- Included templates with a missing path sometimes fail silently, and
sometimes loudly.
- Template loaders raise TemplateDoesNotExist when the specified
template *does* exist, if it happens to use an include with a quoted
path that references another template that does not exist.
- Included templates do not render in the full context of their
parent template as implied by the docs. This means you can't use `{%
block %}` tags inside included templates and override them in
templates that extend the parent template.
My feeling is that including templates should be consistent. If we
support variables as the path argument to the include tag, then ALL
uses of the include tag should be processed when the templates are
rendered.
This means that it will not be possible to use block tags inside
includes. This is not possible now, but there is an open ticket that
would like to make it possible (only for the special case quoted
string path includes).
I would also like to see includes either always fail loudly, or always
fail silently. I think that the most common and expected behaviour
currently is for includes to fail silently, but I don't really care
either way.
The best solution that I can see is to remove `ConstantIncludeNode`
entirely (as has been suggested in at least one of the tickets).
Includes would always be processed at render time, it would not be
possible to extend blocks defined inside an included template, and
including templates that does not exist would no longer raise a
TemplateDoesNotExist exception when getting the parent template (which
does exist).
Could we get a quick vote from any core committers and other
interested parties, so that we can move forward to fixing and closing
these tickets?
https://code.djangoproject.com/ticket/16147
https://code.djangoproject.com/ticket/12064
https://code.djangoproject.com/ticket/12008
https://code.djangoproject.com/ticket/598
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
