I would personally prefer to be able to specify whether the "include"
should be rendered at the compile time or at the rendering time.
For some applications it is really useful to have recursive inclusion
of templates, which is impossible with compile-time inclusion. For
example, a few days ago I was writing a view which visualizes a diff
between two mongoDB documents with arbitrary levels of nesting. It can
be elegantly expressed with recursive includes, yet I was forced to
add additional render_to_string statements to my view, unnecessary
complicating the code.
The problem with processing the inclusion at render time to me is
that:
x Errors are left unnoticed for a longer time - eg if included
template has any errors you won't see them until you are actually
processing the view, and if your include is conditional it can get
complicated.
x Degrades performance.
I can't really think of an elegant syntax to that though. {% include
"blah.html" render %} seems ugly and would be very confusing to
beginners.
George
On Jun 3, 6:04 pm, Tai Lee <real.hu...@mrmachine.net> wrote:
> 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/16147https://code.djangoproject.com/ticket/12064https://code.djangoproject.com/ticket/12008https://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.
