NO
Ну и подключать тогда только через PSR интерфейс, естественно.
Size: a a a
2020 June 16
В
Если предполагается, что пользователь сможет заменить контейнер на любой PSR-совместимый, то в компонентах нельзя использовать фишки, которые есть только в Yii DI контейнере.
О том и речь
А
а в чём замес? в том, что yii сервис-провайдеры зависят от yii контейнера? и всё?
A
А зачем указывать имя контроллера?(В чем профит)Я про метод name.
T
For example if I use the complete Yii framework what benefit could it bring me using the league container, symfony or php-di?
T
I agree with agnostic libraries as event-dispatcher, but we also have to have exclusive framework libraries, have something that identifies us and sets us apart from others.
А
А зачем указывать имя контроллера?(В чем профит)Я про метод name.
чтобы рендерить по умолчанию из папки с именем контроллера
AM
а в чём замес? в том, что yii сервис-провайдеры зависят от yii контейнера? и всё?
В провайдерах. Они удобны, хочется их предоставлять с каждым пакетом. Но это завязывает нас на yiisoft/di.
AM
TradersVE
For example if I use the complete Yii framework what benefit could it bring me using the league container, symfony or php-di?
That's what @viktorprogger mentioned. There's a benefit in it.
T
If I want to work with the symfony container and all the yaml configuration I program in symfony.
А
Значит надо подумать о шлюзе, чтобы можно было менять способ дефайна в контейнер
Для каждого контейнера свой шлюз )
Именно об этом (вроде) мы и говорили на сайте elisdn'а (об интерфейсах psr и их недостаточности)
Для каждого контейнера свой шлюз )
Именно об этом (вроде) мы и говорили на сайте elisdn'а (об интерфейсах psr и их недостаточности)
T
It's like grabbing a v-powered car, and you want to have a standard that uses v and linear.
AM
Aha :)
AM
Well... we actually have a way to use symfony container... as a part of composite container.
AM
For me personally Yii container is more than enough.
AM
Maybe that's fine that yii-* packages would be dependent on it.
T
It is the most logical, if the package is yii belongs to the framework, having dependence on other packages yii.
AM
OK. Let's assume it's fine for yii-* packages to depend on Yii's DI container.
AM
Then there's another problem.
AM
Where to put service providers for non yii-* packages?