Челендж на 2026

Могу даже видео ответ дать на вопрос "зачем" :)  Отвечал не я. Так совпало, что в начале года прошла пара "php линчей" (код ревью). В т.ч. и Yii3 и отвечая на вопросы автор канала (Валентин Удальцов - думаю большой шанс, что кто погружен в php знает его. Он например в прошлом году конфу по php собрал) затронул и этот момент.

Так что вот ответ (с привязкой ко времени). на Вк и на youtube 

Спасибо, Александр, очень важный акцент с точки зрения проф. развития и самоудовлетворения от процесса.

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

[7/12] Релиз шаблонизатора

В самом фреймворке были некоторые изменения в основном "для пользы" шаблонизатору. Выпустил релиз 1.5.

Основные работы были по шаблонизатору и релиз 1.1.0 состоялся. Для шаблонизатора есть дока

Из основного:

Поддерживаются две формы {{переменная}} (для вывода значения переменной) и {% директива [...параметры] %}  - различные функциональные директивы. Можно добавлять, при необходимости, свои формы "тегов". В указании переменных поддерживается точечная нотация для доступа к значениям на любой глубине массивов

Сейчас реализованы базовые директивы:

- if...elseif..else,  foreach  - условие и цикл

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

- include - подключения подключаемых файлов стилей и скриптов

- defer - отложенный вывод значения переменной. (например для h1, который может быть изменен любым компонентом логика которого будет выполнена уже после вывода тега h1 на страницу)

- scrf - вывод токена.

- component - подключение компонента.

Директивы можно создавать и регистрировать свои.

Компоненты в "коробке" нет компонентов, но есть механизм для их подключения. Компонент это блок обладающий своей бизнес логикой, который подключается на странице и может подключать стили и скрипты и выводить свои блоки. У компонентов можно создавать разные шаблоны для вывода (т.е. один и тот же компонент может иметь разное представление на итоговой странице) Можно разрабатывать свои компоненты. 

Шаблоны сайта - поддерживаются разные шаблоны сайта. Тут для удобства: один шаблон для админки, другой для публичной части  и т.д...

Коротко постарался показать работу с шаблонизатором (включая создание своей директивы и своего компонента) в видео ВК и  youtube

Сейчас начал работу над модулем взаимодействия с базами данных

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

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

ЗЫ. Может позже до тебя всё же дойдёт почему я придумал свой этот подход с XML. И интересно бы узнать как ты сделаешь работу с БД, я говорил уже что то, что ты мне раньше предлагал мне не подходит, я вот буду делать по другому.

Не было такого ни когда абсолютно. Речь была совершенно о другом. Я тебе говорил в этом нет ни чего оригинального и это реализовано везде. Подход правильный и логичный.

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

Ну плохая или нет это надо тестами проверять.  я, например, уверен на 99% что использование XML (по крайней мере в том виде как в той версии что есть у меня твоего фреймворка - это сильно хуже. как минимум там, по сути, отключаются возможности по ускорению встроенные в язык. Так что это все только мнения без реальных сравнительных тестов.  Ну опять же если "похож" на смарти синтаксис это не значит, что он похож на сам смарти.

Ну и возможно главное, мне было интересно поработать с AST деревом, а не использовать готовые библиотеки для работы с DOM.

В том что мне не нужен XML я уверен на 100%. Единственный профит в техническом плане мог бы быть  в том, что заменить мою построение AST дерева на встроенное ( и это действительно может ускорить, но дело в том, что при правильном подходе это не нужно делать на каждом хите). Т.е. один этап из всей процедуры тяжелый конечно может быть.

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

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

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

По самому шаблонизатору - неплохо. Так как я сравниваю с эталоном - jinja2, несколько замечаний.

- закрывающий тэг {% | foreach%} - сложно читать, я бы уже использовал что то типа {% end foreach %} - проще и понятнее.

- директива - это скорее фильтр и вот его лучше применять как {{ <var>| filter:d:M:Y }} - нагляднее

- ты для шаблонов-templates используешь расширение .php 

Шаблон это уход от вставок прямого кода в фронте, поэтому я бы использовал *.html - опять же нагляднее и понятнее.

Но в целом все грамотно и понятно, есть система наследований, если ее доработать то будет вообще хорошо.

Работа с CSS - по мне - избыточно, нет необходимости так делать, проще стили подключать из папки /static  напрямую.
Ну и мне показалось что в классах у тебя нарушение SOLID, но надо пересмотреть, может я что-то упустил, показалось что есть нарушение Single responsibility princip

в целом круто - молодец!

Единственная мысль, которую я озвучивал и ты мог воспринять таким образом: я говорил что на определенном этапе фреймворк/шаблонизатор может собирать такие разрозненные файлы в один или несколько объединяющих. Что важно для сайтов которые используют http 1.1 (надеюсь, правда, таких уже нет практически) особенно если размер одного такого несклеенного файла менее примерно 1.5КБ   . для http2 +  это уже чуть менее критично.

У меня такого пока нет :) т.е. у меня будут все по отдельности (конечно один  и тот же подключается только раз)... Но в планах добавить механизм склейки.

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

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

ЗЫ. Поэтому мне проще доделать всё и наглядный пример работы это единственный мой аргумент в данном случае.

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

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

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

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

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