Шаблоны: супервизор

[флоппик]

Ваще-то в твиге подшаблон и так может поменять заголовок в лэйауте, в чем проблема то?
Шаблон викторины сделает {% block title %}{{ parent() }} — выкторина со стопицот призов {% endblock %}

 

[флоппик]

и практическое - заэмбедить ведь можно только шаблон. Но ведь надо откуда-то ещё достать данные для него?

Неужели вещи, которые я говорю - настолько непривычны народу?
Учитывая постулат о том, что любой мало-мальский сайт просто обвешан виджетами, у меня только одно предположение - все тупо делают виджеты старой доброй лапшой, заморачиваясь на шаблоны только если для "основного контента"?
Ну, или решая большинство задач активным шаблоном/ ещё чем-то + для отдельных случаев грязные хаки.

Мне непонятно, почему ты рендеринг модуля целиком в случае нормальной модульной системы записал в «грязные хаки активных шаблонов» в соседней теме.

$this->set('sidebar', Request::factory('module/action/params')->execute())

чем противоречит твоим желаниям?

 

[Фанат]

Шаблон викторины сделает {% block title %}{{ parent() }} — выкторина со стопицот призов {% endblock %}

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

$this->set('sidebar', Request::factory('module/action/params')->execute())

Это где пишется?

 

[fixxxer]

Фанат
Не-не-не, у меня шаблон ничего не достаёт! Но я, кажется, понял суть вопроса. Ты рассматриваешь шаблон сложной страницы (или даже набора таковых) с кучей разных вариантов отображения как нечто единое, какой-то там pagename.tpl который умеет всё. А на самом деле гораздо проще все варианты разбить на разные шаблоны. Вот тут как раз наследование и полезно. Можно провести совершенно прямую аналогию с пхп-кодом, когда 1000 строк лапши с if/switch рефакторятся в иерархию классов. Опять же по аналогии с пхп кодом, где-то логичнее обычное наследование ( = {% extends %}), где-то - делегирование через __call или новомодные трейты ( ~= {% embed %} ).

 

[fixxxer]

$this->set('sidebar', Request::factory('module/action/params')->execute())

Когда я вижу такие конструкции и рядом с ними утверждения о непонятности верстальщику твиговских тэгов, мне делается смешно.

 

[Vasilij]

Шаблон викторины сделает {% block title %}{{ parent() }} — выкторина со стопицот призов {% endblock %}

Разве такая конструкция отработает во вложенном шаблоне? Ведь викторина, в данном случае, это просто widget основного шаблона.

 

[Фанат]

fixxxer
В том-то и дело, что нету разных вариантов-то!
Вариант основного дизайна - ОДИН.
У любого сайта есть определённый дизайн, который используется НА ВСЕХ видах страниц.
Вот взять тот же хабр, к примеру:

http://habrahabr.ru/ - лента
http://habrahabr.ru/post/144940/ - пост
http://habrahabr.ru/events/coming/ - события.

Все эти страницы строятся в едином дизайне
НА КАЖДОЙ есть ссылки войти - зарегистрироваться, на каждой есть меню, форма поиска, лохматое лого. на каждой есть подвал с кучей ссылок.
Это ЕДИНЫЙ ДИЗАЙН сайта.

Плюс в нём наделано дырок под переменные блоки.
Под основную простыню контента плюс сайдбар с виджетами.

Вот тут как раз наследование и полезно.

Ну, с этим мне спорить трудно.
Наследование, насколько я понимаю его, решает.
Делаем абстрактный шаблон - рыбу сайта, и потом наследуем его, создавая шаблон поста.
Остаётся проблема управления виджетами. О которой я и пишу.

ВОПРОС:
Где идёт вызов контроллера, который заполняет блок залогиненого юзера?
Который пишет ссылки "настройки выйти личная почта избранное" и надпись "У вас недостаточно кармы для голосования" / либо "войти" и "зарегистрироваться"?

 

[fixxxer]

Где идёт вызов контроллера, который заполняет блок залогиненого юзера?

В базовом контроллере страницы aka view controller. Я это делаю на последнем этапе, непосредственно перед вызовом шаблонизатора - определяю набор общих для всего переменных.

Касаемо всяких сайдбаров и виджетов, ну тут зависит от специфики. Если они идут просто пачками подряд - то поступаю кондово: передаю массив $View->Sidebars->[ template_name => variables ], в нужном месте лэйаута просто стоит foreach ... include sidebars/${template_name}.tpl. Вообще тут простых инклюдов вполне хватает в 99% случаев. Если одни и те же сайдбары на разных страницах отображаются в разных позициях, тут будет полезен тэг embed, но на практике еще мне ни разу не приходилось воспользоваться - инклюдов хватало.

