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

StreamedResponse - не контейнер данных. Где interface :))

1. return new TemplatedResponse('template.html', ['name'=>'Sergey']);

не выйдет так сделать в любом случае

why ? у меня работает)

кто занимается рендерингом? респонз?

откуда он знает про движок для рендеринга?

кто занимается рендерингом? респонз?

$container->getTemplateEngine()

внутри Response класса:

2ой вариант return new TemplatedResponse('template.html', ['name'=>'Sergey'], $engine);

return $this->render('template.html'); не вариант?

внутри Response класса:

Ну да. Пока у нас експеремент. вариант 2 рабочий)

return $this->render('template.html'); не вариант?

вариант) но не повод не создавать интерфейс

как-то это не окей) ну я не спорю, есть JsonResponse, BinaryFileResponse, в одном json_encode делается, а во втором file_get_content но какой в этом случае профит? $this->render это встроенная штука, а так вы городите целую кучу всего и.. для чего?

И ощутил всю боль от traits в рнр )

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

Сергей, а как следать return new AppRedirectResponse(new Uri()) Вариант с $this->render не вариант У нас будет 10 методов в базовом контроллере.

Сергей, а как следать return new AppRedirectResponse(new Uri()) Вариант с $this->render не вариант У нас будет 10 методов в базовом контроллере.

return $this->redirect и $this->redirectUrl есть из коробки

как-то это не окей) ну я не спорю, есть JsonResponse, BinaryFileResponse, в одном json_encode делается, а во втором file_get_content но какой в этом случае профит? $this->render это встроенная штука, а так вы городите целую кучу всего и.. для чего?

Всмысле встроенная штука?

Всмысле встроенная штука?

https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerTrait.php#L219

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

иду читать по mixin in kotlin )

ivan Конешн можно сделать Response иммутабельным, ибо $jsonResponse->setHeader('text/html') тоже не ок, и собирать респонс с помощью билдеров и тп, но не будет ли это излишним

иду читать по mixin in kotlin )

там их нет. есть только дефолтные методы в интерфейсах и делегаты

ivan Конешн можно сделать Response иммутабельным, ибо $jsonResponse->setHeader('text/html') тоже не ок, и собирать респонс с помощью билдеров и тп, но не будет ли это излишним

проблема в первою очередь в наследованием.

https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerTrait.php#L219

А, ну это дерьмо. На самом деле всего лишь инстанс EngineInterface

А, ну это дерьмо. На самом деле всего лишь инстанс EngineInterface

в смысле дерьмо?

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

в каких языках норм трейти?

проблема в первою очередь в наследованием.

с наследованием всегда проблемы... наследование это и есть проблема)

с наследованием всегда проблемы... наследование это и есть проблема)

100%

в смысле дерьмо?

Не наследуюсь от симвоневых контроллеров принципиально.

Не наследуюсь от симвоневых контроллеров принципиально.

мы за вас очень рады

придерживайтесь ваших принципов и пишите гавнокод

придерживайтесь ваших принципов и пишите гавнокод

Ахах, не делай поспешных выводов. Когда нибудь и ты дойдешь до framework agnostic

:D ))

да-да, а pdo нужно для смены субд, которая меняется, примерно, никогда)

в каких языках норм трейти?

скала

придерживайтесь ваших принципов и пишите гавнокод

если я не использую symfony controller у меня значит говнокод ?

скала

thanks, посмотрю.

если я не использую symfony controller у меня значит говнокод ?

не исключено. Сам факт того что ты там что-то юзаешь или что-то не юзаешь ничего не говорит о твоем коде

не исключено. Сам факт того что ты там что-то юзаешь или что-то не юзаешь ничего не говорит о твоем коде

согласен)

Ахах, не делай поспешных выводов. Когда нибудь и ты дойдешь до framework agnostic

тебе когда-нибудь доводилось видеть framework agnostic проект? а смену фреймворка в рамках этого же проекта?

фанатичное следование framework agnostic имхо, чушь)

Ахах, не делай поспешных выводов. Когда нибудь и ты дойдешь до framework agnostic

хотя бы одну причину назови

фанатичное следование framework agnostic имхо, чушь)

ну тип есть определенное зерно смысла - типа не надо менять код бизнес логики когда ты апаешь версию фреймворка. Вот только потрогать инфраструктурный код придется.

