Комментарии 20
Интересный велосипед, жду новую статью "Как я изобрел mvc", после нее "Как я изобрел компонент" и так далее.
Не, ну автор молодец.
Потрудился чтобы структурировать информацию, оформил всё в репозиторий, написал статью
Думаю что благодаря этому автор подрос как разработчик.
Теперь нужно рефакторить код. Можно начать с именования. Например:
BlockA
block-a.twig
block-a.css
BlockA.php
BlockA_C.php
Не знаю есть ли смысл в том чтобы создать структуру директорий, например
assets
css
js
images
templates
Но именование BlockA_C.php кажется не очень правильным, потому что у вас неймспейс уже дает уникальность имени. А если вы захотите переименовать BlockA -> ModalBlock или как еще, то вам придется переименовывать все файлы. Или захотите скопировать блок.....
Поэтому внутри блока можно было бы файлы называть одинаково, например Controller.php(ну или что то типа того) и т.д.
Block
block.scss
Theme
First
block--theme--first.scss
Это совпадает с BEM и мне кажется более удобным, чем разделение по типам файлов. Касательно одинаковых имен, да, технически это возможно, но я исходил из удобства редактирования (имхо), в случае одинаковых имен когда в IDE будут открыты одновременно несколько блоков различать их будет менее удобно, и опять же текущий способ более похож на BEM и будет более привычен для тех кто знаком с ним. Копирование блоков я использую довольно часто, в каждом проекте есть дефолтный блок и я создаю блоки с него, чтобы избежать ненужной рутины. По-этому в пакете также есть команда для копирования блоков с заменой имен
Потрудился != молодец.
Каждый блок надо создавать и настраивать вручную, потом в одном блоке что-то изменистя и бегай по коду меняй.
Та же MVC + компоненты в блейде, или даже шаблоны в twig дают куда большую гибкость.
Посоветую посмотреть на https://github.com/symfony/templating и так же прогнать проект с помощью https://github.com/squizlabs/PHP_CodeSniffer (Вы уж извините, но нейминг и форматирование ужасны и сложно читаемы). Так же почитайте PSR-12, BlockA_C
- не очень валидное название класса. Ну и MVC - это не про наследование модели и контроллера от одного класса. Так же попробуйте учесть варианты, что блоки не обязательно должны быть в одном каталоге (их теоретически может быть много и они могут быть связаны). В целом - идея может и взлетит, но сейчас это не похоже на пакет, которым можно пользоваться.
MVC — это не про наследование модели и контроллера от одного класса
абсолютно согласен, однако в данном случае наследование необходимо для чисто технического момента, как чтение полей, и ничего более. И разделение: модель — отображение — контроллер для распределения ответственности по-моему в данном пакете реализовано довольно прозрачно.
Так же попробуйте учесть варианты, что блоки не обязательно должны быть в одном каталоге
А зачем? Пакету необходимо указать лишь одну родительскую директорию, а поддиректорий может быть сколько угодно. Я думаю для большинства случаев этого будет достаточно.
В целом — идея может и взлетит, но сейчас это не похоже на пакет, которым можно пользоваться.
У вас есть конкретные предложения по этому поводу?
наследование необходимо для чисто технического момента, как чтение полей, и ничего более.
если надо чтение полей - сделайте, например, класс со статической функцией, которая будет читать поля объекта и не зависеть ни от чего. Не нужно наследовать "контроллер" и "модель" ради реализации пары функций да еще и с надежой на протектед поля. Создайте интерфейс контроллера и модели что бы быть уверенным, что это тот объект, что ожидается, а не надежда на путь к папке и строгое имя для "моделей" и "контроллеров". Почему в кавычках? - Да потому что в Вашем случае это не модели и не контроллеры.
А зачем?
А затем, что я, например, сам предпочитаю выбирать, где и как размещать классы (я буду следовать PSR-4, этого должно быть достаточно). Вы же диктуете правила, которые можно обойти интерфейсами. А зачем мне тогда такой пакет, а не симфони темплейтинг например? (который уже deprecated, кстати) Хотя это риторический вопрос, мне не нужно шаблонизировать темы под вп =)
У вас есть конкретные предложения по этому поводу?
нет.
Создайте интерфейс контроллера и модели
Вы же диктуете правила, которые можно обойти интерфейсами
Тогда сама идея изменится. Благодаря ограничениям нет необходимости указывать каждый раз путь к шаблону, нет необходимости указывать класс модели для контроллера. Не вижу ничего плохого в наследовании, тем более что наследники будут решать четко установленные задачи. И использование protected полей класса вместо прямого массива (как например в в symfony) дает ряд преимуществ
Почему в кавычках? — Да потому что в Вашем случае это не модели и не контроллеры.
В привычном прямом понимании да. Данные имена были выбраны чтобы люди знакомые с MVC могли провести аналогии. Если рассматривать каждый блок в отдельности, то Model ожидаемо предоставляет данные, View (twig) их отображает, а Controller управляет зависимостями
Тогда сама идея изменится. Благодаря ограничениям нет необходимости указывать каждый раз путь к шаблону, нет необходимости указывать класс модели для контроллера.
Если бы блоки создавались автоматом - этого как раз можно было бы добиться.
Посмотрите на компоненты в angular.
нейминг конечно ужасный :)
Если не трудно, хотелось бы пару примеров из кода с альтернативной версией (правильной по вашему)
С некоторыми шаблонами «конкурентов» знаком, как WordPress, Symfony, Codeigniter. Также альтернатив, подобных уже существующих пакетов, которые делают то же самое при поиске не нашел.
Yii2 виджеты, Битрикс (прости господи) компоненты.
По факту у вас обычная MVC, хотя в данной ситуации контроллер который просто возвращает модель как таковой не нужен (опять если делать референс в сторону Yii2 термин «виджет» больше подходит, нежеле «контроллер», хотя суть та же самая: модель -> виджет -> вьюха). Могли сократить сущности до модель — вьюха, а сам рендеринг скинуть на какую-то отдельную сущность например Renderer, т.к. для каждой модели не нужен отдельный контроллер.
Если не трудно, хотелось бы пару примеров из кода с альтернативной версией (правильной по вашему)
ArticleC и HeaderC это че такое?)))
Yii2 виджеты
Спасибо за уточнение, не сталкивался с Yii, посмотрел, у них пожалуй самые развитые блоки (виджеты) из подобных, но насколько я понял это не самостоятельное решение, и отличается по функционалу с пакетом, по-этому желающие (например я) не смогут использовать это как альтернативу.
ArticleC и HeaderC это че такое?)))
Это суффиксы, чтобы отметить Controller-ы для автозагрузки, модель Article, а контроллер ArticleC. Использовать 'Controller' целиком как суффикс было бы слишком многословно при большом количестве блоков.
Могли сократить сущности до модель — вьюха, а сам рендеринг скинуть на какую-то отдельную сущность например Renderer, т.к. для каждой модели не нужен отдельный контроллер.
Интересная мысль, изначально разделил чтобы не смешивать данные и зависимости, но если рассматривать в контексте блока (виджета) как целую сущность то это имеет смысл. Подумаю над этим.
Спасибо за уточнение, не сталкивался с Yii, посмотрел, у них пожалуй самые развитые блоки (виджеты) из подобных, но насколько я понял это не самостоятельное решение, и отличается по функционалу с пакетом, по-этому желающие (например я) не смогут использовать это как альтернативу.
Yii3 будет модульный, посмотрите возможно уже данный блок есть отдельно.
Это суффиксы, чтобы отметить Controller-ы для автозагрузки, модель Article, а контроллер ArticleC. Использовать 'Controller' целиком как суффикс было бы слишком многословно при большом количестве блоков.
У вас есть пространство имен, и данные суффиксы не имеют смысла. А если уж и делать суффиксы, то полностью т.к. «C» — это очень неоднозначно (может это Controller, а можно это просто Class (по аналогии с I и T), или Classificier и т.д.
Модульные front-end блоки – пишем свой мини фреймворк