Как вы отделяете код от представления?

#php #стиль

Как вы отделяете код от представления (например от html) в больших проектах?

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

Лично я формирую массивы данных в контроллере и через функцию произвожу подключение
.tpl файла, в функцию передаю массив данных, а функция возвращает буферизированное
решение этого файла. В самом файле нужный контент (html, xml, json...) с php вставками
переменных вроде: 



У меня вопрос к такому подходу только один. Когда возникает потребность вставки в
шаблон других шаблонов (например 10 коротких новостей в шаблон главной страницы), приходится
составлять в контроллере каждый такой эллемент и передавать его в основной.

Допустимо ли с точки зрения идеологии MVC в таких файлах шаблонов производить подключение
шаблонов напрямую? Не важно в цикле или чем-нибудь вроде View::renderMatch('short/article.php',
$data['articles_data_array'])

Не затрагивает ли такой сбор шаблона обязанности контроллера? Вопрос не обязательный
для ответа.

Главный вопрос в том, как вы отделяете в своих проектах логику представления, от
шаблона и делаете ли это вообще. Было бы интересно почитать как это делают другие люди.
    

Ответы

Ответ 1

Другие люди используют шаблонные движки. Хоть Smarty, хоть Liquid, хоть Mustache,
хоть Twig или Blade.

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

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

Шаблонные движки приводят к некоторому замедлению открытия страниц при первой компиляции
шаблона, но эта проблема решается массовой компиляцией шаблонов при деплое.


Ответ 2

Обычно есть контроллеры, которые собирают данные для представления (виды), и, если
надо, запускают валидацию введенных данных. Модели содержат логику по получению данных
из БД и т.д., контроллеры используют методы моделей и не лезут в БД самостоятельно. 

Виды занимаются только формированием окончательного HTML. 
Никакой сложной логики, никакого обращения в БД. 

Как правило есть привилегированный вид - макет (layout), который содержит общий код
для ХТМЛ страниц и в определенное место которого вставляется результат обработки вида.

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

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