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

[ksnk]

Фанат
При том, что с использованием парсинга мы получаем пользу - описание активного шаблона будет вставляться в одном месте. И убираться полностью с помощью комментирования части шаблона.

 

[С.]

Модели недостаточно для получения данных - нужен контроллер, который будет посредником между НТТР запросом и моделью.

Для этого есть фронт контроллер. Почему я и пристаю с вопросом, что у вас делает контроллер шаблона? Не могу поверить, что у вас каждый сраный шаблонишко в НТТР лезет. Не его собачье дело, для него фронт-контроллер все уже НТТР разобрал.

А чем занимается этот body.biz.php?

Вообще-то мой вопрос, чем занимается пресловутуй контролер шаблона.
У меня это модель и в частном bodyвском смысле он пуст или заполняет какие-то глобальные данные.

 

[Фанат]

Для этого есть фронт контроллер.

Согласен, натупил в формулировках. Виноват, сам загадил дискуссию.

Верно, НТТР обрабатывает фронт-контроллер. Но при этом он выполняет только функции роутинга.
Его задача - определить, какой контроллер (т.е. какой экшен какого модуля) вызывать. и передать ему входящие параметры.
Дальше контроллер решает, какие данные запрашивать у модели, получает их, форматирует, и передаёт в шаблонизатор.

Вообще-то мой вопрос, чем занимается пресловутый контролер шаблона.

Не контроллер шаблона. просто контроллер. Но поскольку (в случае вывода результата работы в хтмл) его задача - отработать бизнес-логику определённого блока, определять шаблон и выдать данные для него, он получается, де факто, контроллером шаблона.

модель, повторюсь, не может быть контроллером.
модель работает только с данными.

 

[С.]

Итак вроде определились, что не существует "контроллера шаблона", есть просто контролер, один на все шаблоны и весь фреймворк.

Дальше контроллер решает, какие данные запрашивать у модели, получает их, форматирует, и передаёт в шаблонизатор.

С какой стати контроллер решает какие данные запрашивать? Откуда он вообще может это знать? Модель знает какие данные генерить и делает это (при этом нет никакой узурпации функций контроллера). Затем она отдает эти данные контроллеру и говорит: "встретишь шаблон, передай ему".

У меня сложилось впечатление из твоих слов, что у тебя:
- много шаблонов
- много контроллеров (один на шаблон/блок)
- один фронт-контроллер
- одна модель

Я же предлагаю следущее:
- много шаблонов
- много моделей (одна на шаблон/блок)
- один фронт-контроллер

 

[Фанат]

есть просто контролер, один на все шаблоны и весь фреймворк.

есть просто контролер, один на все шаблоны и весь фреймворк.

Нет, так не может быть.

Твоя структура нормальная, только нежизнеспособная или - что скорее - у тебя вообще нету модели, а классическая схема, когда модели нет, а контроллер выполняет её функции. Я так очень долго работал, пока не понял смысл модели - абстрагировать работу с хранилищами данных.

Должно быть так
- один фронт-контроллер (он же, по факту - роутер)
- много модулей
- много моделей (одна на модуль)
- много контроллеров (один на шаблон/блок). контроллер является "блоком" модуля. как понятие "сокет" означает комбинацию хост:порт, так и контроллер являет собой комбинацию модуль/экшен.
в задачи такого экшена входит далеко не только подготовка данных для шаблона. К примеру, экшен (контроллер) user/register вообще ничего на экран не выводит.
- вью. Класс, который занимается
а) шаблонизацией, как таковой
б) находится в каких-то отношениях с контроллером, отвечающим за шаблон рыбы сайта. вот эти отношения я и пытаюсь выяснить

Структурно и модуль, и модель представляют собой классы.
Экшены являются методами класса.
модель представляет собой класс, методы которого предоставляют доступ к любым манипуляциям с данными. Надо тебе выдернуть строку по id из базы - пишешь не запрос в контроллере, а вызов метода модели.
Я согласен - это структура достаточно замороченная, и не всегда оправданная.
Но если у тебя её нету, то не говори, что у тебя есть модель.

 

[lagoff]

Именно в этом.
В зависимости от запрашиваемой страницы набор виджетов может меняться.
Собственно, вопрос именно в этом: где определяется логика выбора виджетов.

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

 

[С.]

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

И так запутались в терминологии, зачем еще хранилище данных сюда притягивать? В MVC нет D, потому что это часть модели. А как она там абстрагирована, это не забота MVC. Однозначно, что не контролер, ни отображение к хранилищу данных прямого доступа не имеет.

Твоя структура нормальная, только нежизнеспособная или - что скорее - у тебя вообще нету модели, а классическая схема, когда модели нет, а контроллер выполняет её функции.

Это ты упорно называешь мою модель контроллером и потом же обвиняешь. Модель это самая натуральная, в ней есть обращение к хранилищу данных, и она не знает вообще в какомконтексте к ней обращаются (контроллер бы знал).

Кроме того концепция "много моделей (одна на блок)" более вебовская. Она не порождает класса-бога, а подтягивет только те данные, которые нужны для данного конкретного блока. Общая концептуальная модель приложения существует, но виртуально, нет какого-либо одного файла или класса, в котором бы это было записано.

В конкретном мире это выражено в том, что есть три категории файлов:

- Ядро фреймворка, он же контроллер. Полностью абстрагирован от приложения и просто тупо копируется из одного приложения в другое.

- Шаблоны, они же вью. Один экшн/блок/виджет - один шаблон. Причем шаблон даже не знает в какой роли он будет выступать.

