﻿id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
13399	included template can't update blocks	lanyjie	nobody	"I encountered this problem in django 1.1, and it caught me in a surprise. This is a short version of the situation, I have four files:


{{{
base.html:
{% block title %} Base {% endblock %}

main.html:
{% extends ""base.html"" %}
{% if use_branch_one %}
{% include ""branch1.html"" %}
{% else %}
{% include ""branch2.html"" %}
{% endif %}

branch1.html:
{% block title %} This is branch one {% endblock %}

branch2.html:
{% block title %} This is branch two {% endblock %}
}}}
I would expect to see the main.html having either of the two titles in the branches, but what happens is you always see the base title!

The interpretation of inclusion should be clear: the included file is first read into the place holder ""AS IS"", then template processing continues from that very point, within the current context of the including template, as if nothing special happened -- and of course that context also specifies the parent template. With that understanding, we should be surprised to see that a block clause in the included template file becomes non-effective. I think the documentation about these builtin tags (include, and similarly ssi) leaves some ambiguity. It could be dynamically included (as you can give use a variable argument for it, so what file to be included is definitely determined at runtime; another situation is to have the include clause inside some conditional clause), but what we said before still applies in this dynamical loading context. If the inheritance is lost in the included file, we are definitely having a lesser template system. Currently what you can do is to factor out the {% block title %} clause in the branches html files into the main.html file. But it wont' work if you have multiple blocks to update in your included template file.

I noticed there are other somehow related tickets about the problems occur at the interplay of ""include/ssi"" and ""extends"" (see ticket 6646 and 2908), and they all stems from the same ambiguity of what shall happen with ""include/ssi"". With this understanding, ticket 2908 could be resolved by allowing multiple definition of the same block (whether included or not), but only the last definition is taken (or, the one comes after overrides the one goes before). Ticket 6646 can be resolved by specifying that the parent/extended template must be first parsed to determine the included blocks that will be available to the child/extending template to fill in."		closed	Template system	1.1		duplicate	include ssi extends interplay		Unreviewed	0	0	0	0	0	0
