MVC. Генерация html страницы шаблонизатором и блоков (или собирание всех данных для этого)?

Question

[dim4ik]

Схема запроса простая:
1. Пользователь совершает запрос /news/1/
2. роутер определяет контроллер и метод который надо вызвать изходя из запроса (контроллер news метод show)
3. котнроллер вызывает модель , которая получает данные по новости №1
до этого момента все прекрасно (тут можно отдать данные шаблонизатору и вставить их в страницу, отдать пользователю)

НО в шаблоне есть еще "блоки", допустим блок комментарией, блок популярные новости. Чтобы получить результат (нарисовать эти блоки) необходимо вызвать их контроллеры, которые через модели выцепят данные.
Я не понимаю на каком этапе необходимо это сделать.

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

Answer 1

[Masterme]

при задании конфигурации роута ты ставишь жёсткое соответствие, например,
"/news/:id" -> контроллер = news, метод = item
таким способом можно получить данные и отрендерить только один хтмл-блок. в то же время по условиям задачи нужно рендерить несколько блоков. выход? а вот:
"/news/:id" -> {
'main' -> controller = news, method = item,
'last_news' -> controller = news, method = last_items,
'now_logged_users' -> controller = users, method = last_logged,
}
и так далее. и в шаблоне отмечаешь блоки 'main', 'last_news', 'now_logged_users'. и каждый блок рендеришь отдельно, а потом вставляешь в шаблон. блоки получаются равноправны и независимы. понятно, что можно назначить какой-то блок по умолчанию, но работать он будет так же - на равных с другими блоками условиях. такая работа с блоками должна быть предусмотрена на уровне роутинга, и если движок это не позволяет - то он говно. есть пхпшная CMS MODx, попробуй её и посмотри, как в ней организованы сниппеты. сама modx может не годится для хай-енд разработки, но в ней правильная идея работы со структурой страниц и вставкой контента в страницы.

Comments

[dim4ik]

Считаю ваш ответ исчерпывающим, так я и хотел сделать, но не знал где прописать все блоки(контроллеры), вы указали на очень интересное место.
Ушел качать ModX и искать их класс роутера. Как найду - отпишу.

[Masterme]

@dim4ik есть ещё схема, на мой взгляд, оптимальнее. Можно прописать в шаблоне какие подшаблоны могут быть вызваны. В моей CMS есть основной шаблон, в нём указаны блоки. Перед запуском страницы в шаблоне ищутся блоки, полученные имена блоков берутся из отдельного файла, каждый обрабатывается независимо на основе параметров из URL.

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

[dim4ik]

@Masterme Вот из-за пункта "б)" и задал этот вопрос. Не понимаю как это можно сделать с шаблонизатором типа Blitz.
Получается так, как я описал выше.
"Перед запуском страницы в шаблоне ищутся блоки" может пояснить этот момент, где в контроллере делается этот момент. Я так понимаю, что контроллер (допустим "новости") сначала делает свои проверки, берет данные из модели -> т.к. готовит массив (допустим $data) для передачи его шаблонизатору (нативному или в view), а только потом делает поиск блоков в шаблоне странице. Правильно я указал порядок действий?

[Masterme]

Ну, можно до, можно после. Вот пример:
Основной шаблон pastebin.com/pwRsc7RP
1. Ищем строки вида [[...]] - это наши блоки, запоминаем их
2. По конфигурации роутера определяем контроллер/метод по умолчанию. Пусть это будет /articles/12 - то есть контроллер articles, метод item, параметр id=12. Выводим статью номер 12, передаём в подшаблон, получаем из подшаблона строку, запоминаем.
3. для каждого из блоков из п.1. ищем в специальном конфигурационном файле типа такого pastebin.com/mHpgSfQn соответствия, затем каждый выполняем, фетчим соответствующий шаблон и получаем строку
4. заменяем в основном шаблоне вхождения [[...]] на соответствующие им строки из п. 3
5. передаём в шаблон результат п.2 как переменную main_content.
6. профит.

---
почему я говорил про равноправные блоки? потому что можно обойтись в общем случае без $main_content и п. 2 и 5.

[dim4ik]

@Masterme
Я в шаблон всталяю блок таким образом:
< block name=comment action=show_item_comments target_type=2 target_id=<?php echo $news['id'];? > >
В него основной контроллер подгрузит данные (допустим новости = 12), в итоге строка с блоком преобразутеся в
< block name=comment action=show_item_comments target_type=2 target_id=12 >
Контроллео новости свое отработал и отдал свои результаты.
Потом парсится шаблон на предмет блоков, для этого блока парсер определит:
$controller = comment
$method = show_item_comments
$args = array( 'target_type'=>2, target_id=>12)

