Привет! Есть задача валидировать вложенные объеты, пытаюсь разобраться, как это корректно

сделать.

Допустим, имеем запрос вида:
{
"task": {
...
"owner": {
"id": 1231233,
"name": "Mark"
},
"field123": 123,
"field122": 124,
"responsible": {
"id": 1231,
"name": "Joe"
},
...
}
}

Сейчас правила для валидатора выглядят вот так:
public function rules(): array
{
return [
...
"task.owner.id" => 'numeric',
"task.owner.name" => 'string',
"task.responsible.id" => 'numeric',
"task.responsible.name" => 'string',
...
];
}

А по ощущениям, хочется что-то такое
public function rules(): array
{
return [
...
"task.owner" => new Rule([
"id" => "numeric",
"name" => "string"
]),
"task.responsible" => new Rule([
"id" => "numeric",
"name" => "string"
]),
...
];
}

С последующими наследованиями и тд.
Есть ли базовый функционал, который в такое умеет? Как такое правильно сделать?

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

О наследованиях в классах валидации забудь вообще)

Я в них все еще верю.. Чуть чуть Потому что писать для сложных объектов полотна дублирующее - какая то шляпа

Зря веришь, наследовать форм реквесты низя. Если проект будет расти, будет много чего расширяться, и в один момент начнутся проблемы с валидациями:)

Что по поводу ощущений, так они ошибочны, когда пишешь task.owner.id - это называется точечная нотация, и она удобна

Я понимаю, что такое точечная нотация Но проблема в том, что таких объектов может быть ОЧЕНЬ много. Сейчас типичное правило для валидации расползается на 100-150 строк с кучей дублей. Глобальная цель - решить дублирование.

В точечной нотации можно ставить * как символ прохода по массиву Может нужно поставить так логику, чтобы было много tasks.*.owner.id

Внешнее апи, которое отправляет запросы. Там идут вперемешку, в зависимости от названия поля разные объекты. И пользователи, и проекты, и ссылки и тд. Тут момент, что нужно именно кастомные блоки валидации вот такие.

Рекомендовал бы у себя переписать как нужно, с помощью одного пакета дто https://github.com/WendellAdriel/laravel-validated-dto Передаешь сколько хочешь параметров, и в методе mapBeforeValidation пишешь свои имена

Прикольный пакет, возьму на заметку) А как вы рекомендуете переписать такое? Когда приходит task с кучей полей внутри, тип которых зависит от имени? Сразу совать в пакет без валидации на уровне запроса?

https://github.com/WendellAdriel/laravel-validated-dto#mapping-data-before-validation

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

как спрашивал здесь - можно забить на make:request, но в начале метода контроллера create/update весь $request кидать сразу в дто

то есть реквест в реквест классах уже не валидируется, а валидируется только внутри дто?

Валидируется, но зачем тебе валидация в двух местах

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

Ну тут удобность в плане прослойки дто, IDE ведь даёт подсказки при написании стрелочки Ты можешь в rules() класса дто, поставить всем атрибутам пустую строку, и делать валидацию на уровне форм реквестов

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

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

Это нужно тогда, когда запрос может прийти из реквеста, или артисан команды, или ещё откуда-то И уйти тоже куда там нужно Дто хранит определённый не изменяемый набор свойств, которые вызываешь в нужном местк

я так и написал)