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
#12008 was repurposed as a documentation improvement because the
current implementation is correct and just needs to be explained
better. As for the other two... I agree that consistency is important,
and that it would make sense (in a way) for ConstantIncludeNode to
either always raise or always s
On 03/06/11 17:36, Aymeric Augustin wrote:
> ConstantIncludeNode improves performance because it calls
> django.template.loader.get_template() only once in __init__() and not
> in each call to render().
>
> get_template() invokes the template loading machinery to create a
> compiled Template obje
On 3 juin 2011, at 16:44, Luke Plant wrote:
> From what I've seen so far, your proposal sounds good.
I agree — consistency is good.
> Is there a way
> that we can keep the performance benefits of ConstantIncludeNode? For
> example, if an IncludeNode detects that it resolves to the same template
On 03/06/11 09:04, Tai Lee wrote:
> 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?
>From what I've seen so far, your proposal sounds good. Is there a way
that we can keep the performance benefit
On Jun 3, 9:32 pm, Jonathan Slenders
wrote:
> I really never want to have the {% block %} names of B/C in previous
> example to be available for overriding in templates which inherit from
> A. This would even cause unexpected collisions between block names.
> The author of the include B, is not
> 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).
It's certainly possible to use {% include %} inside a template. It's
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 templa
