artem
Всем привет) щя ебнусь) failed asserting that the response is redirected. Ошибка в тесте не существующей сущности. Редирект в контроллере прописан
Nikolay
artem
Da
Konstantin
да это не мой :) это пример класса перегруженного зависимостями
Kirill
нет, просто переписать эту дто
Kirill
из того что я вижу - код можно сделать короче более чем в 2 раза
Konstantin
я вижу только constructor property promotion
Konstantin
но наверняка этот код должен быть совместим с 7.4
Kirill
ну 7ка уже 4 месяца назад задепрекейчена как
Konstantin
ну расскажи об этом симфони и их кастомерам :)
artem
Можно дебагнуть тест
Смысла даже нет. Пишет что редирект не срабатывает, уже хттп клиента изнасиловал как мог)
Nikolay
Смысла даже нет. Пишет что редирект не срабатывает, уже хттп клиента изнасиловал как мог)
Так там ведь редирект респонс
Kirill
А что старые. У нас проект которому 10+ лет и тоже на 8.1 переезжаем с 8.0
Kirill
буквально сегодня докер для кубера собирал)
Kirill
Не, ну вопрос был изначально в том, что сервис-локация, зависимая на состояние - это зло
Kirill
Варианты с DI человека не устроил
Kirill
Варианты с трейтами тоже
Kirill
А на то, что портянка из аргументов сокращаемая в 2 раза - ответ был про то, что надо саппортить легаси пых
Kirill
Ну естественно надо, ведь пока пытаешься обмазаться моками всего и вся в тестах, чтоб не дай божечки не отвалилось ничего - это время можно потратить на более профитные вещи))))
Kirill
Ладно, это было уже слишком толсто. Каюсь
Nikolay
Ну естественно надо, ведь пока пытаешься обмазаться моками всего и вся в тестах, чтоб не дай божечки не отвалилось ничего - это время можно потратить на более профитные вещи))))
Допустим есть контроллер с пятью экшенами, в которых большинство зависимостей тянется через container.get. Какой вариант есть, кроме вынести все зависимости в конструктор?
Kirill
ммм... всунуть их через аргументы экшенов, не?)
Kirill
ну там, например:
public function someAction(#[Service] EntityManagerInterface $em, Request $req)
{
// ...
}
Nikolay
ммм... всунуть их через аргументы экшенов, не?)
А это нормально, если они в большинстве экшенов используются?
Nikolay
Мне не нравится этот подход внедрять через методы
Kirill
А это нормально, если они в большинстве экшенов используются?
если в большинстве, то лучше в конструктор
Kirill
а если таких зависимостей больше 2-3х, то обычно всё выносят в сервисный слой
Nikolay
а если таких зависимостей больше 2-3х, то обычно всё выносят в сервисный слой
То есть внедрение в методы это нормальный подход?
Kirill
То есть внедрение в методы это нормальный подход?
в методы, где нужны эти сервисы/зависимости
Nikolay
в методы, где нужны эти сервисы/зависимости
То если зависимость используется уже не в одном методе, логичнее выносить в конструктор
Kirill
лол)
Kirill
давай ещё раз 10 переспроси)
Dmitriy
Сергей
джоинь теги
Shokha
Vlad
посмотри что в аттрибуте роут когда урл такого нету
Vlad
Shokha
Vlad
незчт
Shokha
Не понятно почему это сабскрайбер работает 3 раза)
Shokha
/_profiler если во так зайти он работает 3 раза
Shokha
2ое и 3 раз route null
Павел
Павел
0377
Kirill
Всем привет! Подскажите, как правильнее.
Допустим, у меня есть сущность Employee. И в контроллере, при создании нового сотрудника я отправляю событие
$this->eventDispatcher(new EmployeeCreatedEvent());
Теперь я хочу при создании сотрудника отправлять в общий канал в слак уведомление о том, что у нас в компании новый сотрудник. Встречайте его и тд.
Для этого я в компоненте со слаком подпишусь на это событие и буду слать сообщение.
У меня вопрос, как правильно должен подписчик выглядеть?
Вариант 1: подписчик называется EmployeeCreatedSubscriber и содержит в себе метод отправки сообщения. И это кажется мне логичный, ведь это именно подписчик, в значит он должен подписываться на конкретное событие. Наверное на одно.
Вариант 2: подписчик называется GreetingsMessageSubscriber. Внутри он подписан на EmployeeCreatedEvent и на другие события, если они есть. Он отправляет сообщения с приветствием и подписан на все события, при наступлении которых нужно слать сообщение в слак.
Короче, в первом случае подписчик обрабатывает ровно одно событие, во втором группу событий.
Какой вариант используете вы и как на ваш взгляд правильно?
Иван
Shokha
Доброе утро! У кого нибудь есть простой пример для деплойинг через github Actions
Shokha
.github/workflows папка
Dmitry
Shokha
Везде разный пример кто-то прям yml пишет свой хост логин пароль кто-то нет!
В общем я сделал так
1) ssh-keygen -t rsa -b 4096 -C "your_email@example.com" => c локального компа
2) Создал в гитхабе Action secret => вел туда privateKey
3) положил fileName.pub на сервер /etc/ssh
4) cat /etc/ssh/fileName.pub >> /home/myuser/.ssh/authorized_keys
думаю все правильно сделал!
вот теперь осталось создать workflows папку и файл! вот для этого и надо пример
Aleksander
Всем привет!
подскажите, какой самый простой способ внутри бандла повлиять на конфиг приложения, в котором этот бандл подключается? например, добавить свою папочку в doctrine_migrations.migrations_paths
с разбегу, думал, магия есть какая, но просто положив конфиг в папку Resouces/config ничего не поменялось
полез читать доки, смотреть как у той же доктрины сделано - там чем дальше в лес, тем толще партизаны)
ну ладно ExtensionInterface, но всякие CompilerPass и тд...
подскажите туда ли копаю вообще
спасибо!
Konstantin
скорее всего из коробки - никак, как-то интегрироваться с бандлом миграции самостоятельно. но мне кажется, что в бандле миграциям не место
Konstantin
то есть смотрите, у меня логика какая: я подключаю ваш бандл в первый раз, делаю в своём проекте migrations:diff, получают дифф, применяю его. дальше вы обновляете свой бандл, меняете там схему. я себе затаскиваю из композера вашу новую версию бандла, снова У СЕБЯ делаю дифф и его применяю-коммичу
Konstantin
я сходу ни в одном бандле, использующем базу данных, не видел миграций. получается, что миграция отдана на откуп вашему коду, бандлу-библиотеке, в общем-то, может и не нужно ничего об этом знать
Vlad
с помощью compilerPass
Konstantin
это дебильная довольно зависимость на ровном месте, вы лочите один бандл на другой
Konstantin
и если в проекте будет третья версия бандла миграции, версии могут разъехаться
Vlad
это дебильная довольно зависимость на ровном месте, вы лочите один бандл на другой
дебильно юзать AbstractController)) А тут мб кейс и норм
Konstantin
давай так, либо ты малолетний долбоёб и с тобой никто не разговаривает, либо нормально продолжаем
Vlad
ойой) я тебя не оскорблял если что)
Konstantin
мой пойнт в том, что лезть в кишки чужого бандла компайлер-пассом == жестко заложиться на его внутреннюю структуру, на его классы и структуру конфига. значит мы максимально жестко фиксируем что наш бандл зависит от доктримигрейшнс: 1.2.3, если в том проекте, куда ты подключаешь свой бандл ххх, стоит другая версия бандла миграций, у нас случается безвыходная ситуация: либо мы не ставим новый бандл ххх, либо принудительно обновляем бандл миграций. это херовая история, и это и называется "лишняя зависимость на пустом месте"
Konstantin
твой бандл вообще не должен знать какими миграциями пользуется проект, это не его забота. у одних это доктрин-мигрейшнс-бандл, у других - какой-то иной механизм. это странно настолько явно форсить что-либо у клиентов твоей библиотеки
Aleksander
скорее всего из коробки - никак, как-то интегрироваться с бандлом миграции самостоятельно. но мне кажется, что в бандле миграциям не место
так то бы да, но тогда другой вопрос: как быть если нужен кастомный SQL. его куда? например какой то кастомный генератор идентификаторов(требущий доп. sql кода)... подозреваю что лучше как то это реализовывать пхп-шными расширениями и дополнениями к модели и там заворачивать весь доп. sql, но не знаю есть ли такое
Konstantin
справедливо, да