RayMefise
@RayMefise
Java, PHP, C, C++, C#, .NET, QT

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

СУТЬ ВОПРОСА ПОД СПОЛЕРОМ
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 скачать свой модуль а затем через другой интерфейс попробовать его определить как модуль, если он соответствует всем требованиям, то пакет проинициализируется как модуль и добавится в систему.

Что скажете про такой подход?
  • Вопрос задан
  • 666 просмотров
Пригласить эксперта
Ответы на вопрос 3
@karminski
Разработчик CRM/ERP систем
Следовать PSR - не догма, если вам безразлично будущее вашего проекта. Однако, если вы не хотите через годик сами запутаться где и что у вас лежит, если не хотите создать головную боль другим разработчикам (которые подхватят проект после вас) - PSR MUST HAVE.

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

Посмотрите как там всё устроено.
Ответ написан
index0h
@index0h
PHP, Golang. https://github.com/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. Если так - вам придется вывернуться на изнанку, что бы получилось И гибко И производительно И саппортабельно.
Ответ написан
@oxidmod
мне кажется человек просто не понимае что такое зависимости и что такое внедрение зависмостей. зачем это нужно и какие проблемы решает.
да, без понимания этих вещей можно сделать цмс.
сделать гибкую и удобную для расширения цмс - не выйдет.
на этом все. автор может забить на пср-ы, композер и пилить код как ему удобно.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
XIAG AG Новосибирск
от 130 000 до 200 000 ₽
от 100 000 до 180 000 ₽
Getman & Co Санкт-Петербург
от 80 000 до 150 000 ₽