Это хороший дизайн для проверки формы?

Question

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

Каждая форма (= объект) имеет один или несколько элементов FormElements (= объекты). Каждый FormElement может иметь 0-n FormValidators (= объекты). Все легко настраивается через бэкэнд (простой метод перетаскивания).

Когда представление формы отображается, оно проходит по всем элементам FormElements и для каждого из них проходит по всем связанным с ними FormValidators. Таким образом, он создает весь необходимый JavaScript для проверки формы на стороне клиента.

FormValidator - это легкий объект, который определяет только эти семь вещей:

• Имя класса PHP класса утилиты проверки
• имя метода класса утилиты проверки, который должен называться

• строка для дополнительных аргументов (значения через запятую)

• JavaScript "class" имя утилиты проверки

• имя "метода", которое должно называться

• строка для дополнительных аргументов (значения через запятую)

• связанный объект ErrorInfo, который содержит отформатированное сообщение об ошибке

Каждый из этих методов проверки принимает в качестве первого аргумента входную переменную с входными данными. Каждый из этих методов просто проверяет ввод, если он соответствует некоторым правилам и возвращает TRUE или FALSE.

Когда форма отправлена, FormDataManager создается и получает: - объект Form (чтобы он знал, откуда поступили данные) - входные данные (обычно $ _POST)

Затем он просто перебирает все FormElements, проверяет все их FormValidators и, если что-то недопустимо, перезагружает форму, которой передается массив сообщений об ошибках. Если все в порядке, данные подвергаются дальнейшей обработке (т.е. сохраняются в дБ).

Есть ли улучшения в этом дизайне? Что я пропустил?

Answer 1

Одна распространенная концепция проверки, которую, я думаю, вы пропустили, это группы проверки. Например, вы можете удовлетворить один из следующих сценариев:

• Поле B формы обязательно, только если в поле A есть какое-либо значение.
• Поле формы B является обязательным, только если поле A имеет конкретное значение.
• Поле формы B является обязательным, только если поле A находится в определенном диапазоне (числовое или даты).
• Любое поле A ИЛИ поле B должно иметь значение (они не могут быть оба пустыми).
• Любое поле A ИЛИ поле B должно иметь значение (оба они не могут быть пустыми или оба имеют значение) - (XOR).
• Пароль и поле подтверждения пароля должны быть равны.

И я уверен, что есть другие сценарии, в которых валидация зависит от валидности или необязательного аспекта других элементов формы. Кроме того, «обязательный» в приведенных выше сценариях также может быть просто «применимым», что снова будет другой ситуацией. Типичный (медицинская система) пример здесь: « Вы мужчина / женщина? », с последующим « Вы беременны? » для женщин. Или вопросы, связанные с AOP, когда у вас день рождения и у вас есть дополнительный вопрос только в том случае, если им 65 лет или больше.

Это означает, что вам нужна группа проверки или объект ассоциации проверки, который содержит эти зависимости полезным и универсальным способом.

Я предполагаю, что в вашем дизайне это означает, что вы также можете иметь объекты FormValidator, которые не связаны напрямую с одним FormElement, но с комбинацией FormElements и включают условную проверку перед запуском проверки.

Answer 2

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

Answer 3

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