И если ты ради этого устроил сыр бор - это отдельный вопрос...

Да если тебе не хватает встроенных констрейнтов - пиши кастомные валидаторы, ну блин

Да если тебе не хватает встроенных констрейнтов - пиши кастомные валидаторы, ну блин

Читай плс что написано

Простой пример: форма логина. На ней нельзя подписывать поля ошибками. Мол пароль не верен, или логин не верен. Надо значит вернуть просто список, или одну ошибку вообще.

Тут вообще должна быть ошибка {'auth'; 'auth error'} и к валидатору отношения не имеет, ни к логину, ни к паролю.

Тут вообще должна быть ошибка {'auth'; 'auth error'} и к валидатору отношения не имеет, ни к логину, ни к паролю.

На бек прилетает пара с логином и паролем, ответ содержит ошибку. Все просто же

Хотя тут и кей не нужен

И это самый простой пример

И это самый простой пример

Этот пример вообще не относится к вопросу/пролеме, так как это не ошибка первичной валидации.

На бек прилетает пара с логином и паролем, ответ содержит ошибку. Все просто же

Ну и в чём проблема вывести ошибку?

Этот пример вообще не относится к вопросу/пролеме, так как это не ошибка первичной валидации.

Причем тут первичная или нет? Я про первичную вообще ничего не говорил

Причем тут первичная или нет? Я про первичную вообще ничего не говорил

Потому что валидатор, и то что ты пытаешься сделать - это первичная валидация. А потом приводишь пример про аутентификацию, и говоришь что надо объединить что-то и обработать симфони валидатор

Я вообще не разделяю первичную не первичную.

Я вообще не разделяю первичную не первичную.

В этом и проблема наверное кроется

Надо проверить правильный ли логин пароль - взял и проверил, потом юзера авторизовал

У тебя есть ошибки валидации, а есть ошибки логики, проверки логики.

Нету, щас наговоришь

Надо проверить правильный ли логин пароль - взял и проверил, потом юзера авторизовал

Проверка логина/пароля никак не относитя к симфони валидатору и объединению. Не понял вообще к чему этот пример

Простой пример: форма логина. На ней нельзя подписывать поля ошибками. Мол пароль не верен, или логин не верен. Надо значит вернуть просто список, или одну ошибку вообще.

это значит, что проверяется пара полей и сообщение общее для формы это вопрос ux/ui

Да с чего ты решил то? По твоему валидатор в базу сходить не может?

Да с чего ты решил то? По твоему валидатор в базу сходить не может?

Совершенно верно

Точнее может, но это уже не первичная

Или доку почитай хотябы. Может.

Или доку почитай хотябы. Может.

Так мы продоку симфони или архитектуру?

Да с чего ты решил то? По твоему валидатор в базу сходить не может?

может, как и запретить доступ

может, как и запретить доступ

Ну я бы сказал что это не очень

валидатор - это название компонента он может чекать авторизацию

Это удобно но как то смазывается

Да с чего ты решил то? По твоему валидатор в базу сходить не может?

не ну это уже перебор, пацаны. не только может, но и имеет полное право. банальный пример - уник валидатор

как ты его сделаешь, не сходив в базу?

как ты его сделаешь, не сходив в базу?

Уник валидтор просрет в рейс кондишене)))

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

Уник валидтор просрет в рейс кондишене)))

это смотря как его делать

Проверка логина/пароля никак не относитя к симфони валидатору и объединению. Не понял вообще к чему этот пример

к симфони - нет. к валидации - да

это смотря как его делать

И как можно сделать, чтобы не просрать?

блокировку написать?

завести семафор, что вот, мол, с таким-то ключом записи не допускать

как конкретно - вариантов довольно много, ограничены фантазией

блокировку написать?

Т.е. мы идем в валидтор, делаем лок селект фор апдейт, потом делаем логику на 5 сек и нас все жлут 5 сек?

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

Т.е. мы идем в валидтор, делаем лок селект фор апдейт, потом делаем логику на 5 сек и нас все жлут 5 сек?

это кстати интерсный вопрос от Павла

Технически в валидатор (констрейнт) ДТО хоть регистрацию можно запихать, но это скрыто, я за максимальную прозрачность.

Технически в валидатор (констрейнт) ДТО хоть регистрацию можно запихать, но это скрыто, я за максимальную прозрачность.

Какого хрена тебе валидация запроса должна делать лок, ну скажи

