Проверка как свойство формы

Question

В платформе CakePHP правила валидации являются свойством модели. То есть не имеет значения, откуда поступают данные: когда вы хотите записать их в модель, они должны будут пройти проверку.

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

Я понимаю, что это может быть иногда полезно, и действительно, CakePHP предоставляет методы для определения различных правил проверки на лету, если вы хотите. Но это исключение, а не правило. Мне кажется, что разработка другого способа открывает дверь для ошибок, когда вы обновляете свои правила проверки, но забыли проверить все формы.

С другой стороны, я уверен, что Фабьен Потенциер умнее меня и, вероятно, задумался над этим дизайном. Итак, мой вопрос:

Каковы веские причины для проверки по форме (как правило, а не в качестве исключения)?

Answer 1

Я бы сказал, что это две разные вещи.

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

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

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

Конечно, используя CakePHP, вы достаточно легко можете написать комбо-компонент компонента / поведения, который работает с обоими сценариями, используя ключевые индексы в массиве проверки. Достаточно просто установить ключ «по умолчанию», который используется всегда, и ключ для каждого «действия», определяющий дополнительную логику проверки.

Есть даже несколько готовых решений, если вы немного погуглите.

Answer 2

Вы забыли о наследовании. Вот что я имею в виду:

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

У меня иногда есть разные правила проверки для каждой формы, например, для бэкэнда, для веб-интерфейса - даже если они имеют дело с одной и той же моделью. Основные правила исходят от автоматически сгенерированного класса, и я меняю несколько виджетов и валидаторов или удаляю несколько.

Answer 3

Насколько я знаю веские причины: 1. Мало форм.2. Формы с совершенно другой функциональностью.3. электронная почта может проходить разные проверки (для электронной почты при входе может потребоваться URL-адрес от email@thisSite.com, а электронные письма для регистрации могут поступать с любого домена).