-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Концепции работы шаблонизатора
- Автор темы DexizeR
- Дата начала
Alexandre
PHPПенсионер
пригласи его в форум, пусть он обоснует свой велосипед.
везет же вам... есть кому готовить кофе
убеди начальника, что логику желательно "впихивать" в представление.
У меня такое ощущение, что в ващшей конторе не делалось сайтов, с выводом более 2х блоков на главной страницы.
Возми, например страницу mail.ru - посчитай сколько там блоков? а теперь посчитай сколько это будет "маленьких шаблончиков".
а теперь прикинь, на сколько твой шаблонизатор справится с такой страницей?
alexhemp
Новичок
Пусть верстает тогда макет в чистом HTML а программист уже оборачивает в шаблон. Мне так приходилось делать, но опыт показал, что в HTML верстальщик прямо из фотошопа сохранял, т.е. факстически версткой не занимался и не умел.
Ни разу не встречал нормального верстальщика, у которого были бы трудности с изучением смарти, даешь ему распечатку половины мануала и усе.
Сложные моменты программист подскажет один раз - дальше по аналогии.
Ни разу не встречал нормального верстальщика, у которого были бы трудности с изучением смарти, даешь ему распечатку половины мануала и усе.
Сложные моменты программист подскажет один раз - дальше по аналогии.
DexizeR
Новичок
Поехали.
Премер шаблона постраничного вывода.
<!-- BEGIN DYNAMIC BLOCK: previous_link -->
<a href="?page={PREVIOUS_NUMBER}">Previous</a>
<!-- END DYNAMIC BLOCK: previous_link -->
<!-- BEGIN DYNAMIC BLOCK: digit -->
<a href="?page={DIGIT}">{DIGIT}</a>
<!-- END DYNAMIC BLOCK: digit -->
<!-- BEGIN DYNAMIC BLOCK: selected_page -->
<font color=red><a href="?page={PAGE_NUMBER}">{PAGE_NUMBER}</a></font>
<!-- END DYNAMIC BLOCK: selected_page -->
<!-- BEGIN DYNAMIC BLOCK: separator -->
|
<!-- END DYNAMIC BLOCK: separator -->
<!-- BEGIN DYNAMIC BLOCK: next_link -->
<a href="?page={NEXT_NUMBER}">Next</a>
<!-- END DYNAMIC BLOCK: next_link -->
На выходе должно появиться, например, следующее:
Previous 1|2|3|4|5 Next
Если парсить блоки обычным способом(т.е. на своем месте), то у тебя получится Previoгs 12345|||| Next
Вот за этим мне и необходима возможность конкатенации блоков.
2. (ПУНКТ 2). Выносить логику в шаблон это, в целом, достаточно хорошее решение, т.к. достигается максимальная производительность потому что парсить шаблон уже не надо. Но возникает вопрос. А зачем тогда использовать какой-то Smarty когда можно с точно таким же успехом использовать код PHP и получать такой же результат(и даже более гибкий и производительный) ?
Я лично считаю что логика в шаблоне вполне здравое решение, т.к. самое производительное, но я не понимаю, зачем в таком случае нужен Smarty и вообще компилируемые шаблонизаторы ?
3. (ПУНКТ 3) Мой шаблонизатор дописан и выдает вполне нормальные результаты страничка с 10тью динамическими блоками и примерно 30тью переменными в общей сложности, работает примерно 0.003-0.005 секунды на P3 1800 mhz с 512 mb ram.
2 Alexandre, как ты видишь мой шаблонизатор сделал твою mail.ru с вполне приличными показателями.
Хочу заметить, что сравнивать компилируемые шаблоны с некомпилируемыми это всё равно что сравнить что работает быстрее - incude или побайтное чтение файла с применением функии eval().
Почему я и мой начальник не хотим использовать комплируемый шаблонизаторы ? Потому что это бессмысленно ! Выгоднее писать чистый PHP код в шаблоне.
Так же хочу сказать, что поскольку вся структура шаблона(вместе с данными) хранится в памяти по кусочкам, то функционал шаблонизатора можно расширять бесконечно без всяких препятсвий и ограничений. Кроме того, я пока ещё не использовал НИ ОДНОГО регулярного выражения в коде.
1. (ПУНКТ 1) Объясняю на примере.
Премер шаблона постраничного вывода.
<!-- BEGIN DYNAMIC BLOCK: previous_link -->
<a href="?page={PREVIOUS_NUMBER}">Previous</a>
<!-- END DYNAMIC BLOCK: previous_link -->
<!-- BEGIN DYNAMIC BLOCK: digit -->
<a href="?page={DIGIT}">{DIGIT}</a>
<!-- END DYNAMIC BLOCK: digit -->
<!-- BEGIN DYNAMIC BLOCK: selected_page -->
<font color=red><a href="?page={PAGE_NUMBER}">{PAGE_NUMBER}</a></font>
<!-- END DYNAMIC BLOCK: selected_page -->
<!-- BEGIN DYNAMIC BLOCK: separator -->
|
<!-- END DYNAMIC BLOCK: separator -->
<!-- BEGIN DYNAMIC BLOCK: next_link -->
<a href="?page={NEXT_NUMBER}">Next</a>
<!-- END DYNAMIC BLOCK: next_link -->
На выходе должно появиться, например, следующее:
Previous 1|2|3|4|5 Next
Если парсить блоки обычным способом(т.е. на своем месте), то у тебя получится Previoгs 12345|||| Next
Вот за этим мне и необходима возможность конкатенации блоков.
2. (ПУНКТ 2). Выносить логику в шаблон это, в целом, достаточно хорошее решение, т.к. достигается максимальная производительность потому что парсить шаблон уже не надо. Но возникает вопрос. А зачем тогда использовать какой-то Smarty когда можно с точно таким же успехом использовать код PHP и получать такой же результат(и даже более гибкий и производительный) ?
Я лично считаю что логика в шаблоне вполне здравое решение, т.к. самое производительное, но я не понимаю, зачем в таком случае нужен Smarty и вообще компилируемые шаблонизаторы ?
3. (ПУНКТ 3) Мой шаблонизатор дописан и выдает вполне нормальные результаты страничка с 10тью динамическими блоками и примерно 30тью переменными в общей сложности, работает примерно 0.003-0.005 секунды на P3 1800 mhz с 512 mb ram.
2 Alexandre, как ты видишь мой шаблонизатор сделал твою mail.ru с вполне приличными показателями.
Хочу заметить, что сравнивать компилируемые шаблоны с некомпилируемыми это всё равно что сравнить что работает быстрее - incude или побайтное чтение файла с применением функии eval().
Почему я и мой начальник не хотим использовать комплируемый шаблонизаторы ? Потому что это бессмысленно ! Выгоднее писать чистый PHP код в шаблоне.
Так же хочу сказать, что поскольку вся структура шаблона(вместе с данными) хранится в памяти по кусочкам, то функционал шаблонизатора можно расширять бесконечно без всяких препятсвий и ограничений. Кроме того, я пока ещё не использовал НИ ОДНОГО регулярного выражения в коде.
SelenIT
IT-лунатик :)
DexizeR
По-моему,
1) Сама необходимость введения динамических блоков в стиле фастТимлпейта вытекает из стремления полностью очистить шаблон от управляющих структур, отдав всякую интерпретацию этих блоков на откуп скрипту. А уж реализация этих блоков в фастТимплейте - сама по себе ужас: одна невозможность разместить несколько блоков в одну строку делают этот подход непригодным во многих дизайнах.
2) Замена переменных на значения - самая базовая вещь в любом шаблонизаторе, прекрасно реализованная на уровне самого PHP, причем несколькими способами.
3) Кажущееся отстутствие условий и циклов в шаблонах а-ля фастТимплейт на деле приводит к запутанности в соотвтетсвующем скрипте - поди с ходу разбери, какой динам. блок парсить, а какой очищать в каждой конкретной ситуации.
4) Требование независимой конкатенации любой части шаблона с любой частью, на мой взгляд, перечеркивает сам смысл шаблонизации: ведь в итоге реализации этого требования "шаблон" опять распадается на кучу несвязанных переменных, логика и порядок вывода которых определяются в скрипте и в итоге зависят в основном от программиста, чем от верстальщика. Шаблон - на то и шаблон, что из него должно быть четко и ясно видно, что во что вложено и что за чем следует.
5)
6)
7)
По-моему,
1) Сама необходимость введения динамических блоков в стиле фастТимлпейта вытекает из стремления полностью очистить шаблон от управляющих структур, отдав всякую интерпретацию этих блоков на откуп скрипту. А уж реализация этих блоков в фастТимплейте - сама по себе ужас: одна невозможность разместить несколько блоков в одну строку делают этот подход непригодным во многих дизайнах.
2) Замена переменных на значения - самая базовая вещь в любом шаблонизаторе, прекрасно реализованная на уровне самого PHP, причем несколькими способами.
3) Кажущееся отстутствие условий и циклов в шаблонах а-ля фастТимплейт на деле приводит к запутанности в соотвтетсвующем скрипте - поди с ходу разбери, какой динам. блок парсить, а какой очищать в каждой конкретной ситуации.
4) Требование независимой конкатенации любой части шаблона с любой частью, на мой взгляд, перечеркивает сам смысл шаблонизации: ведь в итоге реализации этого требования "шаблон" опять распадается на кучу несвязанных переменных, логика и порядок вывода которых определяются в скрипте и в итоге зависят в основном от программиста, чем от верстальщика. Шаблон - на то и шаблон, что из него должно быть четко и ясно видно, что во что вложено и что за чем следует.
5)
Парсить все равно надо. Просто парсинг становится проще, а структура шаблона понятнее. Логике не обязательно быть в виде чистого PHP, ее могут нести псевдотеги типа <IF>...</IF> - думаю, верстальщику, даже девушке, это может быть куда понятнее, чем нагромождение с виду почти одинаковых динам. блоков. А производительности по существу без разницы, где эта логика обрабатывается.
А вот в случае компилирующих шаблонизаторов, действительно, парсить шаблон больше не надо, и производительность действительно лучше
6)
Имхо, скорее минус, чем плюс (см. п. 4). К тому же, поскольку структура рекурсивная, "кусочки" в памяти почти наверняка будут дублироваться.
7)
Аналогично, не вижу оснований гордиться этим как большим достижением. Не верю в настолько значительное преимущество рекурсивной функции на базе substr+strpos+str_replace перед грамотно составленным preg_replace в скорости, чтобы отказываться от лаконичности и гибкости второго. Откуда вообще такая неприязнь к регам? Может, Вы просто не умеете их готовить?
__Lex
Новичок
Глупо спорить, каждый будет отстаивать правильность своего выбора.
Мой выбор smarty, а я уже много делал разных "шаблонизаторов". Он простой и удобный (и не надо спорить, вы хоть один проект с ним грамотно напишите, тогда и сравнивайте). Мой выбор обусловлен:
А теперь попробуйте набрать хоть столько критериев любого другого "шаблонизатора".
-~{}~ 09.02.06 08:21:
к примеру вышеописанный навигатор по страницам я пишу в одну строчку
{pager mask="index.html?page=%s" count=$pager.count page_size=$pager.page_size page=$pager.page}
написав для этого свой плагин (фукцию).
Мой выбор smarty, а я уже много делал разных "шаблонизаторов". Он простой и удобный (и не надо спорить, вы хоть один проект с ним грамотно напишите, тогда и сравнивайте). Мой выбор обусловлен:
- Простотой
- Гибкостью
- Он умеет кэшировать
- Это всё же групповой проект, поэтому лишён аппендиксов
- Хорошо докумментирован
А теперь попробуйте набрать хоть столько критериев любого другого "шаблонизатора".
-~{}~ 09.02.06 08:21:
к примеру вышеописанный навигатор по страницам я пишу в одну строчку
{pager mask="index.html?page=%s" count=$pager.count page_size=$pager.page_size page=$pager.page}
написав для этого свой плагин (фукцию).
DexizeR
Новичок
Да, именно об этом я и толкую с самого начала.
Согласен, но в FastTemplate(по крайне мере в 1.2 версии) можно размещать сколько угодно блоков в одну строку.
Запутанности в скрипте это не даёт ни коим образом. По крайне мере я не представляю себе такую практическую организацию блоков, чтобы было неясно зачем они нужны.
См. пост выше с примером постраничного вывода.
Ошибаешься, если верстальщик знает только HTML, то в сякие циклы и условия на совершенно непонятно языке станут гораздее менее удобным для него, чем динамические блоки обозначенные вообще в виде HTML коментария.5)
Парсить все равно надо. Просто парсинг становится проще, а структура шаблона понятнее. Логике не обязательно быть в виде чистого PHP, ее могут нести псевдотеги типа <IF>...</IF> - думаю, верстальщику, даже девушке, это может быть куда понятнее, чем нагромождение с виду почти одинаковых динам. блоков. А производительности по существу без разницы, где эта логика обрабатывается.
А вот в случае компилирующих шаблонизаторов, действительно, парсить шаблон больше не надо, и производительность действительно лучше
С чего это кусочкам дублориваться ? никакого дублирования не происходит. И на самом деле это плюс, а не минус, т.к. уже не надо знать где динамические блоки. Ещё раз повторяю, структура данных в памяти полностью повторяет сам шаблон, а блоки записаны отдельно по ссылкам - соответсвенно к ним можно напрямую обращаться без всяких регулярных выражений и делать что угодно, хоть очищать, хоть дописывать и т.п.
Например, как произвести замену переменных на, скажем, третьем уровне вложенности динамических блоков с помощью регулярного выражения... Причем в этом блоке есть подблоки и самих блоков этого уровня несколько... С помощью регов решение будет достаточно громоздкое... С моим подходом задача решиться элементарно. Согласен, задача фантастичная, но она показывает гибкость такого подхода.
А вот и ошибаешься, снова. Дело в том, что реги могут выйграть только на первом этапе обработки шаблона(его разбора)... А знаешь почему ? потому что регам этого делать просто не надо. Но с другой стороны, представим себе задачу - есть шаблон с двумя уровнями вложенности блоков, напиши такой код, чтобы пропарсить второй вложенный блок. И ведь прибегать к регам надо будет на каждом этапе обработки шаблона... Вот поэтому они и медленнее.7) Аналогично, не вижу оснований гордиться этим как большим достижением. Не верю в настолько значительное преимущество рекурсивной функции на базе substr+strpos+str_replace перед грамотно составленным preg_replace в скорости, чтобы отказываться от лаконичности и гибкости второго. Откуда вообще такая неприязнь к регам? Может, Вы просто не умеете их готовить?
Я думаю, глупо спорить о том, что хранить шаблон строкой якобы лучше, чем разобрать его на удобную структуру. Кроме того, с такой структурой никто тебе не мешает применять к ней регулярные выражения, если возникнет потребность конечно в них... Дело в том, что когда шаблон разобран в такую структуру - уже не надо искать динамических блоков... И чтобы заменить одну переменную в шаблоне выполниться такой код.
$parsed_blocks['block_of_level2'] .= str_replace("var_name1","var_value1",$not_parsed_blocks['block_of_level2']);
Не думаю, что регулярное выражение применяемое ко всей строке шаблона пытающееся заменить переменную только в конкретном участке строки будет работать быстрее.
-~{}~ 09.02.06 10:20:
Ты не много опоздал... Тут как раз уже решили, что Smarty как функциональная часть проекта совершенно бесполезен ибо все это же можно с таким же успехом написать самим кодом PHP в шаблоне... Единственное его преумщество - девочке верстальщике будет проще понять <IF> </IF>, чем <?if(){?> <?}?> - вот и всё.
__Lex
Новичок
DexizeR
Я считаю тебя не компетентным в этом вопросе. Ты не писал проектов на смарти, о чём ты тогда хочешь поговорить? Поверь, за плечами у меня большой опыт использования разных скриптов.
Можешь продолжать писать <?if(){?> <?}?> упиваясь своей по-детски наивной крутизной, пока я буду заканчивать второй, третий проект. Ты кинул тень на девочку верстальщицу потому, что она девочка и верстальщица?
Разумные люди пишут так, как им удобно, они согласяться со мной и потратят 1 день чтобы разобраться со смарти, но сэкономят огромное колличество часов. В прочем, я не сомневаюсь, что есть и другие достойные скрипты, но, повторюсь, это самый экономный и быстрый в проектировании инструмент.
Я считаю тебя не компетентным в этом вопросе. Ты не писал проектов на смарти, о чём ты тогда хочешь поговорить? Поверь, за плечами у меня большой опыт использования разных скриптов.
Можешь продолжать писать <?if(){?> <?}?> упиваясь своей по-детски наивной крутизной, пока я буду заканчивать второй, третий проект. Ты кинул тень на девочку верстальщицу потому, что она девочка и верстальщица?
Разумные люди пишут так, как им удобно, они согласяться со мной и потратят 1 день чтобы разобраться со смарти, но сэкономят огромное колличество часов. В прочем, я не сомневаюсь, что есть и другие достойные скрипты, но, повторюсь, это самый экономный и быстрый в проектировании инструмент.
первые два пункта противоречат друг другу.
вообще, заявлять про простоту смарти могут только самые оголтелые приверженцы этого монстра.
гибкость - ничего не значащее слово. точно таких же определений можно написать ещё 10 - красота, удобство и так далее.
умеет кэшировать - умеет делать из шаблонов пхп код. очень большое достоинство =) особенно по сравнению с пхп кодом =)
последние два пункта, опять же - доказывают "простоту" смарти, ага.
прости, мальчик, но этот твой довод несёт чисто эмоциональную окраску, и никакой информационной.
поэтому я вынужден тебя попросить не писать сюда больше.
DexizeR
Новичок
Солидарен с ответом Фаната.
Теперь:
1. Ещё раз повторяю. Вынесение управляющих структур дело достаточно хорошее и производительное, но существует и другой подход - создавать шаблоны без управляющих структур. Я выбираю второй вариант, но я не говорю, что первый вариант это ацтой, вопрос упирается в удобство, что согласитесь весьма субъективно и зависит от многих факторов, которые у нас с вами, естественно, различаются. Поэтому предлагаю закончить бессмысленный спор, "что удобнее - шаблоны с управляющими структурами или без них ?"
2. Тема эта создавалась мною о шаблонах без управляющих структур, чтобы узнать о том, какие существуют подходы к парсингу таких шаблонов. Свой подход я уже описал и привел данные которые показывают его эффективность. На данный момент я услышал три разных ответа:
2.1. Использовать CMF(content management framework(?)) - понятия не имею что это такое и примеры мне ни о чём не сказали, т.к. там в шаблоне был один PHP код, какой же это шаблон без управляющих структур тогда ?
2.2. Использовать регулярные выражения... достаточно расплывчатый ответ... Приверженцы такого способа - опишите пожалуйста подробнее свой подход... Чем подробнее, тем лучше.
2.3. Сказали что я изобретаю велосипед, при этом ни привели ни одной ссылки на аналоги.
3. Пишите, пожалуйста, свои ответы аргументированно и подкрепляйте их как можно большим количеством фактов и ссылок. Очень не хочется снова слышать фразы вроде:
"У меня такое ощущение, что в ващшей конторе не делалось сайтов, с выводом более 2х блоков на главной страницы."
или
"сразу становиться ясно, что человек изобретает велосипед, ибо он просто не знает что ему реально нужно."
и т.п. Согласитесь, такие фразы совершенно неконструктивные, и применяя их в подобного рода дискуссиях вы только показываете свою некомпетентность.
Теперь:
1. Ещё раз повторяю. Вынесение управляющих структур дело достаточно хорошее и производительное, но существует и другой подход - создавать шаблоны без управляющих структур. Я выбираю второй вариант, но я не говорю, что первый вариант это ацтой, вопрос упирается в удобство, что согласитесь весьма субъективно и зависит от многих факторов, которые у нас с вами, естественно, различаются. Поэтому предлагаю закончить бессмысленный спор, "что удобнее - шаблоны с управляющими структурами или без них ?"
2. Тема эта создавалась мною о шаблонах без управляющих структур, чтобы узнать о том, какие существуют подходы к парсингу таких шаблонов. Свой подход я уже описал и привел данные которые показывают его эффективность. На данный момент я услышал три разных ответа:
2.1. Использовать CMF(content management framework(?)) - понятия не имею что это такое и примеры мне ни о чём не сказали, т.к. там в шаблоне был один PHP код, какой же это шаблон без управляющих структур тогда ?
2.2. Использовать регулярные выражения... достаточно расплывчатый ответ... Приверженцы такого способа - опишите пожалуйста подробнее свой подход... Чем подробнее, тем лучше.
2.3. Сказали что я изобретаю велосипед, при этом ни привели ни одной ссылки на аналоги.
3. Пишите, пожалуйста, свои ответы аргументированно и подкрепляйте их как можно большим количеством фактов и ссылок. Очень не хочется снова слышать фразы вроде:
"У меня такое ощущение, что в ващшей конторе не делалось сайтов, с выводом более 2х блоков на главной страницы."
или
"сразу становиться ясно, что человек изобретает велосипед, ибо он просто не знает что ему реально нужно."
и т.п. Согласитесь, такие фразы совершенно неконструктивные, и применяя их в подобного рода дискуссиях вы только показываете свою некомпетентность.
Develar
Новичок
DexizeR
2.1 Я неправильно понял твое первое сообщение, так что мое сообщение было оффтопиком.
1 Полностью согласен с SelenIT (http://phpclub.ru/talk/showthread.php?postid=574952#post574952). Ты просишь прекратить спор об управляющих структурах, ссылаясь на "факторы, которые у нас всех различаются". Но 4 пункт его ответа вряд ли различается от проекта к проекту. Твой пример постраничного вывода читается как конфигурационный файл, а не как книга. Чтобы мозг четко и ясно осознал что перед ним - он должен сложить из этих кирпичиков домик. Возникает вопрос - а почему нельзя сразу показать домик?
2 Не думаю что могут быть какие либо другие решения задачи создания шаблонов без управляющих инструкций - я имею ввиду не практическое решение, а теоретическое обоснование. Так как фактически управляющие инструкции перемещаются в код программы и шаблон выступает как конфигурационный файл.
-~{}~ 09.02.06 22:58:
И насчет велосипедов. DAN уже дал ссылку. Not a lot of people know this but PHP is in fact a templating system itself. In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.
2.1 Я неправильно понял твое первое сообщение, так что мое сообщение было оффтопиком.
1 Полностью согласен с SelenIT (http://phpclub.ru/talk/showthread.php?postid=574952#post574952). Ты просишь прекратить спор об управляющих структурах, ссылаясь на "факторы, которые у нас всех различаются". Но 4 пункт его ответа вряд ли различается от проекта к проекту. Твой пример постраничного вывода читается как конфигурационный файл, а не как книга. Чтобы мозг четко и ясно осознал что перед ним - он должен сложить из этих кирпичиков домик. Возникает вопрос - а почему нельзя сразу показать домик?
2 Не думаю что могут быть какие либо другие решения задачи создания шаблонов без управляющих инструкций - я имею ввиду не практическое решение, а теоретическое обоснование. Так как фактически управляющие инструкции перемещаются в код программы и шаблон выступает как конфигурационный файл.
-~{}~ 09.02.06 22:58:
И насчет велосипедов. DAN уже дал ссылку. Not a lot of people know this but PHP is in fact a templating system itself. In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.
DexizeR
Новичок
Согласен с тобой, насчёт домика и кирпичиков. Всё верно, но у нас шаблон действительно уже выступает именно как конфигурационный файл(задача фактически в этом и заключается), неплохая аналогия.
"In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code."
У нас цель - отделить именно PHP код от именно HTML кода, а не отделить логику представления от бизнес логики посредством шаблонизатора, кстати, логика представления это немного не точно, точнее будет бизнес логика представления(т.е. специфические для этого проекта требования к отображению информации) - этим и отличаются функциональная часть корзины(например) в одном проекте от другого - бизнес логикой(как в управлении так и в выводе - и в шаблон однозначно попадут логические элементы специфичные только для этого проекта).
Почему мы не хотим использовать шаблоны с логикой представления ? Скорее это дело привычки, но есть и весомый аргумент - не надо обучать верстальщика и каждого человека работающего с шаблоном(что достаточно накладно) или нанимать отдельного человека который будет создавать логику представления в шаблоне...
Кроме того, можно сделать ещё один подход - отделить HTML от логики представления, а логику представления от бизнес логики .))) Мы бы могли так сделать, но нам интересен шаблон именно только как конфиг который без труда сможет подправить любой заинтересованный человек. И нам не интересно отделять логику представления от бизнес логики посредством шаблонизатора.
"In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code."
У нас цель - отделить именно PHP код от именно HTML кода, а не отделить логику представления от бизнес логики посредством шаблонизатора, кстати, логика представления это немного не точно, точнее будет бизнес логика представления(т.е. специфические для этого проекта требования к отображению информации) - этим и отличаются функциональная часть корзины(например) в одном проекте от другого - бизнес логикой(как в управлении так и в выводе - и в шаблон однозначно попадут логические элементы специфичные только для этого проекта).
Почему мы не хотим использовать шаблоны с логикой представления ? Скорее это дело привычки, но есть и весомый аргумент - не надо обучать верстальщика и каждого человека работающего с шаблоном(что достаточно накладно) или нанимать отдельного человека который будет создавать логику представления в шаблоне...
Кроме того, можно сделать ещё один подход - отделить HTML от логики представления, а логику представления от бизнес логики .))) Мы бы могли так сделать, но нам интересен шаблон именно только как конфиг который без труда сможет подправить любой заинтересованный человек. И нам не интересно отделять логику представления от бизнес логики посредством шаблонизатора.