- Бизнес модули, они же модель. Вообще говоря каждому шаблону однозначно соответсвует свой модуль, который автоматом дергается перед шаблоном). Хотя есть и "безголовые" модули-процедуры.

Все, больше никаких сущностей, связывающих их друг с другом нет. Контроллер заранее знает, как связать шаблон с соответствующим модулем (одинаковое имя). Шаблоны могут вставлять в себя другие шаблоны (блоки/виджеты). Модули могут вызывать другие безголовые модули-процедуры. Все четко разделено по трем MVC полочкам и между ними нет пересечений.

 

[lagoff]

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

просто контроллер. Но поскольку (в случае вывода результата работы в хтмл) его задача - отработать бизнес-логику

И это говорит один из "пап" форума? Уверяю вас, вы не поняли что такое модель. Да и контроллер бизнес-логику не обрабатывает. Для этого есть модель.

Шаблоны, они же вью

Шаблоны != View. Шаблонов может в принципе не существовать.

Вы извините, народ, не хочу рисоваться и читать морали, но, имхо, все ваши проблемы заключаются только в недостатке знаний и понимания того, что вы используете. Которое, походу, возникает оттого, что комплексные вещи, такие например как MVC, изучаются по тьюторам а-ля "Создай блог за 5 минут" какого-нить очередного фреймворка, и эти же тьюторы становятся основной для подражания в будущем. А все вопросы которые в этих тьюторах не затрагиваются додумываются самостоятельно отсюда и все эти страницы "мыслеблудия". Прочитайте уже, наконец, что такое MVC, только в оригинале, от первоисточника. Или Фаулера, например, он хорошее исследование провел по концепциям огранизации UI.

Поверьте, все давно уже придумано и продумано. Надо только отбросить спесь, высокомерие и амбиции и просто прочитать.

 

[Фанат]

Что интересно - мне тут коллега на работе только что подсказал, что при наличии супервизора не нужна обертка для native php.
И в самом деле - ведь для супервизора совсем не обязательно получать отрендеренные шаблоны блоков.
Он может просто вызывать нужные контроллеры, получать от них данные для шаблонов, а потом тупо инклюдить главный шаблон, в котором тупо инклюдятся шаблоны блоков.

Идея мне пока не очень-то нравится, но что-то в этом определённо есть.

 

[fixxxer]

Фанат

То, о чем ты говоришь на этой странице, называется HMVC.

У меня такое есть в одном проекте, где эти самые блоки и параметры задаются пользователем в интерфейсе. Ну типа как в Delphi компоненты, только попроще.

Для большинства проектов это слишком все усложняет на пустом месте.

 

[С.]

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

<div>
   <? insert('block') ?>
</div>

мы делаем [упрощенно] include('block.model.php') и затем include('block.template.php'). А супервизор здесь получается неявный.

 

[Фанат]

С.
Этак мы получаем активный шаблон со всеми его недостатками. Не-не-не, Девид Блейн, я уже достаточно разобрался в вопросе, чтобы активные шаблоны вычеркнуть из рассматриваемых вариантов.
А вот супервизор как раз и нужен, чтобы сделать шаблон, извините, пассивным

 

[С.]

На нет и суда нет. Я пока из всех дискуссий уяснил, что единственный неоспоримый недостаток активных шаблонов, что они непассивные. Не могу не согласиться, черт возьми. Дело за малым -- создать пассивные шаблоны, которые были бы такие же удобные (=без деклараций в нескольких местах) и быстрые (=однопроходные), как активные. Хотя я лично для себя я доказал лемму, что эти оба качества одновременно невозможны при в пассивных шаблонах.

 

[Фанат]

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

 

[флоппик]

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

Ничего, вон, игры по сотням кадров в секунду в буфере рисуют, а потом показывают. И ничего - не умерли до сих пор.

 

[Фанат]

флоппик
Буфер-буфером, но исправить уже выведенное всё равно получится только через гланды автогеном.

 

[fixxxer]

В принципе, можно придумать "псевдоактивные" шаблоны, по которым делается два прохода

Первый проход - рассматриваем код шаблона "декларативно" - вытаскиваем что ему нужно и подгружаем.

Непонятно зачем.

 

[С.]

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

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

Двойное декларирование, с одной стороны, выглядит неэффективным, но, скажем, переменные для обычного шаблона мы тоже объявляем два раза - сначала присваиваем в контроллере, а потом обращаемся в шаблоне. И ничего - не умерли до сих пор.

Это все-таки не совсем то. Множественная декларация в пассивных шаблонах гораздо суровее и беспощаднее.

 

[Фанат]

Можно пример?
Я пока вижу только вызов контроллера виджета в супервизоре и обозначение места, куда будет вставлен результат, в шаблоне

 

[С.]

Я считаю, что при вебразработке на фреймворке в 21 веке писать вступительное заклинание для каждой страницы типа:

int main(int argc, char **argv)
{
  /* start here */
}

или

<? include('header.php') ?>
<!-- start here -->
<? include('footer.php') ?>

считаю излишним (а уж фреймоворки, где есть функция генерации или регистрации новой пустой страницы сразу отправляются на помойку). Надо просто создать пустой файл и писать в нем бизнес логику или шаблон. Соответственно в таком варианте совершенно тривиально фронт-контроллеру дергать шапку и подвал в самую последнюю очередь, когда все данные и тело страницы уже сформированы.

В конце концов MVC создан исключительно для облегчения разработки и поддержйки кода, а не чтобы ему поклоняться как святому канону и исполнять ритуальные танцы во имя Его.