Нужно ли строго следовать стандартам PHP при разработки CMS?

Question

[Максим Зайцев]

СУТЬ ВОПРОСА ПОД СПОЛЕРОМ

spoiler

Добрый день. Разрабатываю для себя собственную CMS систему и решил сделать все по человечески с использованием стандартов PHP. Изучая стандарты наткнулся на такую вещь как размещение файлов с привязкой к namespace по стандарту PSR-0 и столкнулся со следующей проблемой.
Согласно стандарту мои классы должны лежать по следующему адресу:
<путь к папке с библиотеками>/<имя поставщика>//<имя класса>.php
что соответствует классу <имя поставщика>\\<имя класса>

<имя поставщика> как я понимаю это компания которая поставляет библиотеку. Если компания моя, то там должно быть название моей компании, если это сторонний разработчик, то его. И тут меня все устраивает за исключением одного момента.

у меня ядро проекта структурно разбито на папки:

<путь к ядру>/lib/<имя поставщика>/ - тут лежат вспомогательные библиотеки от данного поставщика
<путь к ядру>/components/<имя поставщика>/<имя компоненты>/ - тут лежат классы для работы компоненты от данного поставщика
<путь к ядру>/modules/<имя поставщика>/<имя модуля>/ - тут лежат классы для работы модуля от данного поставщика
<путь к ядру>/plugins/<имя поставщика>/<имя плагина>/ - тут лежат классы для работы плагина от данного поставщика

и в идеале мой namespace должен строится как:

lib\<имя поставщика>\<namespace>\<имя класса>
modules\<имя поставщика>\<namespace>\<имя класса>
components\<имя поставщика>\<namespace>\<имя класса>
plugins\<имя поставщика>\<namespace>\<имя класса>

с точки зрения проекта это было бы лаконично, понятно и удобно в функциональном плане, но как я понимаю PSR-0 предписывает мне создавать другую структуру, следующего вида:

<путь к ядру>/<имя поставщика>/lib/ - тут лежат вспомогательные библиотеки от данного поставщика
<путь к ядру>/<имя поставщика>/components/<имя компоненты>/ - тут лежат классы для работы компоненты от данного поставщика
<путь к ядру>/<имя поставщика>/modules/<имя модуля>/ - тут лежат классы для работы модуля от данного поставщика
<путь к ядру>/<имя поставщика>/plugins/<имя плагина>/ - тут лежат классы для работы плагина от данного поставщика

что соответствует следующим namespace

<имя поставщика>\lib\<namespace>\<имя класса>
<имя поставщика>\modules\<namespace>\<имя класса>
<имя поставщика>\components\<namespace>\<имя класса>
<имя поставщика>\plugins\<namespace>\<имя класса>

все ли я верно понял?
имеет ли смысл в моем случае использовать стандарты PSR-0 или нужно забить на него и просто описать свой стандарт наименования namespace и их размещение в каталогах для разработчиков, ведь по сути файлы в проект будут попадать через инстолятор в админке который будет из архива извлекать файлы согласно XML инструкции и размещать файлы согласно внутреннему алгоритму.

Еще я поглядел в сторону PSR-4 и вроде как там такой проблемы нет, она позволяет реализовать то что я описал выше, но я могу ошибаться, так что про это тоже поясните пожалуйста.

PS: использовать composer не планирую, все библиотеки будут писаться мной, но планируется что для данной CMS системы могут разрабатываться сторонние модули и плагины.
В проекте есть строгая классификация папок, грубо говоря классы модуля должны быть в папке с названием модуля внутри папки modules, но как я понимаю придется мне пересматривать структур своего проекта и эту привязку к папкам или отказываться от PSR-0 стандарта и вводить свой стандарт для разработчиков, в общем жду ваших идей.

PSPS: небольшие пояснения о том что подразмевается под modules | components | plugins

components - генерируют по факту основной контент страницы. На странице обязательно есть один и только один компонент. Подставляется в контентБлок шаблона

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

plugins- не участвуют в генерации контента а выполняют функцию расширения функционала. Например подключение по необходимости JSбиблиотеки или реализация всплывающих окон и т.д. Чаще всего их функционал работает независимо от страницы или используется как зависимость для модуля или компоненты. Например без включенного плагина JQweryLoad не будут работать всплывающие окна написанные на jqwery если они используются в шаблоне модуля.

каждый элемент системы как и сама система будут реализованы на основе MVC

