А
А разве используя фабрику мы зависим от реализации контейнера?
а сам подумай. Будет php-di в проекте. Откуда фабрика будет брать зависимости? Точно также сама сколотит как и спиралевская сейчас )
Size: a a a
2020 August 22
СП
а сам подумай. Будет php-di в проекте. Откуда фабрика будет брать зависимости? Точно также сама сколотит как и спиралевская сейчас )
Не, я в фабрику передаю контейнер же
СП
Вот. Поэтому без разницы какая реализация контейнера.
А
да, это может сработать )
СП
Зависимость от
yiisoft/composer-config-plugin наверное нужно убрать?А
а я хз, какие там правила сейчас на это дело )
СП
Ведь любой пакет можно и без него использовать.
А
наверное можно и убрать
СП
сделал)
А
ты на проекте тестировал? зависимости идут из контейнера? не надо в сусле контрибутить ничего?
СП
ты на проекте тестировал? зависимости идут из контейнера? не надо в сусле контрибутить ничего?
Попробовал на примере репозитория - зависимости получаются в конструкторе
А
можешь добавить пару тестов? и тогда будут убиты сразу 2 issue
А
хотя ладно, можно пока и без тестов )
А
Попробовал на примере репозитория - зависимости получаются в конструкторе
т.е. это будет решено? https://github.com/yiisoft/yii-cycle/issues/20
СП
т.е. это будет решено? https://github.com/yiisoft/yii-cycle/issues/20
нет, тут, если я правильно понял, проблема в том, что нужно сделать генератор для сбор репозиториев.
А
нет, тут, если я правильно понял, проблема в том, что нужно сделать генератор для сбор репозиториев.
если теперь репозиторий из контейнера можно получить, то issue решена
СП
нет, сейчас...
А
чтобы не было всяких $orm->getRepository($entityClass)
NO
Вообще разное поведение в зависимости от того есть ли в контейнере какая-то реализация или нет, разве это норм?
Это не норм. Твоя реализация и должна задавать разное поведение. Просто надо добавить дефолтную
СП
чтобы не было всяких $orm->getRepository($entityClass)
getRepository - это не просто вытащить из контейнера, к сожалению