Александр Воробьев

Если я правильно понимаю то head.html - это тоже шаблон. так что там так же идет обработка. 

PS к слову раз уж речь шла о смене расширения, то тогда и html не совсем корректно, тогда лучше достаточно популярное tpl 

не обязательно. Фронт: фронт на ноде -  React и Next (Vue Nuxt)   и пожалуйста рендер на сервер и СЕО нет проблем.

Хм. может быть, мне кажется это все еще ответственность шаблонизатора, которую можно использовать в CMS. Но и без функционала управления контентом ее можно использовать.

не. тут история другая. Начнем с начала. 

1. все что ВНЕ body не надо пользователю писать непосредственно. Это все формируется HtmlResponse из фреймворка даже а не шаблонизатора. Туда можно добавлять и скрипты и css и все что необходимо прочее. Т.е. шаблонизатор это только про body (учитывая что из него можно регистрировать для хеадера все что нужнл, устанавливать title или метатеги.)   Т.е. это как раз "фишка" фреймворка что есть HTmlRespons - который гарантирует отдачу валидной HTML страницы в целом (т.е без боди все остальное формирует он)

2. В контроллере делаем $response->show('/pages/some.php'). Этот файл может быть таким (из твоего примера):

{%layout base%}
    <div class="theme-toggle dropdown dropup">
      <button
        class="btn btn-primary dropdown-toggle d-flex align-items-center"
        id="theme-toggle-button"
        type="button"
        data-bs-toggle="dropdown"
        aria-expanded="false"
        aria-label="Toggle theme"
      >
        <i class="bi bi-circle-half"></i>
      </button>
      <ul class="dropdown-menu dropdown-menu-end shadow" aria-labelledby="theme-toggle-button">
        <li>
          <button type="button" class="dropdown-item d-flex align-items-center gap-2" data-bs-theme-value="light">
            <i class="bi bi-sun-fill"></i>
            Светлая
          </button>
        </li>
        <li>
          <button type="button" class="dropdown-item d-flex align-items-center gap-2" data-bs-theme-value="dark">
            <i class="bi bi-moon-stars-fill"></i>
            Темная
          </button>
        </li>
        <li>
          <button type="button" class="dropdown-item d-flex align-items-center gap-2" data-bs-theme-value="auto">
            <i class="bi bi-circle-half"></i>
            Авто
          </button>
        </li>
      </ul>
    </div>
{%/layout%}

далее имеем /templates/default/layouts/base.php

<!-- здесь подключение навбара -->
    {%raw __layout.content%}
    {%include css __layout.css%}
    {%include js __layout.js%}
<!-- здесь подключение футера -->

Подключение навбара и футера обозначил комментами, т.к. по сути тут есть варианты у меня. Т.в. в решении что есть сейчас это компоненты (ну т.е. навбар это некий компонент который, например,  "набирает"  хлебные крошки получая инфу от ниже следующих копмонентов). но у меня сейчас еще несколько директив дающих что то среднее между layout и component. (пока окончательно не оформилась идея не буду деталей) :) 

Стили и js в данном случае. Это "не каждому пользователю", это создается разработчиком конкретного каркаса. Эти файлы размещаются рядом. т.е. в данном примере будут   

/templates/default/layouts/base.php, /templates/default/layouts/base.js и /templates/default/layouts/base.css. Это отголоски однофайлового компонента Vue  :)  только там все в одном файле.  Но эти подключения не обязательны.  По  сути может быть ведь каркас кнопки. И, с одной стороны, нет необходимости подключать всегда и/или на всякий случай стили кнопки, с другой не надо подключать файлы по количеству кнопок на странице.

т.е. если

// pages/index.php
{%layout button%}
<button>First</button>
{%/layout%}
{%layout button%}
<button>Second</button>
{%/layout%}

// ... layouts/button.php
{%include css __layout.css%}
{%include js __layout.js%}
<div class="buttons-place">
 <div class="buttons-notice"></div>
 {%raw __layout.content%}
</div>

То пользователь этого каркаса вообще не будет знать о подключении стилей у него просто все заработает - и стили и скрипты. Подключаемые файлы подключатся единожды. Если здесь ставить HTML-подключение файлов - оно будет около каждой кнопки подключаться. 