Вроде как придумал следующее решение.

Сама CMS система вместе с зарезервированными в ней модулями и компонентами находится в корне проекта, а в папке vendor лежат скаченные через composer библиотеки вспомогательные.

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

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

Если Петя по какой-то причине не хочет регать свой модуль у нас, то он может через другой интерфейс который просто ставит пакеты через composer скачать свой модуль а затем через другой интерфейс попробовать его определить как модуль, если он соответствует всем требованиям, то пакет проинициализируется как модуль и добавится в систему.

Что скажете про такой подход?

Comments

[Алексей Скобкин]

Изучая стандарты наткнулся на такую вещь как размещение файлов с привязкой к namespace по стандарту PSR-0

В развитом мире уже используют PSR-4.

и в идеале мой namespace должен строится как

И что же случится, если основной код вашей CMS будет лежать в vendor/your_vendor_name/your_library/...?

PSR-0 предписывает мне создавать другую структуру, следующего вида

Нет.

что соответствует следующим namespace

Нет.

имеет ли смысл в моем случае использовать стандарты PSR-0

Имеет смысл использовать PSR-4.

просто описать свой стандарт наименования namespace и их размещение в каталогах для разработчиков

Ещё один велосипед.

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

Как одно связано с другим вообще?
Не использовать Composer в наше время - это очень странно. Уже отталкивает от пользования вашей CMS.

[trevoga_su]

Алексей Скобкин: > Не использовать Composer в наше время - это очень странно. Уже отталкивает от пользования вашей CMS.

Странно - это как макака следовать всем догмам.

[Максим Зайцев]

Алексей Скобкин: я по моему ясно дал понять что Composer не будет использоваться. Вас это отталкивает как программиста который привык юзать чужой код библиотек, а вот дядюшка который хочет скинуть исходники, пройти быструю настройку, а потом просто закинуть через админку архив с модулем и поулчить новый функционал на сайте вам за Composer спасибо ен скажет. Composer хорош при разработке но при работе с проектом который на разных конфигурациях постоянно меняется уже теряет свой запал. Что касается велосипеда, то с таким же успехом можно сказать что ну есть же джумла или высер в виде битрикса, чего велосипед изобретать, давайте просто их использовать, но нет, люди пишут свой код потому что порой нужно просто создать нечто свое которое будет работать для заданных целей так как вам будет нужно. К тому же не знаю (могу заблуждаться) ни одной крупной CMS системы которая бы работала через Composer для конечного пользователя.

[Алексей Скобкин]

Максим Зайцев:

а вот дядюшка который хочет скинуть исходники, пройти быструю настройку

Это, кстати, замечательно делается через Composer. Что ещё и увеличивает возможности автоматизации. Посмотрите на установщик Symfony (тот, который работает через Composer).

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

Потому, что если под крупными подразумевать популярые CMS, то окажется, что всё они стары как мир и Composer ещё не было во время их создания. Будь он тогда - вряд ли бы они таскали с собой тонны статики или сабмодули в репозитории. А если посмотрите на современные CMS - практичеки все при сборке используют Composer. А установку через Composer поддерживают вообще очень многие, хоть и не пользуются всеми его фичами.
В общем, я вам ничего не навязываю. Просто ваш вопрос напоминает мне здешние вопросы в стиле "Зачем мне Git?".

[Максим Зайцев]

Алексей Скобкин: ну гит зачем я понимаю, им активно пользуюсь, но вот про Composer если честно пока как-то не вижу его необходимости, вернее как сказать, я понимаю его плюсы но в рамках CMS системы с модульной сложной структурой не пойму как он поможет. Ну добавится мне библиотека которая может парсить XML например, но где в Composer я возьму модуль который будет из себя представлять магазин с товарами?

[Алексей Скобкин]

Максим Зайцев:

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

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

[Максим Зайцев]

oxidmod: Понимаете, просто мне надо чтобы файлы лежали по определенной иерархии и чтобы были соответствующие инструкции к ним. Например что файл такой сто с классом таким то является контроллером для модуля а класс такой-то его моделью, а шаблон лежит в папке такой-то и все основные классы обязательно унаследованы от моего системного абстрактного класса который реализует ряда операций таких как например подключение нужного представление для модуля исходя из настроек в админке а как это реализовать в рамках Composer я не представляю. я вижу его как система докачки библиотек, но не полноценных решений для CMS. Повторюсь, в Composer я смогу скачать модуль магазин который будет работать из коробки как полноценное решение для CMS вместе с админкой и шаблоном?

