нет, краудин - это способ перевести. дальше в итоге в симфони у вас все равно попадают xliff/json/yaml/etc файлы со строками в нативном для симфони формате. то есть симфони не знает, откуда вы их взяли: перевели руками или откуда-то скачали

я имею в виду, что ы коде добавились новые ключи, как они попадут в краудин?

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

Здраствуйте! Symfony 5.4.6. При попытке выполнить: return $this->redirect('http://symfony.com/doc'); получаю ошибку: Attempted to call an undefined method named "redirect" of class "App\Controller\DefaultController". В версии 5.4.6 уже нет такой функции?

качественный вопрос от серьезного специалиста. у вас IDE нету, чтобы прокликать иерархию классов? вы в блокноте кодите, который не в состоянии подсветить вам метод?

метод на месте

https://github.com/symfony/symfony/blob/6.1/src/Symfony/Bundle/FrameworkBundle/Controller/AbstractController.php#L128

А почему тогда ошибка возникает?

я очень извиняюсь, но потому что руки из жопы, скорее всего

А почему тогда ошибка возникает?

DefaultController унаследован от AbstractController ?

А зачем использовать метод редирект, когда можно вернуть редирект респонз?

нууу, это короче писать?

Зато наследование от ненужного абстракт контроллера)

А так все чистенько и явно

там все равно есть часть полезной херни, типа generateUrl

forward, что там ещё

Ну это урл генератор

флеши, рендер/рендерВью

Подсосать через DI делов на 10 секунд

флеши, рендер/рендерВью

Тоже самое

ну мне не очень нравится писать сотню раз

protected function addFlash(string $type, mixed $message): void { try { $this->container->get('request_stack')->getSession()->getFlashBag()->add($type, $message); } catch (SessionNotFoundException $e) { throw new \LogicException('You cannot use the addFlash method if sessions are disabled. Enable them in "config/packages/framework.yaml".', 0, $e); } }

ну зависимость от контейнера и его состояния - это дичь

абстрактный контроллер в симфе это гавно

Во, контейнер гет...

лучше его не использовать

За контейнер гет вызовы надо тоже осуждать)

ну зависимость от контейнера и его состояния - это дичь

в твоём коде - да, в библиотечном - ради бога

Шо

Да в любом коде это говнокод, кроме парам резолверов или автовайринга самописного разве что)

конкретно этот addFlash я вызываю сотни раз в коде контроллеров, может тысячи даже. шорткат addFlash удобен и экономит 3-5 строчки шаблонного кода каждый раз. ради чего от него отказывать? потому что Кирилл в чяте сказал что это говнокод?

Да пиши

Только не говнокод ом это не станет от этого)

Да в любом коде это говнокод, кроме парам резолверов или автовайринга самописного разве что)

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

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

не потому что наследование это плохо, а потому что ето помойка методов, которая работает через get контейнера

ты можешь мне объяснить в чем это выражается? кроме того, что тебе не нравится. техническим языком, такие-то и такие-то проблемы сопутствуют этому подходу

аргумент "помойка ненужных методов" в целом ставит под сомнение необходимость в симфони, прикинь сколько там в секурити одном "лишних методов", из которых ты 98% не юзаешь

абстрактный контроллер в симфе это гавно

хелперы для респонсов норм а получение из контейнера сервисов - говно

не потому что наследование это плохо, а потому что ето помойка методов, которая работает через get контейнера

есть данность: разработчик каждый день юзает методы redirect, addFlash, createForm, что-нибудь там еще. что ты предлагаешь ему взамен и почему?

хелперы для респонсов норм а получение из контейнера сервисов - говно

в ТВОËМ коде - безусловно, так писать не надо. а как там в кишках симфони они достают, тебе не пофигу ли?

ты же не пишешь юнит(!)-тесты на контроллер-методы, я уверен. тогда чем тебе это мешает?

хелперы для респонсов норм а получение из контейнера сервисов - говно

ну мб, хотя и без них хорошо живется

в ТВОËМ коде - безусловно, так писать не надо. а как там в кишках симфони они достают, тебе не пофигу ли?

да стоит один раз выебать овцу и всё

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

