Околонаучные рассуждения о пользе и вреде шаблонных движков (вроде не флейм)

Околонаучные рассуждения о пользе и вреде шаблонных движков (вроде не флейм)

Вот, тут возникли у меня некоторые мысли по поводу шаблонизаторов. Не знаю, правильно ли такие темы создавать в «для продвинутых», но, боюсь, в оффтопике тему очень быстро превратят в помойку, хотя возможно что то, что я напишу и есть помойка. Тогда переносите в оффтоп.

Так вот. На форумах постоянно мелькают споры, о том, хорошо или плохо – эти шаблоназаторы. При чем в обсуждении учавствуют, как правило сторонники трёх подоходов:
1. Сторонники шаблонов и специальных шаблонизаторов, руководствующиеся, в первую очередь, принципом разделения кода и оформления.
2. Сторонники сложных шаблонных движков, которые руководствуются принципом, что в шаблоне должно быть не только оформление в чистом виде, но и логика отображения. Сюда можно отнести, в т.ч. любителей MVC.
3. Противники шаблонных движков, считающие что отдельный шаблонизатор – лишнее звено благо PHP сам по себе является шаблонизатором.
Ну и все обсуждения между этими тремя группами в итоге заканчиваются флеймом, и ни до чего не доходят.

А я тут задумался вот над чем. Если посмотреть мануал по PHP, то самым первым что мы увидем, это раздел «Что такое PHP», в котором в первую очередь приводится как плюс то, что можно мешать HTML и PHP. При этом приводится пример, из-за которого любой новичек может начать писать код именно так, как нельзя писать – полностью смешивая в одну кучу всё – и данные и дизайн и оформление. Однако же любой более ли менее опытный PHP-шник прекрасно понимает, что да – это плюс языка, но далеко не самый важный.
Так вот и касаемо шаблонизаторов – является ли главной причиной их использования то, что шаблонизатор разделяет код и оформление? А может быть это всего-лишь «фишка», дополнительный плюс?
Очередной раз перерабатывая свой фреймворк, я задумался на эту тему. Я использую шаблонизатор – самый, что ни на есть простой – xtemplate (xtpl.sourceforge.net). Но могла ли моя система существовать без него? Не могла бы. Архитектура системы построена так, что ей необходима некая прослойка, в которую можно отдать данные, которые выводит Фреймворк. Это один из способов выполнения его основной задачи – универсализации подходов, с целью облегчения разработки однотипных элементов.
Поскольку уже на уровне проектирования, для облегчения задач по выводу данных используется шаблонизатор, без него мне не обойтись. И, к сожалению, использование PHP в чистом виде, а так же «логических шаблонизаторов» вроде Smarty для системы неприемлемо, поскольку становится невозможным управлять выводом той же админки непосредственно из main-модуля системы, который изначально построен на управлении блоками вывода (и именно интерфейс работы с блоками мне и даёт шаблонизатор).
Разделение кода и оформления – ну, это уже просто побочное и приятное последствие основной задачи.
MVC. Этот подход по определению требует наличие прослойки работающей с шаблонами. Плюсы или минусы подхода, это тема для отдельного обсуждения – и здесь каждый волен решать сам. Но, опять же, разделение кода и оформления, скорее является последствием подхода, чем главной причиной выбора шаблонизатора.
Ну и, наконец, позиция людей, которые не используют MVC, и наработки которых построены так, что шаблонизатор как таковой не нужен (в т.ч. я сюда и отношу использование логических шаблонизаторов в «голом» виде). Здесь основной целью использования шаблонов, как правило, ставится отсутствие возможности поддаться соблазну, и начать использовать в шаблоне PHP так, как этого не следует делать (например, переносить в шаблон логику получения, а не вывода данных). Как видно – ни один из подходов не противоречит идее разделения кода и оформления. Но везде это является следствием изначально выбранного подхода.
Несколько раз я читал, уже ставшее едва ли не крылатым выражение, которое предписывается Ромику(фанату), о том, что «единственная цель использования шаблонов – это что бы для изменения дизайна не надо было лезть в код». Не ручаюсь за точность цитаты, поскольку не видел изначального оригинала (даже не могу быть уверен, что он такое говорил – просто рядом с такими фразами я видел его (с)).
Некоторые особо умные личности, сделали из этой фразы культ, и используют её, тупо копируя, но нисколько не пытаясь понять её смысл. А ведь это – всего лишь одна из немногих причин, по чему разработчик может использовать отдельный шаблонный движок. И нельзя эту причину ставить как единственный довод против шаблонных движков. Поскольку во многих случаях (но не во всех) – это одна из последних целей использования шаблонизатора. Так же, вспоминается статья на спектраторе, посвященная шаблонизаторам, где автор пытается показать, что PHP – сам по себе хороший шаблонизатор. Но опять же – проблема в том, что автор всего лишь выводит мысли, касаемые одного, конкретного подхода, ни слова не говоря про существующие архитектурные решения.

З.Ы. Вопроса здесь нет – это просто повод поразмыслить. И возможно поправить меня – если я где-то ошибаюсь.
 

Demiurg