Для простого подключения стилей/скриптов компонент не нужен. Для этого есть include. Компонент нужен - когда необходима логика. Т.е там может быть все что угодно, с кеширвоанием  и без, с внешними интеграциями и прочим,  при этом на странице может в итоге отобразиться только фраза дня :)

Ну я не воспринимаю как спор. Наоборот это полезно. ( и уж точно полезнее чем в 100500 раз слушать о "с ноля / не с ноля" :) ). Я ж вполне понимаю, что могу быть и не прав, и из обсуждений как раз таки и рождаются полезные мысли. Как пример из твоего  примера пометил себе что не хватает что то типа include но уже строки (<script>....</script>)чтоб гарантировать отсутствия дублирования и закидывать этот кусок либо в head либо вниз страницы (третий параметр include есть сейчас такой)

Пожалуй мы говорим о разном :) не совсем тогда понимаю о чем ты.

Компонент это в первую очередь функционал. Т.е. я вывел {% component  vasoft:catalog %} (который установил композером) и вот у меня полноценное отображение каталга товаров (а это не только тупое отображение списка, но и выборка, учет все возможных скидок, акций и т.п) Что значит его подключить обычным тегом? Т.е. у компонента вывод html важная но не обязательная часть. Может быть это просто подключение кода счетчика на страницу (при чем ИД из конфига, и вывод по условию какомуто).....

Если ты про директиву include. То на первом этапе ее фишка это то, что стили будут подключены один раз даже если по каким то причинам (например использование в разных компонентах и лейаутах), далее это точка для "расширения": склеивать файлы стилей в один/"ограниченное несколько",  или "переключать" на CDN. Так же сейчас дополняется солью, чтобы при изменениях кеш не мешал.

У меня есть опыт проектов выполненных с использованием разных инструментов и без, так что мне, в этом плане, несколько легче и позволяет пропускать лишние итерации.

Зачем каждый раз? не совсем понял. Компонент подключает - пользователь об этом не знает. (По крайней мере до тех пор если не понадобиться переопределить). Но в этом случае он просто размещает нужный файл  в нужном подкаталоге (условно: templates/my-new-year-site-template/component/vasoft/greeting/main/style.css ,  (т.е. когда мой новогодний шаблон сайта и компонент подключен с шаблоном main) штатный css файл замещается указанным. Пользователю так же ни чего не надо "подключать" отдельно.

Ну и бренд тоже не гарантия качества. Уверяю. У жены в ателье приносили на ремонт клиенты вещи очень разных крутых лейблов (речь о тех случаях, что куплены гарантировано в фирменном магазине в Европе). Особенно если заглянуть под капот (например, в изделиях где есть подкладка) - там столько всего "веселого" :)

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

Нет я такого 1000% не говорил. Т.к. я уверен в обратном года эдак с 2003.

Очень надеюсь, что видео помогут мне речь улучшить... Сколько я еще пык-мыков повырезал. Еще, конечно, портит запись видео второпях (времени в обрез). По хорошему бы план короткий написать, а то записал и понял, что сказал не все что надо было бы сказать и показать. В общем работаю над собой.

Да. Над этим вопросом долго думал. И был даже изначально именно с end , но потом все же пришел к слешу. Логика основная, что шаблон это ближе к HTML, а там так конец блока представляется. 

вообще у меня есть идея по расширению функционала директив и там вертикальной черте была роль отведена. Тоже в этом плане у меня было вариантов 5 за эти два месяца :) . Пришел к такому как  сейчас. Вообще к слову. В обработчик шаблонизатора прилетает всего две части: директива (до первого пробела) и все остальное. Таким образом синтаксис параметров на усмотрение разработчика конкретной директивы. И тут от меня возможно однажды будет что то типа "рекомендуемый синтаксис".  А над ним я подумаю , например когда буду форум делать. Пока у самого нет четкой картинки.  Спотыкался и на проблемах от примерно такого синтаксиса который ты предложил, и других... в общем тут надо больше времени и экспериментов.

Тут тоже осмысленное решение. я из тех кто считает php отличным шаблонизатором и не видит ни чего плохого в использовании его в таких качествах. Да понимаю, что это дает криворуким пихать невпихуемое куда не следовало бы.... Но все же..  Решил оставить именно так и да, в шаблоне можно php :)  

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