[Максим Зайцев]

Алексей Скобкин: Учитывая ваши слова о том, что вы всё это сами пишете, полагаю, что этот модуль будет отдельным пакетом в вашем вендорном неймспейсе. - да в моем, но Петя решил взять мою CMS систему и запилить свой магазин, куда ему свои пакеты пихать? в мое пространство или заливать как-то в Composer?

[Максим Зайцев]

oxidmod: то есть насколько я понимаю я могу запилить свой код и залить его в репозиторий Composer чтобы другие чуваки его могли скачивать для себя, допустим, это конечно неплохо, но как заставить Composer чтобы он после скачиавания пакета как-то понял что это не просто библиотека а именно модуль, что для него надо создать определенный таблицы в базе и что надо внести в базу админки ряд изменений?

[Максим Зайцев]

oxidmod: могу и походим образом делаю, но чтобы вызвать метод мне сначало надока к сто CMS сообщить что это именно модуль а ен просто класс или он должен по всем файлам пробегать сканить их на наличие интерфейса и вносить их в список модулей? глупо. Опять же не вижу описания того как изменить данные в базе, СОЗДАТЬ НУЖЫНЕ ТАБЛИЦЫ и изменить уже записанные данные?

[Максим Зайцев]

oxidmod: так уже интереснее, это все понятно, если можно поподробнее про "в некий конфиг прописывается модуль" и "после того, как модуль добавлен в список он появляется в админке". Как это сделать ручками то я понимаю, в процессе разработки с этим нет проблем, в моем случае данным конфигом является таблица в базе данных в которой хранится информация о модулях, зависимостях и прочем необходимом для ядра. Но вот вопрос в чем. Чувак зашел в админку и захотел установить через какой-то интерфейс Composer новый модуль, как сделать так чтобы установщик Composer понял что это именно модуль а не просто библиотека и что надо внести какие-то правки в конфигурацию, например добавив в список модулей данные об новом установленном модуле.

[Максим Зайцев]

oxidmod: такой вариант я предполагал выше, но для его реализации надо каждый раз сканить папку vendors и все вложения на поиски файлов которые могут быть модулями. В общем мне кажется это не очень вариант. Есть идеи как еще это реализовать, так как пока это одна из главных причин не использовать Composer для реализация модулей

[Максим Зайцев]

oxidmod: то есть надо сканить только файлы с названием Module и еще при этом заставлять разработчиков внутри своего модуля правильно называть файлы?

[Максим Зайцев]

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

[Максим Зайцев]

oxidmod: блин, дело то не в этом, пусть кладет, я просто не понимаю как моя CMS система узнает что это модуль? То есть ей надо каждый раз сканить папку Vendors на наличие там папок с файлами конфигурацией. Просто как мне кажется это не очень практично или я не прав? Когда ты инсталлируешь пакет через свой инстоллятор в админке, тут все понятно. Разархивирвоал архив, считал оттуда файл конфигурации, сделал нужные записи в базу и файлы из архива положил в нужный каталог. На этом все. Но когда работает композер, то он просто скачивает запрошенный файл и тянет к нему описанные зависимости размещая все в папке вендор. А как сделать эту постнастройку. Композер вроде как умеет поддерживать скрипты какие-то которые стартуют перед и после установки, но не уверен что они тут приемлемы будут.

[Максим Зайцев]

ага, то есть как я понимаю в админке пишется интерфейс который при запросе пакета запускает сначала композер, устанавлвиает пакет, затем как-то из композера возвращает данные о том куда был установлен пакет и после передает эти данные в мой скрипт который уже лезет в папку и ищет в ней конфигурационные файлы, я вас верно понял?

Answer 1

[Антон Иванов]

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

Загляните, например, сюда.
https://github.com/yiisoft/yii2-app-advanced

Посмотрите как там всё устроено.

Comments

[Максим Зайцев]

а что на счет PSR-4? Она не позволяет разве решить мою проблему? там поидее можно задать префикс к namecpace и путь к каталогу по этому префиксу или я ошибаюсь?

[Антон Иванов]

Максим Зайцев Еще раз, посмотрите как устроен проект по ссылке. Используйте composer, думаю многие вопросы сразу отпадут.

[Максим Зайцев]