скала

ну там смешали классы, интерфейсы и коней в одну кучу. но не сказал бы что это круто и нужно

ну там смешали классы, интерфейсы и коней в одну кучу. но не сказал бы что это круто и нужно

ну не говори, я тож не говорю, с другой стороны классы это точно рак

но это уже совсем другая история

ну не говори, я тож не говорю, с другой стороны классы это точно рак

в любом современном языке есть классы, в том или ином виде

либо этот язык не используется

тебе когда-нибудь доводилось видеть framework agnostic проект? а смену фреймворка в рамках этого же проекта?

Да, с silex на symfony

ну тип есть определенное зерно смысла - типа не надо менять код бизнес логики когда ты апаешь версию фреймворка. Вот только потрогать инфраструктурный код придется.

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

если я не использую symfony controller у меня значит говнокод ?

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

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

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

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

Ты им пользуешься, кэшированием, контейнером, компонентами.

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

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

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

я и не брал фреймворк) используем HttpFoundation компонент

ну типа.... все что передается как параметр в роутер и что дергает симфони является symfony controller)))

я и не брал фреймворк) используем HttpFoundation компонент

почему не psr реализацию?

я и не брал фреймворк) используем HttpFoundation компонент

роутер?

а, мы не в симфони чатике просто

Ты им пользуешься, кэшированием, контейнером, компонентами.

AbstractController и ControllerTrait это часть FrameworkBundle пакета

1. psr еще не существовал 2. роутер не юзаем

1. psr еще не существовал 2. роутер не юзаем

можно поподробнее про 2-ой пункт?

grpc? graphql? файлики?

AbstractController и ControllerTrait это часть FrameworkBundle пакета

Но это не обязывает меня их использовать.

ну тип как в былые времена было модно - posts.php, edit-post.php и т.д.

можно поподробнее про 2-ой пункт?

у нас свой роутер php массив конфигурация и несколько классов. Ничего сложного.

ERROR: S client not available

Но это не обязывает меня их использовать.

т.е вы тратите время и пишите свой базовый контроллер?

Но это не обязывает меня их использовать.

нет, не обязывает. А Request ты юзаешь?

ну тип как в былые времена было модно - posts.php, edit-post.php и т.д.

да неє)))

т.е вы тратите время и пишите свой базовый контроллер?

Серег, можно и без базовых контроллеров жить)

чтобы пришел новый человек, который знает симфони, посмотрел на это и первым делом сказал wtf?

Серег, можно и без базовых контроллеров жить)

но зачем?)

т.е вы тратите время и пишите свой базовый контроллер?

Нет.

но зачем?)

+

так-то жить можно и без рук, без ног и печень продать)

но зачем?)

не знаю, мне нравится дефолтный AbstractController или как он там завется

просто факт - у меня есть парочка таких вот контроллеров-сервисов

нет, не обязывает. А Request ты юзаешь?

Конечно, но это компонент, а не часть бандла.

Нет.

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

Конечно, но это компонент, а не часть бандла.

а в чем разница?)

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

какие-то странные принципы

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

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

у всего должен быть смысл.

Посоветуйте проверенный php daemonize фреймворк (вроде Kraken, phpDaemon), а то хотим упороться в сервисы и amqp эвенты

внутри проекта менять пхп фреймворк... кто такие решения принимает?

Посоветуйте проверенный php daemonize фреймворк (вроде Kraken, phpDaemon), а то хотим упороться в сервисы и amqp эвенты

systemd + while(true)

да, вариант Сергея лучше

а еще лучше кубернетс)

systemd + Loop::run() :)

а еще лучше кубернетс)

перебор

а в чем разница?)

В отличиях

внутри проекта менять пхп фреймворк... кто такие решения принимает?

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

В отличиях

фонд золотых цитат

ну так домен и так максимально отвязывается от инфраструктуры) просто by design. и то не всегда такой номер прокатывает)

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

внутри проекта менять пхп фреймворк... кто такие решения принимает?

Ну вот мы приняли, после того, как silex ушел в небытие. А поскольку контроллеры в сайлексе не были зависимы от каких-либо симфоневых обвязок, было достаточно просто перенести весь проект на symfony 4