контроллер должен быть туп как пробка. Данные получил - передал кому то. Кто то обработал - выдал ответ. Контроллер соотвествующий ответ выдал клиенту.

Вот только никакой сложной логики не должно быть в контроллере. В сервисе.

ну это само собой

у меня в этой ситуации контроллеры занимаются тем, что создают формы, хендлят их и кидаются командами в шину

и все равно на 25 методов почти косарь строк

(писал не я, проект пришел от другой компании)

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

какие есть нестандартные сценарии?

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

поддержка scope у них очень странная (перепутал с fos_oauth, сорян)

какие есть нестандартные сценарии?

ну когда у тебя не круд например)

о, расскажи нам)

вообще fos rest это совокупность отдельные местами ущербных местами неплохих решений. я довольно долго его юзал тупо для конвертации эксепшенов в http статус коды например)

но из подход к валидации запросов мне честно говоря противен

ты кстати собираешься дописывать свои request objects? я может вкачусь в опенсорс, была идея приделать к ним на изоленту json schema

я хз пока если честно

я думал сделать чуть умнее

типа.... возможность описать схему запросов и ответов

и валидировать симфони валидатором... но можно конечно и через json schema

ну мол у меня валяются валидаторы типа anyOf, allOf и т.д.

ну мол идея в том что мои request objects должны только валидацией заведовать - а мэппинг на всякие там DTO - делай через argument resolver-ы

это намного более удобно и просто

/** @RequestRules(RegisterUserRequestRules::class) */ public function registerUser(RegisterUser $command) { }

что думаешь?

ну мол идея в том что мои request objects должны только валидацией заведовать - а мэппинг на всякие там DTO - делай через argument resolver-ы

поговорим про геттеры и сеттеры

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

поговорим про геттеры и сеттеры

Ой все

а я такой "а зачем вам геттеры и сеттеры вообще"

ну и крч срач

а я такой "а зачем вам геттеры и сеттеры вообще"

у них есть типы и есть final, им не нужны геттеры и сеттеры вообще

а вот в php такой роскоши нет, можно с phpdoc конечно обойтись но некоторым этого мало

вот и вся разница

главный аргумент шо в геттеры и сеттеры можно засунуть логику

ну и крч срач

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

главный аргумент шо в геттеры и сеттеры можно засунуть логику

норм, а потом их можно переименовать в нормальные методы, и засунуть еще больше логики и вжух у нас уже ООП

главный аргумент шо в геттеры и сеттеры можно засунуть логику

а это аргумент "за" или "против"?

за

ужасы какие

ой да ладно, процедурщина не так страшна

что думаешь?

сорри, отходил

как плохое ООП и миллиардами абстрактных фабрик и десятками зависимостей)

про аргумент резолверы тоже думал

про аргумент резолверы тоже думал

без allOf или anyOf сложно композицию правил мутить

норм, а потом их можно переименовать в нормальные методы, и засунуть еще больше логики и вжух у нас уже ООП

ну тут я скорее согласен с этим. если я дергаю условный setPassword, я жду, что он просто подставит значение в поле password и всё на этом. если там есть какая-то логика, типа "обновить еще пару полей, поставить куда-нибудь какой-нибудь флаг и вот это всё", то почему это не updateCredentials и зачем вам тогда вообще обычные сеттеры?

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

но в json schema есть, видел

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

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

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

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

вот по этому я симфони валидатор хочу юзать - просто, удобно

вот по этому я симфони валидатор хочу юзать - просто, удобно

и неизоморфно)

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

в php - либо геттеры либо @readonly + статический анализ.

это просто лично мой гемор - из-за "фуллстечности" моей

и неизоморфно)

кто тебе мешает дампнуть из правил валидации симфони json схему?

были бы фронтендеры - пилили бы сами себе валидацию по спеке какой-то текстовой?

кто тебе мешает дампнуть из правил валидации симфони json схему?

такое уже есть? или самому запилить?

такое уже есть? или самому запилить?

не уверен что есть, но и не уверен что нет)

в эту сторону тоже думал, кстати

ну сходу не нашел, но написать такое вообще не проблема

вечер работы

чуть запарно с точки зрения соответствия реализаций

чуть запарно с точки зрения соответствия реализаций

?

ну в смысле, если ты выплевываешь все согласно спеке - какие могут быть притензии?

не уверен, что symfony validation constraints соответствуют спеке json schema

не уверен, что symfony validation constraints соответствуют спеке json schema

я не уверен что все валидаторы симфони умеет json схема. Например range.

но это не значит что тебе не нужен range)

хотя там есть minValue и maxValue

range умеет)

вотвот

ERROR: S client not available

да

ну то есть я пока не вижу проблем

сходу...

драфт7 весьма хорош, я в нем не видел особых провисонов

только если кастомные валидаторы

Liform и FormTypeGuesserInterface

такое уже есть? или самому запилить?

не уверен что есть, но и не уверен что нет)

сейчас такое пилю

в какой-то из php либ есть разбежность между логикой валидатора и спекой json schema

по типу правило "string" валидируется даже на пустую строку по спеке и не валидируется либой

сейчас такое пилю

symfony validation -> json schema?

в первую итерацию form+validation -> schema

форм наоборот избегаю)

а form зачем?

много кода в них написано

т.к. это как фос :D

ну то есть... как оно с json schema соотносится? типа из структуры формы забираешь типы?

переносим с меньшей болью

более того

по схеме строится вообще форма

такая либа есть и не одна

да. В валидации могло быть недостаточно информации

т. к. через формы работали

понял

по схеме строится вообще форма

это искал, не нашёл для symfony. Для реакта да - есть

а, из symfony форм?

из форм есть одна - liform

но немного мало функционала

вроде что-то еще видел

но не искал, я по vue

/** @RequestRules(RegisterUserRequestRules::class) */ public function registerUser(RegisterUser $command) { }

а вот такое - чем руководствуешься, когда делишь?