Антон: я посмотрел проект по ссылке, не нашел места хранения отдельных модулей и каталогов, может я не совсем понимаю то на что вы мне пытаетесь указать конечно, или вы не внимательно прочитали мой пост. Я понимаю как работает PSR, ноу меня стоит конкретная задача что каждый отдельный элемент системы должен лежать в папке с названеим элемента в подпапке с типом элемента. Папка vendor не нужна так как composer так же за ненадобностью ибо само ядро будет писаться только собственными силами без сторонних библиотек, но если я например отдам это ядро Дяде Ване и он решит что ему нужен свой компонент, например магазин, то он его может написать сам и подключить через админку, тогда сама система позволит его использовать. Для написания компоненты или модуля будут наложены определенные правила, например должен идти сопроводительный файл заданного стандарта который указывает назначение файлов и классов, а классы контроллеры должны быть отнаследованы обязательно от системного класса контролера соответствующего типа.

[evnuh]

Максим Зайцев: PSR-0 deprecated, используйте PSR-4

[Дмитрий]

Добрый день.
Нет места для хранения отдельных модулей потому, что их там изначально нет, но если решите их делать, то создаёте отдельную директорию modules и складываете туда все свои модули.
Вам дали ссылку для того, чтобы Вы посмотрели, где лежат классы для frontend и backend, где для консольных команд скрипты, где виды и так далее. Frontend для пользователей, backend для админа, всё разложено понятно и не запутано.
Если организуете так же, то есть, всё разложите по директориям, используя namespace, да ещё и задокументируете/прокомментируете код, то всё будет отлично, ни Вы, ни кто либо другой, не запутается в Вашем проекте.

[Максим Зайцев]

просто согласно PSR-4 как я понимаю если у меня путь <путь к ядру>/components/<имя поставщика>/<имя компоненты>/ то префикс у меня все равно должен начинаться с имени поставщика, а значит как я понимаю нужно задать следующее соответствие:
<путь к ядру>/components/<имя поставщика> это <имя поставщика>\components\
если я укажу следующий класс <имя поставщика>\components\Materials\Controller
то он подрубится из <путь к ядру>/components/<имя поставщика>/Materials/Controller.php
я все верно понимаю?
соответственно мне надо обязывать и доводить до сведения разработчиков, что для классов компоненты например им надо указывать namespace как <имя поставщика>\components\...
я все верно понимаю?

[Максим Зайцев]

slo_nik: как вы это все понятно, у меня проблема как раз именно с размещением модулей и их namecpace. Я просто говорю что модули могут быть использованы от разных разработав и чтобы namcpace между собой не подрались я не вижу смысла делать структуру папки с модулями так:
<путь к каталогу>/modules/<имя модуля>
а хотелось бы сделать ее так:
<путь к каталогу>/modules/<имя разработчика>/<имя модуля>
но так сзелать я не могу так как PSR мне преписывает что имя namecpace должно начинаться с поставщика, а у меня уже перед поставщиком идет папка modules

[Дмитрий]

Максим Зайцев: Почему Вы решили, что модули от разных разработчиком подерутся?
Например:
modules\user
modules\yii2_user
Как они подерутся?
Или контроллеры, как?
В папке controllers можно все котроллеры разложить по отдельным вложенным папкам, разложить по выполняемым задачам.
Вы, это моё мнение, заморачиваетсь лишним. Если Вы хорошенько продумаете, как организовать свою CMS, то это вопрос у Вас отпадёт.
Тем более, что Вы собираетесь использовать namespace.
Если взять всё тот же YII2.
namespace frontend\models\User;
namespace backend\models\User;
namespace frontend\models\signup\User;
namespacefrontend\models\query\User;
Название модели одно и тоже, но всё остальное разное...

[Максим Зайцев]

slo_nik: все верно говорите, это все понятно как божий день, но смотрите тогда такая ситуация:
Некий Петров создал модуль Contacts и задал ему namespace frontend\models\Contacts;
затем Иванов создал независимо от Петрова модуль Contacts и задал ему namespace frontend\models\Contacts;
А теперь Васильев которому нужны оба эта модуля испытывает проблему так как оба они названы одинаково так как разрабатывались независимо разными людьми и имеют общие пути и namecpace
а вот если бы было так:
frontend\models\petrov\Contacts;
frontend\models\ivanov\Contacts;
то проблемы бы ни было никакой, но так сделать я не могу из-за PSR которая предписывает мне следующее:
petrov\frontend\models\Contacts;
ivanov\frontend\models\Contacts;
теперь надеюсь понятно в чем у меня проблема и чего я пытаюсь добиться. Вариант называть модули по разному не катит так как иванов и петров не знакомы и договориться между собой не могут.

