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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;
теперь надеюсь понятно в чем у меня проблема и чего я пытаюсь добиться. Вариант называть модули по разному не катит так как иванов и петров не знакомы и договориться между собой не могут.

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

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

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

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

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

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

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

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

PSR-0 или PSR-4, и как правильно построить структуру проекта?

diamond: не совсем, если среди версий есть поддержка, то будет использоваться поздняя версия (по принципу пакетного менеджера в linux) если таковой нет, то в системе администрирвоания будет выведено сообщение о возникшей проблеме и предложены варианты его исправления, аналогично rpm пакетам в linux дистрибутивах.

PSR-0 или PSR-4, и как правильно построить структуру проекта?

Сергей: я с вами согласен, просто я неплохо ориентируюсь именно в php и программной логике, грубо говоря могу найти решение на php или другом языке практически любой задачи, но вот по части "корректности" процесса разработки у меня пока проблемы. Обучался я сам и многое в те времена в книгах не писалось, многое вообще приходилось выискивать в англоязычной литературе и только после того как я поработал в крупной конторе программистом java я понял все прелести git, jira, разного рода id систем и т.д. но к сожалению именно с разработкой на php у меня как-то все слишком по "деревенски" получалось - Linux с поднятым LAMP (или виртуалка на маке), git, jira (для работы с командой), confluence (для документирования), netbeans и все. Иерархию проектов мы сами разрабатывали, в свое время изучали разные cms системы но многое в них не понравилось (у нас немного другая идея была в плане самой работы cms и разработки под нее, на тот момент она казалась нам очень крутой и простой, но щас я хочу написать новую систему так как понимаю все недочеты и проблемы старой), стилизацию кода тоже свою брали, на основе стилей java (проект начинался просто лет 8-9 тому назад и потом много раз дописывался и переделывался но основная логика была прежней) ну и многого попросту не знали и не задумывались, например про то как корректно структурировать файлы и что есть специальные утилиты для проверки кода на разные версии php...

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

PSR-0 или PSR-4, и как правильно построить структуру проекта?

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

PSR-0 или PSR-4, и как правильно построить структуру проекта?

что касается сторонних библиотек, то хотел бы пояснить, что они могут быть использованы в том случае если оператор cms ставит сторонний компонент разработанный сторонним программистом и этот компонент несет в себе набор вспомогательных библиотек.

PSR-0 или PSR-4, и как правильно построить структуру проекта?

И почему же, если проект на PHP? Что же вы тогда используете для управления зависимостями? Если сторонними библиотеками вообще не планируете пользоваться, то не нужен ни composer, ни папка vendor.

сторонними библиотеками не пользуемся, используем только то, что предоставляет сам PHP, все остальное мы разрабатываем сами. Контроль зависимостей у нас организован на уровни системы администрирования cms. Грубо говоря если оператор подключает компонент или устанавливает новый а у него в параметрах прописана зависимость от какой либо библиотеки или другого модуля, то этот модуль автоматичекси скачивается с нашего сайта в его систему по средством нашей утелиты.

В public только index.php и статика: css, js, js шаблоны, картинки, шрифты и т. п. Шаблоны php модулей в папках view модулей.

я имею в виду не представления для элементов системы, а именно шаблон страницы, структур страницы, она ведь как раз и содержит помимо php файла (tpl или любого другого типа шаблонов) еще и css файлы и возможно даже js файлы, насколько я помню работу сервера, то если мы их перенесем из папки public то доступа к ним браузеру не будет (при условии что остальные папки закрыты), а значит речь идет о том, что часть шаблонов надо хранить в одном месте а статику от них в папке public, я все верно понял?

Нет, что должно быть в public перечислил выше. Остальные PHP файлы только в /module/<Имя модуля>/src или где угодно, но только не в public. Всё запросы, за исключением запросов статических файлов, идут в index.php, в конечном итоге роутер направляет их в нужный контроллер, который лежит всё там же где-то в недрах /src.

не совсем понял тогда про php код который вызывается с помощью ajax. Ведь если к нему закрыт доступ на прямой вызов, то вызвать его на выполнение через ajax так же не будет возможно. Я предполагаю что наверное для ajax вызовов стоит так же создать управляемый файлы в папке public или возможно добавить этот функционал в index.php

PSR-0 или PSR-4, и как правильно построить структуру проекта?

Это папка для сторонних библиотек, используемых в вашем проекте. Используется composer'ом. Внутрь лезть особо причин нет, composer сам решит как ему там всё разложить. Свои классы вы туда тоже не должны писать.

а что если мы не используем в проекте composer. Я работал с подобными вещами при разработке на Java но с PHP сталкиваться не приходилось. Насколько я понял это своего рода надстройки над ide или отдельной программы которая внедряется в проект и контролирует включение тех или иных файлов в проект согласно зависимостям которые где-то прописаны. Зависимости эти скачиваются из стороннего хранилища и помещаются в указанную папку с библиотеками. Верно ил мое предположение что данная утилита хороша при разработки множества разных проектов и бессмысленна если речь идет о разработке одного проекта (CMS) который в свою логику включает систему зависимостей компонент от библиотек с возможностью получить их с нашего сервера. Грубо говоря если оператор подключает компоненту к сайту а она требует библиотеку которой у него сейчас нет, то она автоматически скачается ему с нашего сервера (напоминаю что речь идет щас о нашей разработке написанной на hp а не о composer).

я просмотрел вашу структуру и обратил внимание на то, что в папке public у вас лежит сразу и основной исполняемый файл и шаблон, причем насколько я понял шаблон у вас один для всех страниц, в своем же проекте я использую механизм при котором разрешается использовать для разных страниц разные шаблоны, как вам удается реализовать подобное, поделитесь опытом. Кроме этого как я понимаю так как мы закрываем доступ для всех папок кроме public это значит, что все js, php файлы используемые в ajax, css и файлы шаблонов должна располагаться также в папке public

src и lib - скажем так, синонимы. Кому как больше нравится. Главное, что внутри лежат сами PHP файлы проекта, следующие стандарту PSR-4. Лежат там только файлы, написанные авторами проекта. Поэтому нет смысла класть vendor внутрь src (или lib).
test - каталог для тестов проекта.
В папке vendor имя поставщика и имя проекта могут совпадать, вот они и дублируются.

насколько я вас понял

<путь к проекту>/<путь к папке с библиотеками>/<Наименование производителя>/(<Пространство имен>/)<Название класса>.php

должно соответствовать пространству имен

<Наименование производителя>\(<Пространство имен>\)<Название класса>
что в целом совпадает с той структурой которую я использую

PSR-0 или PSR-4, и как правильно построить структуру проекта?

Сергей Протько: возможно вы правы, помогите тогда разобраться в этом.

Какую литературу почитать по PHP для повышения профессионализма?

xmoonlight: я имел в виду о том что например PDO работает быстрее чем misqli, когда имеет смысл использовать отлов исключений, а когда стоит реализовывать код в обход этого. Понятное дело что все можно протестировать и сделать свои выводы, но зачем изобретать велосипед, ведь по многим вопросам уже есть ответы от опытных людей.