Она кастится к int, разве нет?

да, к int. а потом уже проходит валидация что 0 это int. а в реквесте пришло может вообще "0drf34343dfdsf"

По идее в форме все строками должно быть

Зачем ставить int на свойство и хотеть обработать ситуацию с 0drf34343dfdsf?

ну я откуда знаю что мне прийдет в post-e

если это строка не прошла валидацию - мне надо об этом сказать.

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

Ты хочешь иметь валидацию типа?

Все правильно, сначала наполняем модель, а потом валидируем

Вообще без типов делай свойства и норм.

🙂

И без валидации 🙂

Ну норм же - свойства mixed - прилетает все что угодно, а потом уже валидируем

8ка ругается, You must specify the type hint for "amount" property in ... даже без strict_types . сделал пока string все. в геттерах кастую к нужному типу. они явно вызовутся после валидации.

ну просто, хм.. может сначала валидировать то что пришло. а уже потом заполнять форм-модель уже правильными данными?

не, я вообще не претендую на правильность.. у меня тест просто упал не  стой ошибкой ,что предполагалась. он попытался аккаунт с id 0 найти. хотя там была строка.

Сейчас в этом решении есть небольшая проблема:
1. Вызов формы выглядит так: $form->load($req) && $form->validate()
Валидация в принципе стоит в другом запросе
2. load может быть вызван без валидации и это нормальное поведение. То есть сюда кастомить "временное хранилище" не особо вариант

Если делать $form->validate($req) && $form->load($req), то будет уже лучше. Но я пытался отказаться от сервиса в формах и запилил PR на $validator->validate($form). Поэтому либо кастомить load, либо придумывать новый flow для работы с формами.

Создай issue с примерами твоих форм и твоего флоу. Подумаем, какое решение можно будет сделать.

надо подумать. про $validator->validate -  я помню . это вроде хорошо.