[shagguboy]

Максим Зайцев: PSR прав. разработчики Иванов и Петров должны выдавать самодостаточные модули, которые ничего не знают о своём окружении.

[shagguboy]

>и имеют общие пути и namecpace
это не так. и пути и неймспейсы у них разные.
vendor\petrov\frontend\models\Contacts;
vendor\ivanov\frontend\models\Contacts;

[Дмитрий]

Максим Зайцев: shagguboy дополнил мой ответ Вам. Вот для чего нужен composer. А я Вам описывал действия для Вас, как разработчика своей CMS.
Если же Вы захотите использовать модули разработанные Петровым, Ивановым, Сидоровым, то используйте composer и будет Вам счастье и не будет накладок.

Допустим, я буду использовать Вашу CMS, то зачем мне в названиях директорий frontend или backend название(имя поставщика) Вашей компании?

Обратите внимание, как именуются пакеты в composer. В основном начинаются с имени пользователя.

p.s. немного сумбурно написал, но надеюсь Вы поймёте мою мысль.

[Максим Зайцев]

shagguboy: это действительно если речь идет об использовании Composer, а я выше писал что не планирую его использование. Composer хорош когда нужно подключить чью-то библиотеку и использовать в своем коде, но когда речь идет об "модуле CMS системы" который разрабатывается конкретно под CMS систему и представляет из себя готовый продукт, например генератор меню на основе каталога магазина, то тут Composer уже не катит (как мне кажется) и я попробую объяснить почему. Вот я разработал базовую CMS систему и затем мой знакомый решил на ней написать свой сайт. Но например у меня не было реализовано модуля "топ статей" который потребовался моему знакомому и он приступил к разработке. Зачем ему для этого Composer если он будет писать этот модуль сам да еще и по строгому соответствию, так как ключевые классы обязательно должны наследоватсья от моих классов, так как мой обработчик при подключении данного модуля в шаблоне вызовет его ключевой класс и будет использовать внутри своего ядра. Так вот как тут мне поможет Composer если это просто подгрузчик библиотек и зависимостей, а мне нужны элементы CMS системы?

[Максим Зайцев]

slo_nik: не совсем если честно понял, я выше написал про то почему я не хочу использовать Composer но похоже я в чем-то заблуждаюсь на счет него и опять же возвращась к Composer почему его тогда ен используют в крупных CMS системах которые используют конечные пользователи?

[Алексей Скобкин]

Максим Зайцев: Вы говорите, что понимаете PSR-0 и PSR-4, но при этом описываете нам проблему, которую именно эти два стандарта (рекомендации, на самом деле) и решают.

[Максим Зайцев]

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

[Алексей Скобкин]

Максим Зайцев: Я пока не понял, в чём проблема с расположением файлов.
Возможно, вам будет интересно посмотреть как реализованы те же бандлы Symfony (2 или 3) - как они регистрируются сами, как регистрируют свои сервисы в системе, как добавляют свою маршрутизацию.

[Максим Зайцев]

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

[Максим Зайцев]

oxidmod: ага это вы объясните например директору компании который говорит что я хочу вот это но чтобы работало вот так вот и программисту приходится писать свой модуль. Вопрос нахрена ему его заливать в Composer? Еще раз, Composer хорош для подгрузи вспомогательных библиотек, но юзать его чтобы хранить там файлы проекта это тупо как по мне, а если файлы проекта там не хранить, то тогда как другие люди которые будут дорабатывать проект независимо друг от друга будут использовать пространство имен? Крмое того Composer это контролер зависимостей библиотек, он не умеет изгаляться и при скачивании библиотеки выполнять еще код изменяющий данные в базе данных, кроме того как я писал неоднократно что те же файлы шаблонов смысла хранить в неймспейсе нет, их вообще по хорошему надо выносить в отдельный файл, но и тут свои траблы возникают, когда часть у нас в Composer а часть в своих папках, плюс еще даныне котоыре надо внести в базу...

[Максим Зайцев]

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

[Антон Иванов]

