ааа, но мне это еще ни о чем не говорит, слышал краем ухо про sylius, но не более :)

тут главное направление, а не скорость перемещения

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

Ребят, один вопрос... Есть кастомный ParamConverter, он нужен только в одном контроллере. Насколько понимаю его можно запускать по * @CF\ParamConverter("customConverter", converter="customconverter_converter") Но никак не могу врубиться, каким образом его отключить для запуска во всех остальных местах? Т.е. сделать чтобы его вызов был только тогда когда он нужен, а не всегда.

ага, т.е. это таки единственный вариант? )

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

сахарок же, не более

у меня есть json-ки в реквестах с 20-ю полями, или коллекция объектов

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

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

ну и мэппинг данных на DTO это нифига не "бизнес" логика

это презентационная логика

ей место в контроллерах

или слое контроллера

HTTP -> DTO - презентационная логика DTO -> Application - бизнес логика

+1

HttpRequest дальше контроллера не стоит пускать

сча придет манагер/заказчик и скажет что дедлайн был час назад :P

сча придет манагер/заказчик и скажет что дедлайн был час назад :P

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

средненько

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

им никто не будет пользоваться!

и у меня плохо с фантазией

и я уже начал писать

на следующих выходных запланировал посидеть, написать тесты и запушить костяк

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

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

не превращай свой проект в CMS

не используй FOS REST если только он не содержит 100% того функционала который тебе надо

если надо быстро нахерачить админку - то норм

но опять же для таких проектов проще взять firebase и не писать ни строчки кода

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

https://www.youtube.com/watch?v=GRr4xeMn1uU

там есть где-то версия этого же даклада для менеджеров

документация firebase?

и незабудь проштудировать документацию к APNS

и запомни что строки вида "не рекомендуется" там надо воспринимать как "мы тебя забаним за это на пару минуток"

а еще лучше - у тебя должен быть ios/android разработчик под боком

который сможет тебе помоч

сразу скажу - самый частый косяк с пушами - факапы с сертификатами

аля "перепутали", "не так сгенерили"