Guest
Вменяемых противников шаблонизаторов я не видел давно.
А то, что любая система сильно завязана на используемый шаблонный движок - это и так понятно.
 
Demiurg
1) На самом деле, я то же. Но, мало ли...
На самом деле, у меня есть задняя мысль - вывести отсюда маленькую-маленькую статью-рассуждение, для невменяемых и начинающих, да бы некоторые поняли таки это.

По этому, было бы интересно такого(вменяемого) все-таки найти. Или, возможно, какой-то аспект я еще не совсем учел.
 

Screjet

Новичок
Дмитрий Попов
И, к сожалению, использование PHP в чистом виде, а так же «логических шаблонизаторов» вроде Smarty для системы неприемлемо, поскольку становится невозможным управлять выводом той же админки непосредственно из main-модуля системы, который изначально построен на управлении блоками вывода (и именно интерфейс работы с блоками мне и даёт шаблонизатор).
А что значит управлять блоками вывода?
 
Screjet
Ну, в контексте моей системы - шаблон представляет из себя набор блоков. Весь сайт - это, как правило, один шаблон (не файл шаблона, а именно шаблон), разделенный на блоки с определённой иерархией. И система работает именно с этими блоками, указывая с каким именно блоком что и как делать, и передавая переменные для конретных блоков.

С PHP и Samrty(насколько я успел понять последний) делать такое довольно проблематично, поскольку может быть множество блоков, называющихся одинаково но находящихся в соверешнно разных блоках более высокого уровня (например: msglist.row.i, msglist.col.i, news.row.i, news.col.i etc).
Ну и плюс - сама система может указать сколько раз вывести, в каком виде.
З.Ы. Неисключено что это можно делать и со смарти, но у xtpl - идеальный интерфейс для этого
 

AlMaz

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

Фанат

oncle terrible
Команда форума
не выходит.
в том-то всё и дело, что не выходит.
программирование в шаблонах - обыденная вещь. взять хотя бы xslt
 

Demiurg

Guest
>а это уже выходит за рамки понятия шаблонов.
у смарти в шаблонах логика отображения, а логику надо программировать, так что твое утверждение не верно.
 
AlMaz
В принципе, абсолютно не исключен подход - когда в шаблон вообще могут передавать абсолютно все возможные данные - а шаблон будет сам определять надо их выводить или нет, где и как. И этот подход - имеет право на существование.
Основная проблема, тех кто начинает в таких темах спорить с позиции "против", что они не могут понять, что технологий и архитектурных решений существует бесчисленное множество. И то, что при Вашем подходе - возможности Smarty излишни отнюдь не означает, что стиль программирования и проектирования другого разработчика, наоборот полнолстью соответствует необходимости использовать smarty.
Плюс xsl, как уже сказал Рома.

И вообще - я не зря упомянул про MVC, который Вы то ли проигнорировали, то ли вообще не знаете. Там вообще, шаблонизатор, можно сказать - ядро системы, а шаблон - вся логика вывода информации.
 

AnToXa

prodigy-одаренный ребенок
Возможно я чуть не в тему, но поясните мне пожалуйста почему же так плохо выносить в шаблон именно логику __получения__ данных?

т.е. "шаблон"(шаблонный движок, view), просто знает что куда обратиться за данными и знает как их вывести, блоками там или в xml отдать.

обращаяется он ессно не в базу, а к некоторым абстракциям, которые уже сами знат куда бы им заползти чтобы данные получить.
хотя похоже, что сейчас пхп скрипт сам и является такой прослойкой между view и controller(который представлен некими библиотеками в пхп, самописными или встроенными, вот как framework у димы попова).

при таком раскладе сильно разгружается логика приложения(controller) в общем-то и как раз достигается решение вопроса с завязванием системы на шаблонный движок.
 

McLay

PHP5 BetaTeam
А в чем плюсы у смарти, xslt, и прочих шаблонных языков, по отношению к простому разделеню логики и отображения по разным php файлам(ну и пространства имен переменных тоже можно отделить)? Соответсвенно, сам шаблон будет написанн также на php. Пока для меня видится только один плюс(не такой уж и очевидный) - простота для дизайнера.
 

inTox

вёбных дел мастер
вы все еще не отделяете дизайн от представления? тогда мы идем к вам.

Отделение д. от п. - это абстрактный императив, в подчинение которому очень часто ставятся:
1. Простота кода.
2. Производительность системы.
3. Здравый смысл.

Мне кажется что в корне неверно ставить вопрос как "за" и "против" в общем случае - это не имеет никакого практического смысла, кроме как даёт повод потрындеть. Гораздо результативнее рассуждать о целесообразности использования для каждой конкретной архитектуры исходя из её задач. На сложном проекте (то есть синдицирующем большое кол-во разнородных и взаимозависимых данных), какой бы шаблонизатор вы не использовали, как бы не "отделяли данные от представления" всё равно рано или поздно придется плясать с бубном (апологетам XSLT могу напомнить про группировку Мюнхена, например, или exslt). Или изменять структуру данных.

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

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

Макс

