Меню
Что нового?

Класс Валидатор

iceman

говнокодер
Назрела необходимость в создание отдельных классов валидаторов.

Посмотрел реализации в ZF2.

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

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

Но теперь нужны сложные валидаторы

Имена классов думаю хранить в таблице и порядок их исполнения (приоритет). Но в коде придется делать абстрактный класс валидатор (с фабричным методом), который бы по имени класса создаст мне нужный объект (дочерний) валидатор. Но ограничен я буду абстрактными методами родительского класса, что мне не нравится. А как передавать внешние данные валидатору - х3, формат разрабатывать придется?

Как бы это унифицировать, но чтобы в будущем все не перелопачивать?
 

Dez

Новичок
Нужный класс хранишь как строку. Аутолоадер по требованию подгрузит.
Параметры можно хранить тоже отдельно, а объект валидатора настроить ими через сеттеры, как в yii сделано. (в цикле присваиваешь "св-ва")
 

iceman

говнокодер
Dez
это понятно, параметры можно передавать на вход в виде массива.

Но как админам ведь при настройке вывода самим нужно будет выставлять параметры.
например, подключают Валидатор LENGTH - соответственно валидатор требует параметры min и max, ведь админу надо будет нарисовать форму, где именно для этого валидатора отобразятся 2 поля - где он их заполнит, для других валидаторов возможно совсем другие поля, а еще валидировать надо что ввел сам админ.
могу хранить это все в xml в одном столбце для каждого валидатора (VALIDATOR_NAME=>PARAMS) - в админке парсится xml и рендерятся нужные поля - админ заполняет, соответсвенно xml меняется и сохраняется с данными.
 

Dez

Новичок
Ого го интерфейс. Даже в друпале такое не всегда реализовано..
Для некоего типа валидатора определить конфиг из которого построится форма, настраивающая этот валидатор, мне кажется выполнимым решением.
 

kkn1960

Новичок
iceman

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

Сейчас для ввода параметров валидатора у меня используется только два поля:

- тип параметра (radio)
- сами параметры (textarea)

Типом параметра может быть:
- строка
-элемент ввода
-константа
-массив

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

Массив нужен для ввода нескольких параметров, например, минимального и максимального значения для проверяемого поля

Тип константа мне понадобился для проверки значений с помощью PHP фильтров

Все остальные параметры относятся к типу Строка
 
Войдите или зарегистрируйтесь для ответа.
Сверху