да стоит один раз выебать овцу и всё

ну дядь, это не аргумент 🙂 ты код кеша симфонивского видел? коля-грека там таких овец напереебал, простите, что кровь из глаз льётся

а однако же все юзают и особо не парятся, главное что снаружи оно имеет удобоваримую обёртку

Валентин на стриме про трейты показывал говно говна но это не значит, что надо писать так, как там внутре

ну или там вот это - https://github.com/symfony/translation/blob/6.1/Translator.php#L295

разве это нормально? не особо, мягко говоря. разве это повод не юзать транслятор? да нифига

да стоит один раз выебать овцу и всё

Простите, а джун тогда зоофил со стажем? 😂 или по незнанию не считается?

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

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

А можно про хуки подробнее? Я как понимаю это Event driven design же? чем плох? подход много где вроде используется.

event driven обычно всем хорош, кроме того, что хер концы сыщешь при дебаге. и ответа на вопрос "какая же сволочь вызвала вот это и почему" часто и не найти

А можно про хуки подробнее? Я как понимаю это Event driven design же? чем плох? подход много где вроде используется.

проблема в том, что ты потом не знаешь, где именно происходит изменение данных

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

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

Спасибо) Ключевая мысль - событие событию рознь. Но общую проблему похода я понял.

есть данность: разработчик каждый день юзает методы redirect, addFlash, createForm, что-нибудь там еще. что ты предлагаешь ему взамен и почему?

Запилить свой контроллер, где будет только указанные зависимости

Тоже не очень, конечно...

Тоже превратится в помойку в перспективе

И даже будет хуже, чем сейчас)

будет хуже, ага, потому что его наследовать будет криво

трейт сделать - так в нем тоже самое будет, тоже контейнер нужен

ну либо смириться с помойкой и делать как быстрее 🙂

ты можешь мне объяснить в чем это выражается? кроме того, что тебе не нравится. техническим языком, такие-то и такие-то проблемы сопутствуют этому подходу

Эта абстракция провоцирует писать плохой код

основная проблема

Вот к примеру getDoctrine() https://github.com/symfony/symfony/blob/5.4/src/Symfony/Bundle/FrameworkBundle/Controller/AbstractController.php#L384 понятно,что он депрейкетнут и вырезали. По твоему хорошо доставать так доктрину?

есть данность: разработчик каждый день юзает методы redirect, addFlash, createForm, что-нибудь там еще. что ты предлагаешь ему взамен и почему?

нормально инжектить сервисы и использовать их и не экономить на спичках

Вот к примеру getDoctrine() https://github.com/symfony/symfony/blob/5.4/src/Symfony/Bundle/FrameworkBundle/Controller/AbstractController.php#L384 понятно,что он депрейкетнут и вырезали. По твоему хорошо доставать так доктрину?

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

ну или сервисе, в котором репозиторий, или как-то еще - не суть

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

ну а если у меня формчка и мы просто сохраняем сущность, тут тоже репозиторий нужен или сервис свой? или crud

Вот к примеру getDoctrine() https://github.com/symfony/symfony/blob/5.4/src/Symfony/Bundle/FrameworkBundle/Controller/AbstractController.php#L384 понятно,что он депрейкетнут и вырезали. По твоему хорошо доставать так доктрину?

и диспатч мессадж выпилили, теперь надо явно бас инжектить

трейт сделать - так в нем тоже самое будет, тоже контейнер нужен

нет, не нужен)

trait ProvidesXHelpers { abstract protected function getServiceX(): ServiceInterface; protected function doSomething() { ... } protected function doSomethingElse() { ... } protected function doSomethingElseMatter() { ... } }

class ExampleController { use ProvidesXHelpers; public function __construct( private ServiceInterface $service, ) { ... } protected function getServiceX(): ServiceInterface { return $this->service; } }

это по мне еще хуже

уж лучше в трейте сделать метод инжекта с #[Required]

а то получается херня какая-то - мало того что трейт подключи, так еще и в конструктор твоего контроллера пропихни два десятка зависимостей

и будет у тебя каждый контроллер выглядеть вот так

https://cdn.weblab.pro/uplg0.png