Максим Зайцев Ну как вы разобрались? Давайте проще поговорим. Если вы хотите "чтобы файлы лежали по определенной иерархии" (ваша фраза) - забудьте про composer и PSR. Придумайте свой стандарт, которому будете жёстко следовать. Только не забудьте его описать для будущих поколений. Если же вы хотите следовать стандарту PSR ("делать правильно") - прислушайтесь к тем 30 комментариям что вам выше выложили. Измените свою структуру: ваше ядро должно лежать в vendor, также как и любой другой независимый компонент вашей системы. Все классы должны иметь уникальные имена и неймспейсы. Не может быть чтобы Иванов, Петров и Сидоров создали одинаковые классы \my\namespace\ClassName. Это не правильно с точки зрения построения архитектуры.

[Максим Зайцев]

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

Answer 2

[index0h]

TL;DR
Вы хотите потратить кучу времени просто так, увы. Если так хочется сделать cms - делайте, но возьмите за основу фреймворк, Silex например (лучше конечно Symfony, но там порог вхождения довольно высокий).

-----------------------------------------------------------

Use PSR-4 Luke!

и в идеале мой namespace должен строится как:
lib\<имя поставщика>\< namespace>\< имя класса>.... >

Плохая идея, очень. Namespace стоит делать: < vendor >\< project >\<...>\ClassName
Подключив зависимости через composer вы столкнетесь с тем, что путь к конечному файлу будет:
vendor/< vendor >/< project >/.../ClassName.php
И это вне зависимости от того, используется ли ваша cms, или нет. Путь всюду будет идентичным.

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

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

PS: использовать composer не планирую, все библиотеки будут писаться мной, но планируется что для данной CMS системы могут разрабатываться сторонние модули и плагины.

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

В проекте есть строгая классификация папок, грубо говоря классы модуля должны быть в папке с названием модуля внутри папки modules.....

Что мешает сделать систему конфигурации у каждого модуля? Жесткое позиционирование файлов/каталогов - это как выровнять людей по высоте с помощью циркулярки))

небольшие пояснения о том что подразмевается под modules | components | plugins

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

А вот разделение по MVC было бы вполне не плохо. Не забудьте про консольное выполнение.

каждый элемент системы как и сама система будут реализованы на основе MVC

Если я правильно понимаю это получиться что-то типа HMVC. Если так - вам придется вывернуться на изнанку, что бы получилось И гибко И производительно И саппортабельно.

Comments

[Максим Зайцев]

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

автоподключение классов будет, тут речь идет не о том что я не хочу юзать composer я имею в виду что не вижу его применения в рамках реализации элементов CMS системы.

попытаюсь прояснить ситуацию так как складывается впечатление что я что-то не то пытаюсь объяснить.
Ну вот к примеру с помощью composer я подрубил к проекту все нужные мне библиотеки. Супер. На основе их я реализовал модуль для сайта "Shop" и положил его в .\frontend\modules\Shop\<файлы модуля> но потом мой код взял мой знакомый и решил что захотел реализовать свой магазин и вот куда он должен класть свои файлы если он тоже хочет чтобы его модуль назывался Shop?

как я понял мне предлагают все файлы класть в папку vendor\zaitsev\modules\Shop\<файлы модуля> но блин тогда все мои файлы будут лежать в папке vendor, а что будет лежать в других файла? а шаблоны которые с мобулем идут их тоже туда пихать? что-то я не сосем этого понимаю зачем это делать. Ок, я согласен что composer хорош при подключении вспомогательных библиотек при разработке, но если я хочу разрабатывать крупные модули то накой мне все элементы валить в composer если например шаблоны я бы хранил вообще отдельно что вполне логично, да и шаблоын могут для одного и тогоже модуля быть от разных поставщиков. В общем меян именно этот момент интересует. А если это делать в рамках проекта, то есть не размещать файлы проекта в том чесле модулей в папке vendor, то тогда встает вопрос а как решить ту самую проблему с наименованием папок если два разных чувака работая над проектом независимо решили запилить одноименный модуль?

[index0h]

Максим Зайцев
> не вижу его применения в рамках реализации элементов CMS системы.
В том то и дело, cms - это зависимость проекта на базе этой cms. Да, вы можете отойти от этого принципа, но в этом случае проблем "не работает после обновления" будет на порядки больше.
Вот вам пример: пацанчеки из opencart в свое время не позаботились надлежащим образом об зависимостях (возможно на данный момент эта проблема и решена, не в курсе), результат: да, есть куча дополнений, которые прямо поверх кода устанавливаются, а дальше начинается капец так как затрагиваются системные части, результатом подобного подхода являются конфликты между разными дополнениями.

