AM
return Config::create([
MyInterface::class => MyClass::class,
// ...
])->withModifier(new SaveOrder());
Добавил оба.
Size: a a a
2021 January 28
А
в дискуссиях голосовалки не завезли? :)
AM
AM
Ещё у нас есть варианты?
AB
Я так понимаю это для конфига? А какой там юзкейс вот этих модификаторов? в частности порядок сохранять*
AB
И вот к примеру у меня есть две коллекции, у каждой из них стоит
SaveOrder, но они друг другу противоречат. Какой результат будет?Д
А в третьем не так?
в третьем если ArrayCollection::MODIFIERS то норм тоже.
Д
а __ непонятно что.
СП
И вот к примеру у меня есть две коллекции, у каждой из них стоит
SaveOrder, но они друг другу противоречат. Какой результат будет?Все модификаторы будут выполнены, то есть в итоге будет порядок как в последнем массиве
AB
Все модификаторы будут выполнены, то есть в итоге будет порядок как в последнем массиве
А как понять какой массив (в контексте конфига - это я так понимаю файлики) будет последним?
СП
А как понять какой массив (в контексте конфига - это я так понимаю файлики) будет последним?
От низа к верху, последний - тот что в приложении
СП
https://github.com/yiisoft/yii-demo/blob/master/composer.json#L106-L109 - вот тут вот порядок самому получается задавать?
В том числе. Плагин же определяет порядок слияния массивов: сначала из пакетов в порядке указанном в composer.json пакета, потом к ним добавляет конфиги из приложения также в порядке указанном в composer.jaon
AB
Просто в ПР https://github.com/yiisoft/yii-demo/pull/167/files - везде используется SaveOrder. Т.е получается он там нужен всегда? Или все-таки могут быть ситуации, когда он не нужен?
AB
Я к тому что может это на уровень конфиг плагина вынести?
СП
Не везде, только события и провайдеры, для конфига контейнера и параметров не нужно.
(В пр сделано для параметров, но кажется это случайно вышло и там не надо)
(В пр сделано для параметров, но кажется это случайно вышло и там не надо)
AM
Я к тому что может это на уровень конфиг плагина вынести?
Это вариант номер 2.
AM
Не везде, только события и провайдеры, для конфига контейнера и параметров не нужно.
(В пр сделано для параметров, но кажется это случайно вышло и там не надо)
(В пр сделано для параметров, но кажется это случайно вышло и там не надо)
Да, для параметров не надо было :)
2021 January 29
NO
А контейнер модульный нужен, чтобы можно было подключать модули и делегировать получение зависимостей из других контейнеров:
И в классах модуля А понятно, что кеш будет обязательно в памяти, а логгер пусть с уровня приложения подтянется.
Так же любые определения можно "локализовать", если оно того требует. Без алиасов и копи-пасты конфига модуля в конфиг приложения.
RootContainer:
Logger
ModuleAContainer:
Cache => MemCache
И в классах модуля А понятно, что кеш будет обязательно в памяти, а логгер пусть с уровня приложения подтянется.
Так же любые определения можно "локализовать", если оно того требует. Без алиасов и копи-пасты конфига модуля в конфиг приложения.
Не понял почему тут обязательно нужно несколько контейнеров. Что мешает в одном сделать?
NO
Что характерно, снова от модулей все эти костыли прут, как и в случае с конфиг-плагином. Там не смогли в модульность и закопались, в контейнере опять не смогли, опять закопались..