DjangoBB LoFi version

Полная версия: Множественное наследование в шаблонах

Начало » Web » Множественное наследование в шаблонах

zheromo

Апрель 19, 2011 13:23:18

Кто-нибудь что-то использовал по сабжу? Хочется иметь такую штуку, но ничего внятного, к сожалению, пока не нашел. Jinja, что печально, сабж не поддерживает.

regall

Апрель 19, 2011 13:58:09

Chameleon - http://chameleon.repoze.org/

zheromo

Апрель 19, 2011 16:19:34

Хм, макросы - это, имхо, не множественное наследование и, вообще, даже не наследование. Или я чего-то не понимаю?

regall

Апрель 19, 2011 16:20:34

zheromo, а как вы себе представляете множественное наследование шаблонов? Точнее его цели и хотя бы очерки реализации?

zheromo

Апрель 19, 2011 16:59:09

regall
zheromo, а как вы себе представляете множественное наследование шаблонов? Точнее его цели и хотя бы очерки реализации?

Примерно также как наследуются классы. Например:

Шаблон layout

{% block header %} header text {% endblock %}
{% block content %} 

  {% block title %} title {% endblock %}
content text 

{% endblock %}
{% block footer %} footer text {% endblock %}

Шаблон header_mixin

{%block header %} new header {% endblock %}
{%block title %} new title {% endblock %}

Наследующий шаблон

{% extends layout, header_mixin %}

{%block content%}
{{ super }}
my content
{% endblock %}

Результат:

new header
new title
content text 
my content
footer text

zheromo

Апрель 19, 2011 17:19:16

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

Обнаружилось что все это вместе легко бы соединилось если бы можно было объединить эти две иерархии наследования, т.к. по сути они друг от друга почти не зависят, а их совместное использование при “одиночном” наследовании приводит к куче условий, шаблон получается плохо читаемым, как минимум.

regall

Апрель 19, 2011 17:23:09

zheromo, это уже явно не проблема шаблона, а проблема проектирования приложения. Шаблон должен получать, в идеале, плоский контекст и вставлять его переменные в положенные места. То, что вы хотите сделать логику представления шаблонами не есть хорошо.

zheromo

Апрель 19, 2011 17:43:23

regall
Шаблон должен получать, в идеале, плоский контекст и вставлять его переменные в положенные места.

return template % context

- идеальный шаблонизатор :)

regall
То, что вы хотите сделать логику представления шаблонами не есть хорошо.

А где ее еще делать? Во вьюхе? А именно к этому и стремлюсь, так как сейчас вьюха проверила права доступа, извлекла контент и передала его в шаблон, приходится писать кучу ифов, такого рода - ели пользователь обладает ролью такой-то, то нарисовать кнопочку такую-то, если ролью такой-то то такую и т.д. (Управление контентом происходит с фронтенда а не с админки - это требование).
Если создать по шаблону на каждый вариант - (их не очень много), то от лишних условий получается избавиться, но появляется жуткое дублирование кода в шаблонах что опять же ведет к проблемам в сопровождении.

o7412369815963

Апрель 19, 2011 20:59:59

в примере (пост 5) header_mixin должен быть отнаследован от layout, а “Наследующий шаблон” от header_mixin.
а пример с админами:
все что сходится выводим в template_doc, а отличия рассовываем в user и admin

layout -> template_doc -> user
                \-------> admin

или выводим доп компоненты

layout -> template_doc -> user -> admin

у меня в толстом корпоративном портале иерархия до 8 уровней, и все нормально.

zheromo

Апрель 20, 2011 06:07:49

o7412369815963
в примере (пост 5) header_mixin должен быть отнаследован от layout, а “Наследующий шаблон” от header_mixin.

пример я просто привел для демонстрации работы наследования, не больше

имеется допустим иерархия по видам контента

layout -> content_1 -> content_2 -> content_3
                                     \
                                       -> content_4

Контент имеет разное отображение для разных пользователей

Соответственно для каждого content_ разное отображение для различных групп пользователей
Приходится писать много ифов в каждом content_

Элементы которые зависят от группы, также, можно выделить в иерархию

manage_layout -> user -> moderator -> administrator
                                           \
                                             -> owner

Тогда для контента 3 для пользователя с правами moderator можно было бы писать

extends(content_3, moderator)

т.е. элементы управления вставятся сами (те которые есть в modertor), если унаследовать от administrator, то те которые есть в administrator.
и можно будет избавиться от ифов, паттерн - replace conditional with polymorphism