и передаст их тому, кто вызовет каждый блок последовательно
контроллер блока -> метод -> view вернет html
потом этот html вставится обратно в шаблон
и так каждый блок.

В итоге в конце получаем готовую страницу.

Answer 2

[Walt Disney]

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

Answer 3

[Webdesus]

Что мешает в конроле новостей вызвать методы других контролов для получения дополнительной инфы?

Comments

[dim4ik]

Удалился комментарий?! Контроллер новостей должен отвечать за новости. То, о чем спрашиваете вы, должно исполнятся на уровне выше. Поэтому я и задал этот вопрос.

[Walt Disney]

Для вашего примера, как раз и нужно делать это в контролере.

Новость скрыли от просмотра/удалили, а при переходе на страницу комментарии остались? или вы сделаете контролер новости более главным чем контролер комментариев, так что бы он запрещал выполнение других контролеров? Если делать это где то ещё вы обростёте костылями.

Вам в любом случаее вам придётся связывать сущьность новости с сущьностью комментарии. Т.е. модель коментариев должена получить хотя бы id новости. И самый нормальный вариант это сделать в контроллере страницы "новости".

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

Комментарии вообще без хозяина мёртвая сущность им по сути нужны только модель и вьюха, а контроллер в там не нужен.

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

[dim4ik]

Согласен в вами полностью!
Сейчас сделан контроллер новости главным(или основным).
- вызывается только он, потом все параметры передаются шаблону
- в шаблон так же вставили new_id для блоков/виджитов типа блока комментариев
- потом идет поиск блоков в этом шаблоне (нашли блок комментариев или последние новости)
- вызвали их контроллер->модель->контроллер->view = html
- вернули опять эти html куски на место блоков в шаблоне
- выдали страницу пользователю.

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

[Walt Disney]

Вы парсите шаблон на предмет наличия в нём блоков? Это плохая затея, представьте что у вас верстальщик работает. Для него такое будет постаянным молшебством, а для вас постаянным дёрганьем по его проблемам.

Блиц был адекватным 5 лет назад, думаю таким и остался, там же есть? что то типа fetch/rendContent/getBlock для того, что бы отрендерить блоки оберните это дело в класс

и используйте типа:

$this->Render->set('news',$news)
$this->Render->set('content',$comment);
$this->Render->rend();

Добейтесь того что бы у вас вместо страницы var_dump показал все данные этой страницы, и там уже прикрутите Blitz

Вам скорее всего в любом случаее нужен контроллер страницы, что бы контролировать её, как бы банально это не звучало. Большинство MVC фрейворков по умолчанию используют адреса stite/controller_name/methood_name - это они не просто так.

[Masterme]

@ruFelix
> Вы парсите шаблон на предмет наличия в нём блоков? Это плохая затея
Это хорошая затея, вполне себе рабочая. Верстальщик получает список блоков, и если он не тупее обезьяны - он сообразит, что в основной шаблон можно вставить [[block_name]], а каждый блок сверстать отдельно

[Walt Disney]

Я к сожалению не знаю вашей полной задачи.
У вас не может появиться задача отобразить количество комментариев у каждой новости в списке новостей?

Идея парсинга шаблона в вашем варианте мне не нравиться потому что:
1) бэктрейс и отладка будут очень своеобразными
2) шаблон управляет тем что будет вызванно, т.е. оттягивает на себя роль контроллера
3) что вы будете делать что бы пометить уже прочитанные пользователем комментарии? связать контролерры (comments + users ) через парсинг шаблонов уже не получиться.

Answer 4

[Кирилл Платонов]

Создайте для отдельных блоков с узкими задачами "облако тегов", "последние комментарии" и тп отдельную сущность - виджеты. В них выносите логику, и представления этих блоков. Эти блоки вы будете вставлять в представления, например <?php echo $widget->render('tags'); ?>

Comments

[dim4ik]

Сейчас так и реализовано, но это неправильно. Данные все должны быть известны сразу до передачи их шаблону.

[dim4ik]

Всё дело в том, что я хочу использовать шаблонизатор Blitz, а пхп код в него уже не вставить.

[Кирилл Платонов]

@dim4ik чем вас не устраивает нативный шаблонизатор?

