про наследование?

\Symfony\Bundle\FrameworkBundle\Controller\AbstractController как базовый будет использоваться

да, вероятно, к тому идет

а там через контейнер не получишь все что тебе нужно как раньше)

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

бандл? ты про Dunglas ActionBundle?

бандл? ты про Dunglas ActionBundle?

ага или речь о другом подходе? других не слышал)

просто можно и без него в 3.3

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

и там неймспейс Controller был захардкоджен IIRC

я юзаю, красота.

а там через контейнер не получишь все что тебе нужно как раньше)

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

просто можно и без него в 3.3

а можно меня носом в доку ткнуть? не могу найти

https://symfony.com/doc/current/controller/service.html#invokable-controllers

у меня контроллеры в Action +

AppBundle\Action\: resource: '../../src/AppBundle/Action' public: true tags: ['controller.service_arguments']

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

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

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

нужный сервис

сейчас ты можешь сделать $this->get(LoggerInterface::class) и у тебя будет сервис, а раньше надо было по алиасам только и всякие колбасы в духе $this->get('app.user.trololo.strategy.loader`) юзать, если у тебя неймспейсы с большой вложенностью

первый метод интересен, спасибо

интересно, раньше ж сервис тоже можно было назвать AppBundle\Service\FavoriteService и сделать $this->get(FavoriteService::class)

у меня контроллеры в Action +

почитал про adr в чем плюшка такого метода?

почитал про adr в чем плюшка такого метода?

можешь всем говорить что у тебя не MVC

интересно, раньше ж сервис тоже можно было назвать AppBundle\Service\FavoriteService и сделать $this->get(FavoriteService::class)

::class не всегда был доступен в пхп)

почитал про adr в чем плюшка такого метода?

меньше шансов что у тебя контроллеры будут раздуты на 10+ зависимостей

меньше шансов что у тебя контроллеры будут раздуты на 10+ зависимостей

и тут вопрос — потому что ADR или потому что SRP?

и тут вопрос — потому что ADR или потому что SRP?

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

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

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

это уже радикальный srp имхо

блин, начал проставлять defaults public для сервисов три файла с конфигами - 48 deprecations, 4 файла - 58, 5 файлов - 48 втф?

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

и тут вступает в игру автовайринг и автоконфигурация. Вот тот кусок конфига для экшнов который я выше скидывал работает для неограниченного количества классов

и тут вступает в игру автовайринг и автоконфигурация. Вот тот кусок конфига для экшнов который я выше скидывал работает для неограниченного количества классов

хм, а так козырно получается

ага :)

я тоже сначала плевался на эти нововведения, но конфигов реально меньше. Проекты с большим количество сервисов напряжно переводить, но на новых — просто сказка

я тоже сначала плевался на эти нововведения, но конфигов реально меньше. Проекты с большим количество сервисов напряжно переводить, но на новых — просто сказка

не оч напряжно

просто время надо выделить и отследить, чтобы не сломалось я на своем сейчас стараюсь держать баланс между новым и старым а то по сути я уже третий разработчик здесь и накопилось немало вонючего в процессе перевода на 3.4 выкинул штук 5 зависимостей из composer.json

3.4?

он же еще не релизнулся

3.3 щас стабильный

3.4 в feature freeze

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

пока все перетянется, пока оттестируется - как раз уже выйдет стабилка кстати, у симфони rc ведь выходят прямо перед релизом? по идее, должны быть через 2-3 недели?

30го ноября где-то релиз будет

бетки пойдут где-то к концу октября или даже началу ноября

что там такого, что есть смысл переходить на 3.4? почему не подождать ноября и не сразу на 4.0

3.4 и 4.0 одновременно выйдут

3.4 это то же самое что 4.0, только с депрекейтами

4.0 - без депрекейтов

такая же история как была с 2.8 и 3.0

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

я когда на 4ю версию апнусь переведу

там в принципе не много

::class не всегда был доступен в пхп)

я вкурсе) но с 5.5 уже можно начинать делать так

ну или get_class() если < 5.5

плагин в пхпшторме раньше ругался если называешь сервисы по FQCN

ща проверю, у меня 2.8

вроде всё ок

лично у меня хотелка заказчика - lts версии

он в этом сечёт или просто из неба хочет?

потому 4.0 не катит хотели еще весной на 3.3 перейти, но уговорили только на 2.8 (с 2.7)

у нас критерий чтобы работало, и девы были довольны

у нас критерий чтобы работало, и девы были довольны

отличный критерий )) куда на собес идти? :D

он слегка сечет начинал разрабатывать проект он

отличный критерий )) куда на собес идти? :D

?

никогда не понимал этих технических ограничений

ERROR: S client not available

сидят на дебианах, на пхп 5.4, 1.4 симфони из-за того что тимлид так написал все 5 лет назад и сейчас стал СТО и не хочет ничего менять

ну, у нас обусловлено большой командой и кучей старого гомна... но львиную долю depreceted уже выпилили... надеюсь скоро на 3.3 перейдём

некоторые до сих пор на 2.7 сидят

при том что очень многие из тех с кем я общаюсь в киеве

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

7.2 еще в ноябре будет

там и на 7.2 прыгну в любом случае, главным апдейтом был 5.6 > 7.0

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

зачем тебе идти на 4.0, если ты еще на 3 не перешёл? )) вопрос в том, что нужно будет меньше делать работы потом или ты планируешь с 2.8 на 4.0?

это будет ад

если проект большой

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

eraseCredentials в userinterface - кто-нибудь использует? и для чего?

хохохо, смотрите что приняли!

https://github.com/symfony/symfony/pull/22200

services: App\Manager\TwigManager: arguments: [!tagged twig.extension] и пачка сервисов доступна так: class TwigManager { public function __construct(iterable $twigExtensions)

Круто

Как раз есть кейс, где сейчас компилер пассом собираю колекцию сервисов

пробую feature-based структуру, как можно для routing annotations задать какую-то более-менее умную маску поиска?

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

аннотаций который отсюда https://symfony.com/doc/3.0/bundles/SensioFrameworkExtraBundle/annotations/routing.html

пробую feature-based структуру, как можно для routing annotations задать какую-то более-менее умную маску поиска?

можно в 3.4 DSL пхпшный заюзать)

но у нас 3.3(

https://github.com/symfony/symfony/pull/24180

а объяснить sensioframeworkextrabundle не получится это?

у меня есть в src SomeContext\Http\Controller, хочу там аннотации юзануть

@fes0r ты спрашивал, есть ли связь один ко многим.. есть и не одна а 3

@fes0r ты спрашивал, есть ли связь один ко многим.. есть и не одна а 3

почитай окромиуса по поводу того насколько медленно работает гидрация доктрины в этом случае

а если ManyToMany ?

есть просто джионы и по таким связям

а если ManyToMany ?

тоже

ocramius.github.io/blog/doctrine-orm-optimization-hydration/