On Jun 3, 9:32 pm, Jonathan Slenders <jonathan.slend...@gmail.com>
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 supposed to know where his
> template will be included, and we can't expect him to choose block
> names which don't collide with those of A.

I agree, and my preferred fix (to remove `ConstantIncludeNode`) would
make it clear that the actual include is to occur at render time, and
any blocks contained therein are completely separate to blocks in the
parent template. It should not be possible to replace a block in an
included template by defining the same block in the including (parent)
template.

> Further, I'm not aware of any inconsistencies in include behaviour
> when using variable template names. Maybe anyone else?

One inconsistency is that when a literal quoted string is used as the
path to the template to be included, `ConstantIncludeNode` is used
instead of `IncludeNode` as a special case. This tries to include the
specified template when the parent template is compiled instead of
when it is rendered. This is supposed to be functionally the same as
using a variable path argument (which is executed when the template is
rendered), but slightly optimised. Unfortunately, it's not
functionally the same.

One example of this difference causing a problem is that when
`TEMPLATE_DEBUG` is `True`, a `TemplateDoesNotExist` exception is
raised when compiling a template that does exist, if it contains `{%
include "template_that_doesnt_exist.html" %}`. This means that any
code that checks for the existence of a template (with
`select_template()`) could break and behave differently in production
and development environments based on the content of the template.

If the template tries to include the same non-existant template, but
passed to `{% include %}` as a variable, no exception is raised.

Another example cited in the tickets is that it is impossible to
conditionally include a template that uses a literal string as the
path argument. E.g. `{% if some_false_var %}{% include "..." %}{%
endif %}` will raise `TemplateDoesNotExist` because the include is
executed when the parent is compiled, even though it is never rendered
because the context at render time causes the condition to fail.

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.

Reply via email to