[dim4ik]

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

[dim4ik]

Конечная же моя цель, это дорефакторить свой "движок" сайт, и отдать отдельные модули на разработку другим программистам, чтобы опираясь на четкую структуру движка/модуля, мне легко было в этом разобраться.

[Кирилл Платонов]

@dim4ik ок. Я не думаю, что правильным будет пытаться ограничить функциональность таким образом. У программистов остается возможность что-то испортить в контроллерах. Если вы опасаетесь за структуру базы данных, то можете ограничивать возможность модифицирования структуры базы данных в настройках для разных пользователей. И разрешить менять структуру в специализированных местах для этого, в миграциях, например.

Если пытаться решить задачу вашим способом, с использованием шаблонизатора, то можно помещать подготовленный виджетами html/css/js код в переменные и вставлять таким образом в ваш шаблон. Не красивое решение, но рабочее.

[Кирилл Платонов]

И все таки я советую вам обходиться без шаблонизатора. Сила в простоте.

[Masterme]

> чем вас не устраивает нативный шаблонизатор?
как можно такое спрашивать в 2013м году?

[Masterme]

@BloodyHistory эй, сила в простоте, а необходимость вручную оборачивать каждое эхо в htmlspecialchars - это простота что ли? Вставлять на каждый чих <?php ?> - простота? Или может быть отсутствие возможности наследовать шаблоны - простота?

[Кирилл Платонов]

@Masterme не вижу проблем в том, что вы описали.
htmlspecialchars - согласен, может быть не очень удобно. Но в таком случае можно использовать функции/методы обертки. Проблема <?php ?> решается нормальным IDE/редактором. В sublimetext это делается вводом названия конструкции в шаблоне и нажатием tab. Конструкция сама оборачивается в <?php ?> и никаких проблем с этим нет вообще.
На примере Yii, с которым я работаю, могу вас огорчить - наследование шаблонов там реализовано и прекрасно сочетается с нативным шаблонизатором.

Если то, что вы перечислили выше - главные преимущества шаблонизаторов то вы меня не убедили.
Так или иначе в вашем шаблонизаторе будет выполняться экранирование.
Ради достижения сомнительной выгоды от смены <?php ?> на {} или <%%> или чего-то еще вы жертвуете производительностью, на сколько мне известно в большинстве случаев значительной.
Вместо общеизвестных C-подобных конструкций вы наполняете ваше представление новыми конструкциями шаблонизатора, в которых непосвященному человеку проблематично разобраться.
Кроме зоопарка фреймворков и CMS на php мы получаем еще и зоопарк шаблонизаторов, непонятно зачем нужных, усложняющих представления и снижающих производительность.

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

[Masterme]

@BloodyHistory
> На примере Yii, с которым я работаю, могу вас огорчить - наследование шаблонов там реализовано и прекрасно сочетается с нативным шаблонизатором.

можно пример, как это выглядит?

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

главные преимущества шаблонизаторов - работа в естественной семантической модели, минимизация вероятности ошибки (можно настроить htmlspecialchars по умолчанию), пользовательские функции, платформонезависимость (вдруг нужно будет перенести шаблоны на другой ЯП). или вот ситуация - каждый блок требует определённых css и js, причём css должны подключаться в хедере итоговой страницы, а js и инлайновые скрипты - в футере.

убеждать не буду, просто поверстайте с моё - и всё поймёте

Answer 5

[dim4ik]

@Webdesus @Masterme @ruFelix @BloodyHistory
Вопрос по поводу контроллера на примере новостей.

Поясните, что является результатом работы котнроллера в этом случае
массив $data, var_dump которого покажет нам все данные относящиеся к странице новости
или же уже готовая страница?

Хочу поступить следующим образом при формировании страницы новости:
1. контроллер запросил у модели данные, провел все проверки, на выходе получили массив $data для Представления (шаблона) и название шаблона для страницы (или оно внутри $data, возможно еще будет указан формат ответа "html" или "json" для предстваления)
2. Представление (View) получил данные страницы и название шаблона ( тут либо вставил эти данные в шаблон, либо ждем проверки на блоки для вставки все данных сразу вместе с блочными)
3. Теперь ищем блоки и находим блок "комментарии"
4. запускаем контроллер блока, в ответ получаем (данные или html)
5. На этом этапе у нас либо
а) массив $data всех всех переменных для отрисовки страницы
б) либо массив html блоков
6. вставляем их в шаблон

Посоветуйте, пожалуйста, решение.