Д
Собственно идея как в старых добрых ini, разделить параметры по секциям, один пакет- одна секция.
да, так будет круто. нужно только причесать этот способ
Size: a a a
2020 May 27
В
Пока ничего лучше в голову не приходит, это хороший вариант.
Д
сюда бы приделать автоподтягивание настроек, если они лежат как
config/
—yiisoft/yii-web/params.php
—yiisoft/yii-rest/params.php
и компилить их в один большой params.php с секциями
config/
—yiisoft/yii-web/params.php
—yiisoft/yii-rest/params.php
и компилить их в один большой params.php с секциями
'vendor-name/package-name' => [Д
но спорно
DS
сюда бы приделать автоподтягивание настроек, если они лежат как
config/
—yiisoft/yii-web/params.php
—yiisoft/yii-rest/params.php
и компилить их в один большой params.php с секциями
config/
—yiisoft/yii-web/params.php
—yiisoft/yii-rest/params.php
и компилить их в один большой params.php с секциями
'vendor-name/package-name' => [Ну так плагин их так и собирает вроде, в runtime/build/config/params.php, разве нет?
АН
@yiiliveext по модулям не дошли руки ?
RM
Александр Некрасов
как сейчас не очень, идея @yiiliveext будет лучше чем сейчас
+1
DS
Там секции только для виду. Они не учитывались, насколько помню :)
Учитывались, но это не суть важно. Надо разделять настройки пакетов. чтобы можно было открыть билд и посмотреть что у кого сейчас установлено и при желании переопределить.
Д
идея была в том, чтобы не писать лишнего в composer.json и чтобы автоматом такие папки резолвились.
Д
хотя, кажется, не очень будет
DS
Александр Некрасов
@yiiliveext по модулям не дошли руки ?
Занят сейчас другим проектом, надеюсь что на этой неделе разгребусь.
RM
RM
сюда бы приделать автоподтягивание настроек, если они лежат как
config/
—yiisoft/yii-web/params.php
—yiisoft/yii-rest/params.php
и компилить их в один большой params.php с секциями
config/
—yiisoft/yii-web/params.php
—yiisoft/yii-rest/params.php
и компилить их в один большой params.php с секциями
'vendor-name/package-name' => [Я тоже так думал. Как Ларавел.
T
I in the modules or extensions instead of using parameters, I will create a configuration class it will be much better.
Д
Я тоже так думал. Как Ларавел.
пару раз тыкал, не понравилось там)
T
it is best to create the properties and try not to use parameters.
RM
TradersVE
I in the modules or extensions instead of using parameters, I will create a configuration class it will be much better.
Like this? https://github.com/yiisoft/yii-cycle/pull/5
DS
TradersVE
it is best to create the properties and try not to use parameters.
Params are not users settings for modules but it is settings for a module/package di. If you want to use user settings you can create separate Settings class and save it in the separate file|database|key-value storage
AV
Мы так и не порешали с наименованиями. И это касается не только ключей в провайдерах, но и параметров. Пока пакетов/модулей мало, то все еще выглядит ок, но при увеличении их числа, будет сильно хуже. Поэтому надо какое-то соглашение. Например, для параметров делать так:
'vendor-name/package-name' => [
'enabled' => true,
'someSetting' => [
'someKey' => 'someValue',
]
]
мы используем плоскую структуру парамов, без массивов, через точку, с префиксом типа названия проекта, который может быть общий для нескольких пакетов:
`
return [
'the-project.some-feature.enabled' => false`,
'the-project.some-feature.name' => 'default',
];
`
так потом чуток читабельнее:
`
SomeFeature::class => [
'__class' => ..,
'enabled' => $params['the-project.some-feature.enabled'],
]
`
но массивами c именами пакетов, тоже ок
главное чтоб порядок был
`
return [
'the-project.some-feature.enabled' => false`,
'the-project.some-feature.name' => 'default',
];
`
так потом чуток читабельнее:
`
SomeFeature::class => [
'__class' => ..,
'enabled' => $params['the-project.some-feature.enabled'],
]
`
но массивами c именами пакетов, тоже ок
главное чтоб порядок был
AM
Ну, вижу что мнения в общем сходятся. Это хорошо. @yiiliveext я тогда запишу в доку и начнём править пакеты.