> 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
for the following case, which I often do:
> A includes B; B extends from C.
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 can understand you want to override some part of the include B in
the main template A, that's what I made {% decorate %} for. (Which I
still would like to become a django core tag.) It's different from {%
include %}.
https://github.com/citylive/django-template-tags/blob/master/src/django_template_tags/templatetags/decorate.py
Further, I'm not aware of any inconsistencies in include behaviour
when using variable template names. Maybe anyone else?
Cheers,
Jonathan
--
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.