А наследование скорее полезно тут в другом смысле - например, есть общие сайдбары, и сверху/снизу хочется вывести что-то специфичное именно для текущей страницы - там получается что то типа
{% block sidebars %}
specifics
{{ parent() }}
{% endblock %} а в паренте тот самый форич.

 

[Фанат]

fixxxer
О.
Вот с этого места поподробнее, если можно.
похоже, этот твой базовый контроллер и есть та фигня, о которой я говорю.

 

[fixxxer]

Ой... да там ничего особенного, полный тупак. Вот скопипащу

    # фреймворк
    protected function displayTemplate() {
        try {
            $this->assignCommonViewVars();
            $this->View->parseTemplate( $this->assembleTemplate() )
                ->displayTo($this->Response);
        } catch (Exception $e) {
             // .....
        }
    }

    protected function assignCommonViewVars() {
        // совсем общая фигня, типа
        $this->View->CURRENT_PAGE->assign(get_class($this));
    }

    # в приложении
    protected function assignCommonViewVars() {
        parent::assignCommonViewVars();
        // $this->View->..., общее для данного приложения
    }

    # ну и еще уровни наследования могут быть для отдельных страниц

Внутри assignCommonViewVars может быть всякое.

Ну например если есть сайдбары, то наверняка будет $this->sidebars, метод типа $this->addSidebar('foo', $Foo), и $this->View->Sidebars->assign($this->sidebars) в assignCommonViewVars.

Короче ничего интересного, топорная хрень =)

 

[Ragazzo]

fixxxer
assignCommonViewVars это в контроллере или где? что значит коммент #в приложении? где именно располагается этот метод?

 

[fixxxer]

В приложении = не во фреймворке. Если бы я фреймворк отдельно не выделял, пункты 1 и 2 были бы вместе

 

[Ragazzo]

fixxxer
у тебя свой шаблонизатор я так понял)

 

[fixxxer]

не, у меня просто уровень абстракции от шаблонизатора. есть адаптеры для твига и смарти3

 

[флоппик]

Когда я вижу такие конструкции и рядом с ними утверждения о непонятности верстальщику твиговских тэгов, мне делается смешно.

Я такого не утверждал никогда.

Это где пишется?

В контроллере.
В принципе, ничем особо от подхода fixxxer не отличается, просто у меня это не отдельный View Controller, а методы before() и after() которые вызываются до и после нужного метода контроллера. И в Controller_Templated от котрого наследуются контроллеры приложений, определен after() примерно так:

public function after()
    {
        parent::after();
        $this->template = View::factory($this->template);
        $this->template->set('request', $this->request);
        $this->template->set($this->vars);
        $this->template->display();
    }

 

[флоппик]

Разве такая конструкция отработает во вложенном шаблоне? Ведь викторина, в данном случае, это просто widget основного шаблона.

Конечно отработает, оно для того и было придумано, практически, соль твига — наследуемые блоки.

 

[ksnk]

Тоесть, подводя итоги подхода к проблеме у fixxxer и флоппик - они просто написали в отдельном месте инициализацию "активных" шаблонов и не выпендриваются?

imho,

суть паллиатив и проблему не решают.

Хочется (мне ) , чтобы модуль определялся в единственном месте, в шаблоне. А не в двух местах.

 

[С.]

А по моему мнению, то, какие блоки показывать на странице - это именно бизнес-логика.

Как мы уже обсуждали ранее, четких границ между M, V и C не существует. Есть моменты, которые можно отнести как к одному, так и к другому. Выбор показывать ли блок ленты навостей на новостной странице тоже не однозначно относится к бизнес логике или отображению. Положа руку на сердце, а бы тоже отнес это к БЛ. Но!

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

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

 

[Фанат]

fixxxer
Ты не совсем понял мой вопрос
Я не имел в виду техническую реализацию, а вот именно то, что у тебя переспросил Ragazzo - "откуда ты это сказал???"
Где конкретно мы вызываем контроллер блока пользовательских ссылок?
что это за файл, какое место он занимает в остальной иерархии файлов?

 

[fixxxer]

У меня никаких активных шаблонов нет
Сначала собираем view-массив, потом все целиком за один раз рендерим.
В случае со ссылками, которые есть на куче страниц, где-то в базовом классе было бы что-то типа
$UserLinks = new UserLinks(....параметры...); // у него есть метод renderTo($View)
$this->View->UserLinks->bind($UserLinks); // при рендеринге дернется $UserLinks->renderTo для получения массива
а где то в шаблоне есть блок, обратабывающий UserLinks. Если, опять же, эти ссылки на множестве страниц - скорее всего, где-то в лейаут-шаблоне инклюд на этот блок.