symfony2 динамическая валидация формы с коллекцией, в зависимости от значения полей
К примеру у меня есть документ Post, который может быть как простым постом с коллекцией параграфов, так и постом-ссылкой. Пост может быть создан как ссылка и позже быть отредактированным, заполнившись оригинальным содержимым (параграфами, которые являются коллекцией)
Поля поста: title, is_external, external_url, paragraphs.
Параграф состоит из: title, description. Description обязателен к заполнению.
Как я могу валидировать значения из формы по следующим правилам:
Если is_external checked, external_url не может быть пустым, а paragraphs можно вообще не проверять. Иначе external_url должен быть пустым, коллекция paragraphs должна содержать хотя бы одну запись, все параграфы должны быть валидированы.
Да, я тоже так решил действовать. Написал колбек, который хорошо валидирует external_url, но с коллекцией paragraphs возникли проблемы.
Уперся в валидацию коллекции, в зависимости от поля. Не знаю, как вызвать валидатор глубже.
Один из хороших подходов — это создания собственного валидатора, который будет валидировать не свойство а, целлый класс. symfony.com/doc/current/cookbook/validation/custom_constraint.html Здесь плюс большой, что Вы его сможете потом при необходимости определить как сервис, и внедрить в него зависимости.
Также есть возможность обработать эту проверки на евенте FormEvents::SUBMIT (На >= 2.1 < 2.3 FormEvents::BIND), и если есть ошибка, то самому добавить ее addError(new FormError(/**… **/));
А зачем вам валидация формы? У вас должна быть валидация конечной модели.
И на мой взгляд было-бы правильнее разделить это на 2 cущности, а на выборке мержить эти сущности
Окей, подскажите тогда как валидировать динамически модель подобным образом.
Если вы имеете ввиду два разных класса, то такой вариант не подходит, т.к. переключить тип записи нужно «на лету», чекбоксом.
Документ Post должен быть один. У него, кроме описанных, есть еще 10 полей, которые ведут себя одинаково, независимо от is_external, кроме того для системы в целом is_external у Post не имеет никакого значения. Иметь 2 разных модели с 80% одинакового функционала противоречит DRY. Усложнять себе жизнь наследованием не хочется, т.к. повторюсь, обе сущности выполняют одну и ту же задачу. И с точки зрения бизнес логики is_external равносильно background color.
