Pull to refresh

Comments 20

Интересный велосипед, жду новую статью "Как я изобрел mvc", после нее "Как я изобрел компонент" и так далее.

Не, ну автор молодец.

Потрудился чтобы структурировать информацию, оформил всё в репозиторий, написал статью

Думаю что благодаря этому автор подрос как разработчик.

Теперь нужно рефакторить код. Можно начать с именования. Например:

BlockA
        block-a.twig
        block-a.css
        BlockA.php
        BlockA_C.php
Согласен что имена блоков в примере не самые user friendly, использовал их для наглядности, не уверен что условные header/form оторванные от контекста будут более понятны. Поделитесь вашей идеей как назвать, если есть

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

assets
    css
    js
    images
templates

Но именование BlockA_C.php кажется не очень правильным, потому что у вас неймспейс уже дает уникальность имени. А если вы захотите переименовать BlockA -> ModalBlock или как еще, то вам придется переименовывать все файлы. Или захотите скопировать блок.....

Поэтому внутри блока можно было бы файлы называть одинаково, например Controller.php(ну или что то типа того) и т.д.

На данный момент в своих проектах я группирую по темам, как

Block
  block.scss
  Theme
    First
      block--theme--first.scss

Это совпадает с BEM и мне кажется более удобным, чем разделение по типам файлов. Касательно одинаковых имен, да, технически это возможно, но я исходил из удобства редактирования (имхо), в случае одинаковых имен когда в IDE будут открыты одновременно несколько блоков различать их будет менее удобно, и опять же текущий способ более похож на BEM и будет более привычен для тех кто знаком с ним. Копирование блоков я использую довольно часто, в каждом проекте есть дефолтный блок и я создаю блоки с него, чтобы избежать ненужной рутины. По-этому в пакете также есть команда для копирования блоков с заменой имен
Изменил имена на условные Header, Article и Button в статье, в любом случае лучше воспринимается чем BlockA/B, спасибо за совет

Потрудился != молодец.

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

Та же MVC + компоненты в блейде, или даже шаблоны в twig дают куда большую гибкость.

думаю что все таки Потрудился == молодец.
Главное не останавливаться
Нужно запастись смирением, прислушаться к конструктивной критике и работать над ошибками
Знаком с MVC и изобретать его еще раз не планирую. Если присмотреться то можно увидеть что именно на MVC идеи структура данного пакета и опирается. Целью было получить небольшой пакет который решал бы задачу переиспользуемых блоков без подключения больших фреймворков, в которых кучу всяких дополнительных, в данном случае ненужных, вещей, как маршрутизация и тому подобное. Причем который подходил бы для классического разделения, без jsx. Если знакомы с альтернативами, поделитесь именами, буду признателен

Посоветую посмотреть на https://github.com/symfony/templating и так же прогнать проект с помощью https://github.com/squizlabs/PHP_CodeSniffer (Вы уж извините, но нейминг и форматирование ужасны и сложно читаемы). Так же почитайте PSR-12, BlockA_C - не очень валидное название класса. Ну и MVC - это не про наследование модели и контроллера от одного класса. Так же попробуйте учесть варианты, что блоки не обязательно должны быть в одном каталоге (их теоретически может быть много и они могут быть связаны). В целом - идея может и взлетит, но сейчас это не похоже на пакет, которым можно пользоваться.

Спасибо за ссылки и конструктивный комментарий, по привычке использовал WordPress code style, PSR-12 гораздо уместнее, обновил. Касательно того что

MVC — это не про наследование модели и контроллера от одного класса

абсолютно согласен, однако в данном случае наследование необходимо для чисто технического момента, как чтение полей, и ничего более. И разделение: модель — отображение — контроллер для распределения ответственности по-моему в данном пакете реализовано довольно прозрачно.

Так же попробуйте учесть варианты, что блоки не обязательно должны быть в одном каталоге

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

В целом — идея может и взлетит, но сейчас это не похоже на пакет, которым можно пользоваться.

У вас есть конкретные предложения по этому поводу?

наследование необходимо для чисто технического момента, как чтение полей, и ничего более.

если надо чтение полей - сделайте, например, класс со статической функцией, которая будет читать поля объекта и не зависеть ни от чего. Не нужно наследовать "контроллер" и "модель" ради реализации пары функций да еще и с надежой на протектед поля. Создайте интерфейс контроллера и модели что бы быть уверенным, что это тот объект, что ожидается, а не надежда на путь к папке и строгое имя для "моделей" и "контроллеров". Почему в кавычках? - Да потому что в Вашем случае это не модели и не контроллеры.

А зачем?

А затем, что я, например, сам предпочитаю выбирать, где и как размещать классы (я буду следовать PSR-4, этого должно быть достаточно). Вы же диктуете правила, которые можно обойти интерфейсами. А зачем мне тогда такой пакет, а не симфони темплейтинг например? (который уже deprecated, кстати) Хотя это риторический вопрос, мне не нужно шаблонизировать темы под вп =)

У вас есть конкретные предложения по этому поводу?

нет.

Создайте интерфейс контроллера и модели

Вы же диктуете правила, которые можно обойти интерфейсами

Тогда сама идея изменится. Благодаря ограничениям нет необходимости указывать каждый раз путь к шаблону, нет необходимости указывать класс модели для контроллера. Не вижу ничего плохого в наследовании, тем более что наследники будут решать четко установленные задачи. И использование protected полей класса вместо прямого массива (как например в в symfony) дает ряд преимуществ

Почему в кавычках? — Да потому что в Вашем случае это не модели и не контроллеры.


В привычном прямом понимании да. Данные имена были выбраны чтобы люди знакомые с MVC могли провести аналогии. Если рассматривать каждый блок в отдельности, то Model ожидаемо предоставляет данные, View (twig) их отображает, а Controller управляет зависимостями

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

Если бы блоки создавались автоматом - этого как раз можно было бы добиться.

Посмотрите на компоненты в angular.

Если бы блоки создавались автоматом

Можете пояснить, что именно могло бы создаваться автоматически?
Прежде чем что-то изобретать, неплохо бы ознакомиться с «конкурентами». Как организована работа с шаблонами и виджетами в фрейморках и других CMS. Ну и уже по традиции комментариев данного топика: нейминг конечно ужасный :)
С некоторыми шаблонами «конкурентов» знаком, как WordPress, Symfony, Codeigniter. Также альтернатив, подобных уже существующих пакетов, которые делают то же самое при поиске не нашел.

нейминг конечно ужасный :)

Если не трудно, хотелось бы пару примеров из кода с альтернативной версией (правильной по вашему)
С некоторыми шаблонами «конкурентов» знаком, как 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 и т.д.
Sign up to leave a comment.

Articles