Про фреймворк я говорю в том смысле, что обычно в него включается комплект хелпперов, которые используются в явном виде и выполняют все те функции, о которых идёт речь, тогда и только тогда, когда и где они нужны.
Но вот тут уже пошла вкусовщина, так что предлагаю на этом остановиться.
Спасибо за мнение.
Это всего лишь термины и абстракции. В различных фреймворках они реализованы разными путями, но присутствуют.
В том же «Битриксе» есть те же редактируемые области в шаблоне и шаблоны компонентов, которые вполне себе наследуются внутри сайта/шаблона сайта/шаблона компонента/директории/страницы.
> Это проекты, над которыми работают параллельно несколько людей. В том числе и с шаблоном.
Шаблон позволяет разделять подготовку и отображение данных.
Разделить данные и отображение позволяет модель MVC. Это делается на уровне архитектуры проекта. Например, файлы шаблонов лежат в отдельной директории.
А совместная работа достигается с помощью систем контроля версий. При чём тут вообще шаблонизаторы?
> Язык шаблонизатора имеет упрощенный синтаксис, поэтому ему гораздо проще научить новичка.
Простейшие конструкции и в PHP вовсе не сложны.
А новичёк потом вырастет и всё равно будет вынужден либо выучить PHP, либо уйти в своей специализации от кодинга под шаблонизатор.
Хотя изменение формата передачи данных — это следствие неудачного решения на каком-то этапе.
Да и вообще должно быть единообразие: либо массивы, либо объекты.
А перед выводом в шаблон приводить данные к выбранному варианту.
Откуда данные берутся в шаблоне?
В любой реализации MVC-архитектуры они передаются через какой-то служебный массив или объект.
Вот там их и можно приводить к единому виду согласно собственным соглашениям.
Ну, это всё легко, прозрачно и с настройками делается нативно.
Единственное преимущество — краткость записи, но это дело вкуса и тоже поправимо даже нативно.
То есть ответ такой: «мне не нравится синтаксис языка PHP, поэтому я использую другой язык»?
Можно тогда вовсе избавиться от PHP в пользу более красивого языка )
> поддерживает все возможные математически операции, множество функций
Я про то, что мне всё равно для их использования придётся лезть в новую документацию нового языка программирования.
> можно ли по подробнее, как это выглядит?
У шаблона Ш1 есть входные параметры: П1, П2, П3.
В шаблоне Ш2 я могу сколько угодно раз вызвать шаблон Ш1 с разными значениями параметров П1-П3.
Вполне вероятно, я что-то не понимаю или упускаю, но что ещё предлагается наследовать?
Ну, это детали и дело вкуса.
Точно также вы можете заворачивать передаваемые в PHP-шаблон переменные в любую «синтаксически сладкую» обёртку, унифицируя интерфейс доступа под свой вкус, но оставаясь в рамках нативного PHP. Достаточно легко можно реализовать доступ через $product->image->big->width, если вам так нравится.
Лично я считаю неверным, когда «читатель» сам гадает, нужно ли ему взять свойство объекта или элемент массива (если объект поддерживает оба интерфейса), потому что результат в общем случае будет разным. Так что получатель данных всегда должен рассчитывать только на один стандартный API.
> Но если вёрсткой занимается человек, который далёк от php, и уж тем более от таких вещей, как безопасность выводимых данных, то тут это будет несколько проблематично
В моей практике верстальщик отдаёт HTML+CSS, а данные в него вставляет уже «думающий» программист, который следит за их безопасностью.
> Использование нормального шаблонизатора позволяет забыть об этом в 99% случаев. А добавить | raw когда требуется вывести неэкранированный html — совсем не сложно.
Это просто соглашение.
Можно в рамках проекта принять соглашение, что все входящие параметры шаблона уже безопасны.
Хотя лично мне по душе явные вызовы «обезопасиватеелй».
> вы не заставите об этом помнить тех, кого это не касается — дизайнеров и верстальщиков
То есть в ваших проектах они реально владеют языком шаблонизатора, понимают структуры данных и реально сразу пишут «боевой» шаблон, куда всё верно подставляется?
> Разметка шаблонизатора понятнее и проще, нежели php
Вот уж неочевидно.
Нужно знать, какие инструкции вообще понимает конкретный шаблонизатор, а также каковы параметры инструкций по умолчанию и доступные опции.
> Ну и наследование… представьте себя без наследования в программировании — это море копипаста, вот также и в шаблонах
Не вижу никакой проблемы в любом современном фреймворке: делаете view/partial с параметрами и включаете его в другой view/partial.
Может, я неверно понимаю «наследование шаблонов»?
Можно конкретный пример, кусок кода?
А я попробую описать, как бы я это сделал на чистом PHP.
Но вот тут уже пошла вкусовщина, так что предлагаю на этом остановиться.
Спасибо за мнение.
Руками всё это уже реализовано до нас во фреймворках.
Ничего сложного и страшного в такой реализации нету. И в том числе можно делать это lazy-путём.
В том же «Битриксе» есть те же редактируемые области в шаблоне и шаблоны компонентов, которые вполне себе наследуются внутри сайта/шаблона сайта/шаблона компонента/директории/страницы.
Шаблон позволяет разделять подготовку и отображение данных.
Разделить данные и отображение позволяет модель MVC. Это делается на уровне архитектуры проекта. Например, файлы шаблонов лежат в отдельной директории.
А совместная работа достигается с помощью систем контроля версий. При чём тут вообще шаблонизаторы?
> Язык шаблонизатора имеет упрощенный синтаксис, поэтому ему гораздо проще научить новичка.
Простейшие конструкции и в PHP вовсе не сложны.
А новичёк потом вырастет и всё равно будет вынужден либо выучить PHP, либо уйти в своей специализации от кодинга под шаблонизатор.
Хотя изменение формата передачи данных — это следствие неудачного решения на каком-то этапе.
Да и вообще должно быть единообразие: либо массивы, либо объекты.
А перед выводом в шаблон приводить данные к выбранному варианту.
В любой реализации MVC-архитектуры они передаются через какой-то служебный массив или объект.
Вот там их и можно приводить к единому виду согласно собственным соглашениям.
UPD: Пример реализации: github.com/yiisoft/yii2/blob/master/framework/yii/base/Component.php#L28
Единственное преимущество — краткость записи, но это дело вкуса и тоже поправимо даже нативно.
И для этого целый шаблонизатор?
В моей практике для этого хватало простейших плейсхолдеров типа %ИМЯ%.
Часто «юзеры cms» используют функции или циклы?
Можно тогда вовсе избавиться от PHP в пользу более красивого языка )
Я про то, что мне всё равно для их использования придётся лезть в новую документацию нового языка программирования.
> можно ли по подробнее, как это выглядит?
У шаблона Ш1 есть входные параметры: П1, П2, П3.
В шаблоне Ш2 я могу сколько угодно раз вызвать шаблон Ш1 с разными значениями параметров П1-П3.
Вполне вероятно, я что-то не понимаю или упускаю, но что ещё предлагается наследовать?
Я не уловил, как ваш ответ связан с кешированием и наследованием (1-й вопрос).
В остальном вы лишь подтвердили мои тезисы.
Точно также вы можете заворачивать передаваемые в PHP-шаблон переменные в любую «синтаксически сладкую» обёртку, унифицируя интерфейс доступа под свой вкус, но оставаясь в рамках нативного PHP. Достаточно легко можно реализовать доступ через $product->image->big->width, если вам так нравится.
Лично я считаю неверным, когда «читатель» сам гадает, нужно ли ему взять свойство объекта или элемент массива (если объект поддерживает оба интерфейса), потому что результат в общем случае будет разным. Так что получатель данных всегда должен рассчитывать только на один стандартный API.
В моей практике верстальщик отдаёт HTML+CSS, а данные в него вставляет уже «думающий» программист, который следит за их безопасностью.
> Использование нормального шаблонизатора позволяет забыть об этом в 99% случаев. А добавить | raw когда требуется вывести неэкранированный html — совсем не сложно.
Это просто соглашение.
Можно в рамках проекта принять соглашение, что все входящие параметры шаблона уже безопасны.
Хотя лично мне по душе явные вызовы «обезопасиватеелй».
> вы не заставите об этом помнить тех, кого это не касается — дизайнеров и верстальщиков
То есть в ваших проектах они реально владеют языком шаблонизатора, понимают структуры данных и реально сразу пишут «боевой» шаблон, куда всё верно подставляется?
Вот уж неочевидно.
Нужно знать, какие инструкции вообще понимает конкретный шаблонизатор, а также каковы параметры инструкций по умолчанию и доступные опции.
> Ну и наследование… представьте себя без наследования в программировании — это море копипаста, вот также и в шаблонах
Не вижу никакой проблемы в любом современном фреймворке: делаете view/partial с параметрами и включаете его в другой view/partial.