Родительский контекст в inclusion-тегах

Чтобы все не решили, что я перестал писать технические посты про Django, вот маленький пост средней полезности.

Если вы какое-то время работаете с Django и используете inclusion-теги, то наверняка сталкивались с неудобством, что кроме переменных контекста, возвращаемого из тега, в шаблон не попадает ничего. В частности, там нет всяких полезных {{ user }}, {{ MEDIA_URL }} и прочих "глобальных" вещей из родительских контекстов.

Я одно время был даже пропонентом такого подхода, потому что он "чище": в контекст не сливается куча глобальных переменных, которые теоретически засоряют namespace внутреннего независимого шаблона. Но практика показывает, что все наоборот. Случаев, когда вам нужны глобальные данные в контексте, полно, а вот чтобы они мешались, я как-то не припоминаю совсем. Да и кроме того, поскольку шаблонный язык очень ограничен, прострелить себе ногу с помощью глобальных данных там довольно сложно. Средств мало :-).

Поэтому сейчас я думаю, что на самом деле inclusion-тег должен просто передавать в свой шаблон весь родительский контекст тоже. А пока этого не произошло, я хочу описать способ, которым я это делаю.

Проще всего сделать, конечно так:

@register.inclusion_tag('template.html', takes_context=True)
def my_tag(context):
    return {
         'user': context['user'],
         'MEDIA_URL': context['MEDIA_URL'],
    }

Но это скучно и нуждается все время в поддержке по дописыванию нужных переменных. Чтобы это автоматизировать, можно было бы воспользоваться методом типа items(), выдающему все содержимое, но такого метода у контекста нет. Потому что контекст — это на самом деле не dict, а стек из dictов. Поэтому нужно было бы бежать по всем стеку циклом, и у каждого dictа брать items(). Но это уже слишком многословно.

Поэтому вместо того, чтобы бороться со стековой структурой контекста, я использую ее себе на благо. Ведь вместо того, чтобы копировать по сути весь контекст, можно естественным образом добавить свои переменные в еще один уровень стека и передать этот же самый контекст в свой шаблон! Тогда шаблон увидит и свои переменные, и все остальные, что были в контексте до этого.

Жаль только, что декоратор inclusion_tag написан так, что сделать этого не позволяет. Поэтому я пишу тег руками:

class MyTagNode(template.Node):
    def render(self, context):
        context.update({
            # собственные переменные
        })
        result = template.loader.get_template('template.html').render(context)
        context.pop()
        return result

@register.tag
def my_tag(parser, token):
    return MyTagNode()

Метод context.update берет переданный dict и "пушит" его наверх стека. Соответственно context.pop его потом оттуда удаляет. Вуаля!

Хотя, повторюсь, хотелось бы, чтобы это было дефолтным поведением inclusion-тега. Потому что он все таки удобней, чем написание тега целиком.