Страница 1 из 1

config/config.php и модульность

Добавлено: 10.02.2021, 09:46
korshunov
Обнаружилась забавная картина.

Допустим, пользователь добыл и скопировал два модуля (M1 и M2), у которых в config/config.php присутствует один и тот же параметр
M1. module_config_variable = 5
M2. module_config_variable = 7

Если установить M1 все в порядке. Если затем установить M2, то получите белый экран!

Представьте, что будет дальше. Пользователь начнем теребить второго разработчика (Р2). А тот отвечает, что все отлично работает. На форуме другие пользователи, тоже ответят, что M2 у них работает.

Через время подключит пользователь debug_mode, прочтет
Fatal error: Uncaught Exception: Duplicate parameter "module_config_variable" in...

Уже станет чуть-чуть понятно, куда копать. Далеко не сразу, но выяснится, что имеется конфликт в двух модулях.

Что дальше? Просить разработчика М1 (Р1), чтоб поправил переменную, чтоб было не как у Р2? Или просить об аналогичном Р2? Если повезет, Р1 пойдет навстречу и изменит. А потом вдруг окажется, что совпадение с Р3...

В то же время, если в штатном config/config.php вставить
config_variable = 8
config_variable = 9
две строки с одинаковыми переменными, то фатального белого экрана не возникает.

Такие вот дела с передовой ООП-разработкой...

Добавлено: 10.02.2021, 10:30
zyxer
По вашему лучше если один модуль в тихую переопределит директиву конфига другого модуля и это может вылезть ай как больно )
Вообще, когда вы пишите свой модуль, лучше (я думаю это очевидно) называть директивы конфига как-то уникально, чтобы уменьшить вероятность пересечения её с директивами других модулей.

Через время подключит пользователь debug_mode, прочтет
Если уже и видите "белый экран" думаю логично сразу смотреть логи. На то они и логи, чтобы понимать что пошло не так. Ранее мы выводили сообщение об ошибке, но сейчас пишем в лог, а выводим только если включен debug_mode

Но мы чуть переделали в новой версии, чтобы можно было директиву из конфига модуля переопределять в config/config.local.php

Такие вот дела с передовой ООП-разработкой...
это высказывание не имеет никакого смысла, т.к. дело не в ООП, а если посмотреть в Okay\Core\Config::loadConfigsFrom() то мы там явно кидаем исключение. Это говорит что так и задумывалось.

Добавлено: 18.02.2021, 13:14
korshunov
zyxer писал(а):По вашему лучше если один модуль в тихую переопределит директиву конфига другого модуля и это может вылезть ай как больно )

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

Еще похожая ситуация. Если модуль при установке пытается создать таблицу и запрос на создание дает ошибку (например, таблица с таким именем уже есть), то как раз и произойдет случай "в тихую" - внешне все как будто нормально, ошибок не видно, но реально таблица не создана. Следы неудачного запроса можно увидеть в логе, но кто ж туда каждую минуту смотрит?

А если модулю надо добавить поле в стандартную таблицу, а поле с таким именем уже существует, то он смело "в тихую" меняет свойства поля на нужные ему, и в логе никаких следов не оставляет. Тут возможны даже потери данных...

Добавлено: 18.02.2021, 13:38
zyxer
Поставим задачу в бэклог просмотреть еще раз этот момент и подумать какие там могут быть нюансы и их решения.

Мы в данный момент кидаем Exception, который либо в лог пишется либо на вывод отдается. Как можно сделать более понятно?

Добавлено: 18.02.2021, 16:09
makki
Еще одна проблема с таблицами БД и головная боль для программиста, что модулем создаются новые таблицы, а после отключения (удаления) модуля, всеравно остаются.

Добавлено: 18.02.2021, 16:33
zyxer
тут думаю будет больше головняка если кто-то удалит модуль и удалятся все данные которые были ранее заполнены. Мы много думали об этом, но кажется лучше, если это нужно будет, вичищать руками. Но также есть мысл таки сделать метод в Init-е delete() который будет отрабатывать при удалении модуля, и туда разработчик будет добавлять что посчитает нужным