> На основе их я реализовал модуль для сайта "Shop" и положил его в .\frontend\modules\Shop\<файлы модуля>
В том то и дело, что вы привязываетесь к корневому каталогу, что неверно.
vendor/< vendor >/< projectName-ExtensionName >/< файлы зависимости >

За счет этого вы получите такое: бизнес логика зависимости существует в едином экземпляре, но в случае чего ее можно уже в приложении подстроить под себя.

> а шаблоны которые с мобулем идут их тоже туда пихать?
Путь к шаблонам по умолчанию vendor/< vendor >/< projectName-ExtensionName >/... Однако это настройка зависимости, которую можно переопределить.
При этом в проекте сайта непосредственно можно спокойно указать свой и юзать кастомную тему.
Статические файлы можно либо скопировать, либо слинковать. Это дело можно реализовать с помощью: https://getcomposer.org/doc/articles/scripts.md
Хотя... Лучше конечно не выдумывать костылей и заюзать twig, или smarty, которые и так это сделают, только лучше и быстрее))

> как я понял мне предлагают все файлы класть в папку vendor\zaitsev\modules\Shop\<файлы модуля> но блин тогда все мои файлы будут лежать в папке vendor, а что будет лежать в других файла?
Э-не. Еще раз, вы путаете понятия "зависимость" и "файлы проекта". Файлы проекта лежат не в vendor, их задача - реализовать конечную БЛ проекта. Задача зависимостей - максимально упростить этот процесс.

> накой мне все элементы валить в composer если например шаблоны я бы хранил вообще отдельно что вполне логично
Шаблоны конечного проекта - в каталогах конечного проекта. Шаблоны зависимостей - в каталоге vendor/...
Пример: у вас есть форма авторизации. В вендоре вы прописываете БЛ, там же делаете базовый шаблон. Если при подключении зависимости вас уже устраивает эта форма - зашибись. Если не устраивает оформление - ок, переопределите тему в своем проекте, но не в зависимости.

> да и шаблоын могут для одного и тогоже модуля быть от разных поставщиков.
Дык это замечательно! У вас есть базовая зависимость, возьмем туже форму авторизации. Есть 10 поставщиков оформления. В вашем проекте вы указываете в настройках подключаемой зависимости, где брать шаблон, в этом случае он будет из каталога vendor/< поставщик >/...

> А если это делать в рамках проекта, то есть не размещать файлы проекта в том чесле модулей в папке vendor, то тогда встает вопрос а как решить ту самую проблему с наименованием папок если два разных чувака работая над проектом независимо решили запилить одноименный модуль?
Чувак 1 создаст проект < Чувак1 >/< Проект >
Чувак 2 создаст проект < Чувак2 >/< Проект >

В каталоге vendor у вас будет И Чувак1 И Чувак2

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

[Алексей Скобкин]

Максим Зайцев:

как я понял мне предлагают все файлы класть в папку vendor\zaitsev\modules\Shop\<файлы модуля>

Вы так хотите иметь директорию modules, что с вами даже как-то спорить не хочется.

но блин тогда все мои файлы будут лежать в папке vendor, а что будет лежать в других файла?

А в чём проблема-то? Вы не хотите обделить другие директории наличием файлов или что? В чём ПРОБЛЕМА, которую вы решаете?

а шаблоны которые с мобулем идут их тоже туда пихать?

но если я хочу разрабатывать крупные модули то накой мне все элементы валить в composer если например шаблоны я бы хранил вообще отдельно что вполне логично

Вы так говорите, как будто вас убеждают хранить шаблоны вместе с контроллерами. Посмотрите, например, сюда: https://github.com/sonata-project/SonataAdminBundle
Здесь у вас в Controller лежат контроллеры (при необходимости также с иерархией), а в Resources/views - шаблоны. И когда вы подключаете такой вот готовый бандл-компонент - к вам приезжает сразу всё: и роутинг нужных адресов сайта и контроллеры, которые его обслуживают, и шаблоны, которые рендерятся пользователю, и сервисы, и всё остальное.

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

Да вам десять раз про неймспейсы сказали и о том, что они решают эту проблему. Что не так-то?