Технически в валидатор (констрейнт) ДТО хоть регистрацию можно запихать, но это скрыто, я за максимальную прозрачность.

не, регистрация - это действие вот что точно не стоит запихивать туда, так это действие

Какого хрена тебе валидация запроса должна делать лок, ну скажи

Ну вот я про это.

Совершенно верно

Ну вот смотри. Юзер отправляет логин пароль. Далее, если такой юзер существует и пароль ему соответствует выдаётся токен. Через специальный объект. Задачи проверять пару у выписывателя токена нету. Его задача выдать токен и все. Какую альтернативу предложишь в этой схеме?

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

не, регистрация - это действие вот что точно не стоит запихивать туда, так это действие

Сходить в бд - тоже некое действие. Ну короче топить не буду, но мне не нравится пихать в валидацию работу с базой.

Т.е. мы идем в валидтор, делаем лок селект фор апдейт, потом делаем логику на 5 сек и нас все жлут 5 сек?

не все, а только по этому ключу. то есть тот, кто пишет в эту таблицу, теперь тоже проверяет этот лок. выглядит мутновато, да, но если логика того требует, куда деваться-то? не все системы позволяют иметь несколько записей с одним ключом и ждать какого-то компакшна (какая-нибудь транзакция, например). но тебе об этом надо сообщить в форме/апишке, где там у тебя валидатор

Сходить в бд - тоже некое действие. Ну короче топить не буду, но мне не нравится пихать в валидацию работу с базой.

а сходить в конфиг? действие - это действие

а сходить в конфиг? действие - это действие

Зачем идти в конфиг? Короче я за то, что первичная валидация - это минимум.

Остальное - уже ближе к логике идет

можно сколько угодно теоретизировать про "должен/не должен", но честно говоря твои аргументы слабоваты. валидаторы имеют полное право обращаться в внешним источникам. у меня вон есть валидаторы в компании (мы работаем на рынке приватности твоих данных), которые проверяют при регистрации, не юзаешь ли ты скомпрометированный пароль, делая запрос к haveibeenpwned.com

не особо понятно кто, если не валидатор, должен сказать "нет, бро, 123456 пароль не лучший, давай другой"

можно сколько угодно теоретизировать про "должен/не должен", но честно говоря твои аргументы слабоваты. валидаторы имеют полное право обращаться в внешним источникам. у меня вон есть валидаторы в компании (мы работаем на рынке приватности твоих данных), которые проверяют при регистрации, не юзаешь ли ты скомпрометированный пароль, делая запрос к haveibeenpwned.com

Ага, только это ближе к БЛ и я заалкаю такое явно, а не в дтошку и под валидацию

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

^ сходив в пять баз и справочников

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

валидация но не первичная, это скорее набор бизнес рулов

нет никакой первичной и вторичной валидации

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

валидация но не первичная, это скорее набор бизнес рулов

тогда первичная валидация - это просто json распаковывается

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

Да, но клиенту доверять нельзя)

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

хотя конечно отличается немного

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

Ладно, ок. В чем разница между проверкой одного конфига, справочника, или например 10, которые асинхронные, возможно под сагой и потом конпенсаций? Где у вас грань между валидацией и безнес рулом?

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

Ладно, ок. В чем разница между проверкой одного конфига, справочника, или например 10, которые асинхронные, возможно под сагой и потом конпенсаций? Где у вас грань между валидацией и безнес рулом?

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

поэтому бизнесрул - это вообще хз что

поэтому бизнесрул - это вообще хз что

Т.е. любая проверка - это валидация?

То что баланс не может быть меньше 0, но если есть кредитный лимит то все же может ? Это тоже валидация?

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

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

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

а некоторые реализуют валидаторы так, что возвращается толь первая ошибка. Заполнены 5 полей, все некорректно - ошибка по первому полю. Юзер исправляет. Ошибка по второму полю. И т.д.

За такое убивать можно

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

Ну потому что по мне, то что надо проверить в БД - это уже некая логика, а не просто валидация.

тебе надо это в формочке отобразить

а некоторые реализуют валидаторы так, что возвращается толь первая ошибка. Заполнены 5 полей, все некорректно - ошибка по первому полю. Юзер исправляет. Ошибка по второму полю. И т.д.

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

"вы не можете юзать этот инн, у вас тут задолженность и делопроизводство"

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

С симфой всё норм кста

"вы не можете юзать этот инн, у вас тут задолженность и делопроизводство"

Вот это валидация в дто или нет?