ща на гист залью

https://gist.github.com/SerafimArts/d3c3287f97b080f9e8dea85092af8a7c

Вот

У меня есть два типа аутентификации, по жвт токену и по хедеру (беарарер)

по дефолту надо юзать токен, но в одной (или нескольких) из реализаций надо использовать другую реализацию

я хотел не париться и тупо для алиаса (интерфейса) прописать тег и его ловить в комапйл пассе

но...

но нельзя

чтобы у разных алиасов одного сервиса были разные теги?

нет

задача не выставить тег

задача прочитать метадату интерфейса (алиаса) и разрулить реализации

тег - это один из способов, о которых я знаю, и который нихрена не работает для алиасов

ещё мне приходит на ум юзать autowiring_type, вместо алиаса

тогда с тегами будет всё ок

все равно непонятно из гиста

его разве не убрали?

кого?

autowiring_type ну зависит ещё от версии симфони у тебя

у меня древняя, всё никак не могу апнуться

этот тип задепрекейтили чтоль?

а, да, в 3.3

я слоу

хм

Короче, ещё раз задача: 1) Есть интерфейс и две реализации. 2) Хочется добавить просто метадату для интерфейса и где-то потом её прочитать. 3) Интерфейс указывается алиасом на дефолтную реализацию (одну из двух).

Вот и всё

у меня идей нет

=\

есть идея переопределить класс Alias

но это чот вообще печаль тогда

Переписать проект

Может кто-нибудь пояснить за ServiceValueResolver (который должен резолвить аргументы контроллера в роутере)? Почему мы ищем в контейнере сервисы с id вида FQCN::Action вместо FQCN? Почему далее ищем сам сервис не по типу (хотя суть в type-hinting же, не?), а по имени переменной?

@BonBonSlick так я и переписываю как раз)

просто пытаюсь чуть улучшить этот убогий симфонёвый контейнер)

он там получше ларавел

ну, кажется что нет

хотя

@BonBonSlick так как в симфоне сделать контекстуальный биндинг?

если в плане разработчика, то контейнер симфони лучше, мы его сами вертим как хотим

окок

лучше

так как предоставить в конкретном месте конкретную реализацию по интерфейсу, а в остальных (местах) другие реализации?

только автовайрингом

думаю вам что то в таком роде

https://symfony.com/doc/current/service_container/service_decoration.html

мимо

не оно

т,е. сказать контейнеру: "Когда Х или его потомки требуют сервис Y предоставить ему другую реализацию"

как в ларке: ->when(ExampleController::class)->needs(SomeRepoInterface::class)->give(SomeDBRepo::class)

и когда резволится ExampleController ему внедряется другая реализация

@BonBonSlick это пример того почему симфонёвый контейнер - это огрызок

Никогда не занимался таким

)

не занимался, потому что в симфоне этого нету

Да и в ларе не делал

А зачем ты пытаешься такое делать?

Как по мне, усложняет понимание програмы

у меня есть два типа аутентификации

Я это понял.

нужно в одном месте её подменить на другую реализацию

Но в целом это выглядит нездорово

почему?

вход с помощью ключика для получения токена

Ну потому что ты как будто бы пытаешься упростить, а на самом деле создаёшь костыль.

и вход с помощью токена для выполнения запросов

я пытаюсь работать с интерфейсами

ERROR: S client not available

ну т.е. реализовать слабую связанность

Ну укажи явно зависимости.

Эти.

это уже явные зависимости

На уровне конфигов

конфигов?

Да. :)

ну это уже костыль

=(

Разве?

ну т.е. сервис в одном месте, а конфиги для него в другом?

или что имеется ввиду?

Так ты сервисы же в ямле задаёшь

ну да

только класс, куда надо подсунуть реализацию - это не сервис)

Ну вот там и пропиши зависимость для этого.

т.е. его нет в контейнере

Контроллер можно как сервис юзать.

это не контроллер

Просто иногда дублирование - это не всегда плохо. :)

короче, не важно

никак, не добавить метку для алиаса, значит никак

буду знать, спасибо

чорт

сегодня очередной день **** с симфонёй. Вначале defaults в роутах не наследуются, теперь ничего не сделать с алиасами контейнера

не фрейм, а CMS какая-то :D

шаг влево, шаг вправо и всё рушится

:)

Но все очень явно и без магии зато.

Это большое преимущество для больших систем.

ну...

хз