Старожил PHPClub
И вообще - я не зря упомянул про MVC, который Вы то ли проигнорировали, то ли вообще не знаете. Там вообще, шаблонизатор, можно сказать - ядро системы, а шаблон - вся логика вывода информации.
это что у тебя за MVC такой интересный ? :)

В MVC есть разные подходы и все имеют право на жизнь.
Некоторые слабо разделяют контроллер от представления (возможно ты это имел ввиду ?)
Само предсталение может иметь логику (native PHP, Smarty, XSLT), а может быть разделено на 2 части : логика представления и простые шаблоны без логики
 

svetasmirnova

маленький монстрик
Мне кажется, вот эта фраза:
>MVC. Этот подход по определению требует наличие прослойки работающей с шаблонами.

применительно к PHP содержит противоречие. Смотрим.
model.php:
PHP:
$a = foo();
view.php:
PHP:
красота
<?=srttoupper($a)?>
красота
controller.php:
PHP:
include 'model.php';
include 'view.php';
Это не MVC? И где тут дополнительный шаблонизатор?
Или пример использования Smarty из мануала:
PHP:
{php}
		// including a php script directly
		// from the template.
		include("/path/to/display_weather.php");
{/php}
И где тут отделение логики от отображения?

То есть я хочу сказать причём здесь шаблонизатор?
 

Demiurg

Guest
svetasmirnova
плохой пример из мануала.
мне лично кажется, что некоторые вещи, которые есть в смарти просто не нужны. В том числе и {php}
 
AnToXa
т.е. "шаблон"(шаблонный движок, view), просто знает что куда обратиться за данными и знает как их вывести, блоками там или в xml отдать.

обращаяется он ессно не в базу, а к некоторым абстракциям, которые уже сами знат куда бы им заползти чтобы данные получить.
обращаяется он ессно не в базу, а к некоторым абстракциям, которые уже сами знат куда бы им заползти чтобы данные получить.
Собственно ты сам все сказал... Потому я просто не знаю что ответить =)

McLay
У Xslt - совершенно своё отдельное и однозначное применение. Применение в связке с XML. Возможно существуют ситуации, когда необходимо отдавать данные в xml, но пользователю отдавать их в html.
Smarty - не отвечу, т.к. не знаю.

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

Вот например, как с помощью голого PHP, я смогу сделать следующее:
Написать функцию, с параметрами A,B и C которая выводит в указанном в параметре A шаблона B сообщений (которые передаются в другом параметре C).
Учесть, что для одной страницы возможно сколько угодно вызовов для каких угодно параметров A,B и C.
Соотетственно в шаблоне, написанном на PHP недолжно возникать конфликтов.

А по такому принципу у меня работает вся система. И блочное иерархическое хранение/отображение шаблона (родственное Dom, кстати) - лучшее решение.

Вы поймите же - сайты делаются с нуля только поначалу. Рано или поздно любой программист начинает думать об универсализации. А универсализация подразумевает четкую структуризацию всех этапов и аспектов разработки.
 

Screjet

Новичок
Дмитрий Попов
сама система может указать сколько раз вывести, в каком виде.
Неясно, что значит "в каком виде"? Вид как раз и формируется шаблоном, или шаблон может динамически меняться?
 

svetasmirnova

маленький монстрик
Demiurg
В общем я немножко о другом. При обсуждение подобных вещей постоянно берётся за аксиому, что использование шаблонизаторов само по себе приводит к разделению логики от отображения, но это скорее вопрос дисциплины при программировании, чем использования той или иной технологии. А возможности типа {php} как ни крути нужны, хотя бы для простого написания/использования какой-нибудь украшательной функции (хотя в Smarty это и по-другому можно сделать?)
 
svetasmirnova
Это не MVC? И где тут дополнительный шаблонизатор?
controller.php

svetasmirnova
То есть я хочу сказать причём здесь шаблонизатор?
Сдаётся мне - меня никто не понимает.
Гораздо результативнее рассуждать о целесообразности использования для каждой конкретной архитектуры исходя из её задач
вот, именно это я и говорю.

обратите внимание - я нигде не сказал, что шаблонизатор - это только Smarty или xtpl.
Даже вот такая функция:
shablon($vars,$file)
{
include($file);
}
может быть шаблонизатором.
И при определенных условиях - такой подход тоже оправдан.
Кто-то генерит XML, натравливает на него sablotron, и все работает. Кто-то пишет шаблоны на PHP, и рекьюрит их по типу указанного в функции. Это все - различные подходы и архитектурные решения. И все они имеют право на существование.

И глупо обсуждать пользу шаблонизаторов как таковых. Это не глупо - это нельзя делать в принципе. Это можно делать, только при рассмотрении конкретного проекта/решения/технологии.

Screjet
Система может определить - выводить этот блок или не надо. Выводить мыло или форму для отправки мыла. Выводить пароль, или нет, т.к. он хранится в md5.
Сама система определяет - использовать select или chekbox. Под "в каком виде" я имел ввиду именно это. И уже тогда она говорит шаблону:
вывди блок страница.форма_редактирования.строка.селект. Отпарси блок страница.форма_редактирования.строка

Но! При этом я не исключаю возможности обратного подхода, когда шаблон просит "система, а дай как мне данные для чекбосов".
 
Сверху