m5xim Jun 2 at 16:44

Пакет PHP Views — простая шаблонизация проекта с Blade и моделями

Easy

7 min

1.5K

PHP*CMS*Laravel*Symfony*WordPress*

Review

Translation

Comments 12

fso Jun 2 at 16:49

Это конечно хорошо) Но много лет в разных проектах актуальна проблема шаблонизации docx, в основном из-за того, что просто распаковать архив и пропустить contents.xml через шаблонизатор - недостаточно. Ибо тэги шаблонов офисный редактор оборачивает в блоки, которые после "компиляции" грозятся стать не парными, невалидными или вовсе возникнет путаница со вложенностью. Таки документы офисом открываются с ошибками, с дикой текучкой памяти или не открываются вовсе... Сорри за оффтопик, но наболело)

FanatPHP Jun 2 at 18:09

Чисто по подаче выглядит, как инфоцыганство.

Потрясающая производительность. Абсолютно непонятно, за счёт чего, если там везде чистый пхп. Я добавил в эти копеечные шаблоны HTML с главной страницы php.net, просто чтобы немного приблизить их к реал лайф. Результаты:
39.46 ms: Twig (with cache)
142.79 ms: Blade from Laravel (with cache)
205.84 ms: PHP Views without Models (using built-in Blade)
внезапно потрясающая производительность вся куда-то улетучилась.
Отсутствие зависимостей. Ну да, а другие пакеты ставятся с трудом и страданиями.
Широкая совместимость на самом деле абсолютно стандартная
Надежная архитектура: баззворд
Поддержка пространств имён какая-то внутренняя фишка, которая в других шаблонизаторах не нужна.
Плюс какие-то прибитые гвоздями к шаблонам модели
Ну и ~~подписывайтесь на наш телеграм канал~~ поставьте нам звездочку, а то их там всего три штуки, то есть весь этот матёрый проект видело человек 5.

thekingoftheworld Jun 3 at 10:06

Добрый день! Давно хотел узнать, в чем вообще смысл php-шаблонизаторов, как таковых.

Чем код шаблона лучше собственно кода php. Например, какие преимущества имеет вот это

<a href="{{ item.href }}">{{ item.caption }}</a>

против вот этого:

<a href="<?=item['href']?>"><?=item['caption']?></a>

Раньше я слышал версию, что шаблонизатор нужен, чтобы слабо подготовленный контентник не имел доступ к коду php, т.к. во первых, можно вынести шаблоны в отдельные файлы, во вторых, как будто, забытая "}}" не разрушит всю страницу в отличии от забытой "?>". Но теперь, когда в шаблоны протекает логика, циклы, условия и прочее наследования, кажется, что это обмен шила на мыло.

FanatPHP Jun 3 at 11:13

Спасибо за хороший вопрос. Основных причин три

