но еще нужно подтянуть файл нужной локали

https://fullcalendar.io/docs/v3/lang
по идее это поможет

Добрые люди. Вопрос не по симфони (но юзаю его), а по годности кода.
Насколько плоха или хороша идея, чтобы создать BaseController, который наследуется от AbstractController, а все остальные контроллеры уже наследуются от BaseController?
Например, нужно тащить постоянно во все методы Request $request и TranslatorInterface $translator и чтобы во все методы не инжектить 2 объекта (а может и N в зависимости от потребностей) служит BaseController с protected $translator и protected $request.
Хотелось бы услышать плюсы, минусы такого решения, а возможно и ссаными тряпками закидаете.
Знаю, что никто не запрещает так написать, но возможно я не вижу явных каких-то недостатков из-за отсутствия годного опыта

в нашем проекте лет 5-6 назад так сделали.. потом 2 года пилили.. сейчас уже 4-й год от этого уйти пытаемся.. :)

а чего пытаетесь уйти? есть какие-то неприятные вытекающие?

что-то вроде "в каждом контроллере должно быть описано всё, что ему нужно". к тому же появляется желание запихнуть в базовый контроллер, какие--нибудь методы, которые нужны только 2-3м контрноллерам. а еще и контейнет симфы туда запихнуть. :)

Чем меньше наследования, тем лучше

Короче понял, наверное...
Все упирается в чистоту кода, его читабельности и самодостаточности на уровне зависимостей

прям во все-все методы?

да. как я написал выше, 2 класса допустим нужны будут в 95% случаев

перевод к примеру есть возможность в твиге без инжекции пользоваться

да, это я знаю, но если будет допустим генерится title для страницы с логикой генерации какой-то, то думаю, что твиг в этом не поможет

это возможно конечно облегчит тебе жизнь, но как с поддержкой...

что инжектится, куда, то ли инжектится или нет, хрен короче прочтешь

я бы "муки" и "страдания" вынесла бы в отдельный сервис, имхо

ну я бы не назвал это "муками и страданиями", просто хотел услышать мнения и понял, что нужно соблюдать чистоту кода, его читабельность и самодостаточность на уровне зависимостей.
На крайняк, я так понимаю, можно тот же TranslatorInterface $translator для App\Controller\ в services.yaml передать как аргумент и ловить в конструкторе класса

Симфониевский AbstactController - боль и мусор и его надо избегать во всех случаях, если вы пишите что-то сложнее бложика.

В идеале - отдельный класс под каждый экшн с __invoke(), далее инжектим либо в конструктор, либо в аргументы через ArgumentResolver, если часто юзается в экшенах.

А в чем боль проявляется на долго дистанции?

тоже не очень понял...

Зачем отдельный класс на экшн если экшены отлично группируются по типу или сущности или другие способы. Только классы плодить