Автоматическое экранирование. Преимущество конкретно этого малюсенького кусочка кода в том, что он не идентичен примеру ниже, который для соответствия должен выглядеть как
```
 <a href="<?=htmlspecialchars($item['href'])?>"><?=htmlspecialchars($item['caption'])?></a>
```
здесь мы убиваем сразу двух зайцев - самых беспечных (которые либо не знают, либо забывают про обязательное форматирование вывода в зависимости от контекста) и самых умных (которые считают, что некоторые переменные и так безопасные и их форматировать не обязательно.
И хотя автоматическое форматирование не панацея, и имеет уже свои недостатки, это огромный шаг вперёд по сравнению с вашим <?=item['caption']?>.
Наследование и блоки. В реальной жизни шаблоны оказываются чуть сложнее, чем ваш пример. Особенно - шаблон основного дизайна сайта, в котором бывает множество мелких исключений. Например, на определённой странице надо подгрузить специальный js или css. Или есть сайдбар, который в каждом разделе сайта отображает свою информацию. В чистом пхп такой сайдбар очень быстро превращается в кучу говнокода. А при использовании шаблонизатора мы в основном шаблоне заполняем этот блок дефолтной информацией, а в шаблоне конкретной страницы мы можем заменить или дополнить её.
Разделение ответственности. Увы, не каждый шаблонизатор может похвастаться следованием этому правилу - как, например, рассматриваемый в этой статье (что также снижает его привлекательность). Разделение это нужно не "контентнику" а самому программисту, который, если дать ему возможность писать в шаблоне на РНР, тут же перетянет половину бизнес-логики в шаблон. А потом кто-то другой будет мучаться, переводя сайт на новый дизайн или на SPA.

censor2005 Jun 3 at 11:40

Ну и не забываем про вкусный синтаксический сахар вроде

<div @class([
  'alert',
  'alert-danger' => $is_error
])>
</div>

или

<option value="{{ $version }}" @selected(old('version') == $version)>

leon-mbs Jun 2 at 20:07

нет ничего проще Mustashe

FanatPHP Jun 3 at 12:53

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

Как в Mustashe выглядит цикл? {{#block}}...{{/block}}. А условный переход?... {{#block}}...{{/block}}. Гениально, Ватсон! Буквально как в анекдоте, "В теории мы миллионеры", а в реальности логика в шаблоне есть, но при этом чудовищно нечитабельная: вместо явного цикла или явного условия - совершенно одинаковый синтаксис, суть которого можно понять только посмотрев тип переменной (и который гвоздями прибит к именам переменных). А дальше начинаются совсем уже танцы вприсядку со специальными именами блоков, типа block_has_items.

Для любого непредвзятого наблюдателя все эти "logicless" шаблонизаторы - просто анекдот.

alexhu Jun 2 at 21:43

Шаблонизатор позволяет подставлять значения в код php. При рендеренге код шаблонизатора преобразуется в php, который трансформируется в html и отдаётся клиенту. Ещё иногда шаблонизатор экранирует данные и можно немного их преобразовать, что тоже можно сделать чистым кодом php без всяких шаблонизаторов. Циклы, условия, очистка данных - наверное вообще не задача шаблонизатора , только библиотеки популярных шаблонизаторов раздуты до совсем уже экзотических методов, которые почти никем не используются. Но разработчики хотят развивать свои разработки и добавляют такое, что уже и понять зачем это и когда применять, бывает трудно.

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

В opencart, Laravel предусмотрены шаблонизаторы и лучше и нам их использовать. В wordpress шаблонизатора нет и wordpress прекрасно работает.

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

Sunvas Jun 7 at 19:09

У меня одного чувство, что для банальной вставки переменных в шаблон как-то слишком уж много телодвижений? Особенно учитывая то, что верстальщик как бы не обязан обладать знаниями всех этих PHP премудростей.

FanatPHP Jun 8 at 04:31

Такое ощущение, что половину комментариев сюда пишет ИИ.

Что именно вы считаете "слишком многими телодвижениями"? Синтаксис шаблона? Код подключения шаблонизатора? Композер? И какая, по-вашему, "вставка переменных в шаблон" не требует этих телодвижений? "похапе инклюде"? При чем тут тогда трогательная забота о "верстальщике", который именно в этом случае и "будет обязан обладать знаниями всех этих PHP премудростей"? А в случае с шаблонизатором ему как раз надо будет знать только его примитивный синтаксис.

Sunvas Jun 8 at 05:43

Что именно вы считаете "слишком многими телодвижениями"?

Всё то, что перечислено у вас в п 3.2: создание рендерера, конфигурирование пространства имён, создание экземпляра менеджера представлений, регистрация пространства имён моделей, определение модели и т.п. Ради чего всё это? Ради автоматического экранирования (которое может и не понадобится)? Какой порог входа в эти нагромождения абстракций?

А в случае с шаблонизатором ему как раз надо будет знать только его примитивный синтаксис.

Юзеркейс: верстальщик в гробу видал этот ваш SSR и желает всё отрендерить на Vue.js. И тут оказывается что использование {{ }} вызывает конфликт; прописать параметр nonce для <script> без того, чтобы лезть в вышестоящий код, невозможно; даже создание JSON объекта из всех переменных шаблона может привести к неожиданным сбоям:

The Blade templating is based on regular expressions and attempts to pass a complex expression to the directive may cause unexpected failures.

FanatPHP Jun 8 at 06:11

Всё то, что перечислено у вас в п 3.2:

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

И главное - верстальщик-то здесь при чём? Который к этим "премудростям" не имеет ни малейшегоо отношения. Подключение и инициализация движка - это на 100% работа бэкендера.

Ради чего всё это?

Вы так и не предложили альтернативу, в которой "всего этого" нету.

Юзеркейс: верстальщик в гробу видал этот ваш SSR и желает всё отрендерить на VUEjs.

В этом случае шаблоны вообще не при чём, а весь вывод делается в том самом Vue. Это отдельный юзкейс. Смешивающего серверную шаблонизацию и SSR гения, который героически решает задачу создания json из переменных шаблона вы себе выдумали сами, к данной статье он не имеет отношения. Ну или если вам реально приходилось с этим сталкиваться в жизни, я вам искренне сочувствую, но нормальные люди отправляют json сразу с сервера. Поэтому снова прошу не путать свой печальный опыт с предметом статьи.