PHP-валидатор полей формы (Form validator)

denver

?>Скриптер
PHP-валидатор полей формы (Form validator)

Подскажите плиз идею (или решение, или докажите отсутствие решения :)) такого валидатора полей формы чтоб форма задавалась одним махом (массив или еще как) без всякой PHP логики. HTML_QuickForm на мой взгляд не самое лучшее решение, хотя кажется расчитан на форму любой сложности. Не нравится мне куча методов (addField, AddGroup и т.п.) неужто нельзя форму со всеми валидаторами и дефолтными значениями задать одним массивом например?

Под формой высокой сложности я подразумеваю форму, проверка которой подразумевает не только проверку каждого поля
(например is_not_empty, is_valid_email и т.п.) , но и сложные проверки -- как, допустим, некое поле проверять на что-то только если другое поле равно определенному значению.

HTML здесь out of scope. Мне НЕ нужен генератор HTML, только лишь валидатор всех полей формы. Возможно с callback функцией парсинга ошибок, но необязательно.

Вобщем главное что хотелось бы видеть -- инициализацию формы попроще, но итуитивную и с поддержкой сложных проверок, что-то наподобие:
PHP:
$form = array(
	'name' => array()
	'email' => array(
		'default'     => '[email protected]',
		'validators' => 'is_not_empty, is_valid_email'
	)
	'password' => array(
		'phrase' => array(
			'validators' => 'is_not_empty',
		),
		'confirm' => array(
			'validators' => 'is_not_empty',
		)
		'validators' => 'is_equal',
	)
);

if (is_valid_form($form, $_POST, $errors)) {
    // do smth ...
} else foreach ($errors) {
    // parse errors ...
}
У кого какие назработки/ссылки, делитесь или натолкните на идею :)
 

WP

^_^
Чем не устраивает if? И массив ошибок. В любом случае удобнее извращений с массивами, callback-функциями и т.д.
 

Kirill

Новичок
как это сделано у меня на некоторых проектах:
$i++;
$page_array['fields'][$i]['db_field'] = 'is_offer';
$page_array['fields'][$i]['name'] = 'name'
$page_array['fields'][$i]['type'] = 'yesno_list';
$page_array['fields'][$i]['length'] = 1;
$page_array['fields'][$i]['change'] = true;
$page_array['fields'][$i]['binding'] = false;
$page_array['fields'][$i]['yesno_list'][0]['db_value'] = 0;
$page_array['fields'][$i]['yesno_list'][0]['text'] = 'no';
$page_array['fields'][$i]['yesno_list'][1]['db_value'] = 1;
$page_array['fields'][$i]['yesno_list'][1]['text'] = 'yes';

$i++;
$page_array['fields'][$i]['db_field'] = 'phone';
$page_array['fields'][$i]['name'] = 'name';
$page_array['fields'][$i]['type'] = 'text';
$page_array['fields'][$i]['length'] = 50;
$page_array['fields'][$i]['change'] = true;
$page_array['fields'][$i]['binding'] = false;

$i++;
$page_array['fields'][$i]['db_field'] = 'add_phone';
$page_array['fields'][$i]['name'] = 'name';
$page_array['fields'][$i]['type'] = 'text';
$page_array['fields'][$i]['length'] = 50;
$page_array['fields'][$i]['change'] = true;
$page_array['fields'][$i]['binding'] = false;

Только значения берутся из базы ('db_field).
У полей, которые надо проверять по особому, дописываю параметр
$page_array['fields'][$i]['check_function'] = 'function_name'; -тогда проверять будет поле заданная функция (её лучше выносить в дочерний класс).
Всего не предусмотришь, пытался раньше писать валидаторы на все случаи жизни - писать можно много и долго, а воспользоваться 1 раз. Вынесение проверки в доп функции, на мой взгляд, самый удобный вариант.
 

denver

?>Скриптер
WP
Чем не устраивает if? И массив ошибок. В любом случае удобнее извращений с массивами, callback-функциями и т.д.
Про колбэк я рановато сказал конечно. И идею что-то не до конца раскрыл :(

Да, с учетом вышенаписанного if сгодится вполне. Пример из гугла
PHP:
...
$submited = false;
$errors = array();
if (!empty($_POST)) {
	$submited  = true;
	if ($_POST['admin_password'] == '') {
		$errors[] = 'Administrator password cannot be empty.';
	}
	if ($_POST['admin_email'] == '') {
		$errors[] = 'Administrator email cannot be empty.';
	} else if (!eregi("^[a-z0-9\._-]+@+[a-z0-9\._-]+\.+[a-z]{2,6}$", $_POST['admin_email'])) {
		$errors[] = 'Administrator email is not valid.';
	}
...
После проверок еще нужно делать обычно следующие шаги (скажем, под FastTemplate):
1) для каждого поля, подставить данные из $_POST если есть в соответствующий атрибут value у соответствующий инпутов (если нет то подставить дефолтовое значение)
2) для каждого поля, в случае с ошибкой около ошибочного поля пропарсить блок
<!-- BEGIN admin_email_error -->
<div class="error">{ERROR_MSG}</div>
<!-- END admin_email_error -->
Если ошибки не было то наоборот, этот блок скрыть
3) Пропарсить самый главный блок с ошибкой который делает alert("пожалуйста исправьте ошибки")

В случае с XML+XSL разумеется действия не до такой степени тупые, но всё равно типичные и повторяющиеся.

Теперь предположим нужно создать форму с нуля, у которой штук 10 обязательных полей, неужто интересно писать такую if-программу?
С каждой новой формой, на каждом новом сайте, для каждого шаблонизатора -- один и тот же набор if-ов и действий.
И это еще более-менее простая форма, пример сложной формы -- какой-нибудь мастер составления визардов (хехе), с кучей взаимозависимых полей, груп и т.п. Без 4-5ти вложенных ifов и листинга немалого размера не обойдешься. А 5ти-вложенные ifы подобны пизанской башне, да и вообще, пять этажей всегда менее сейсмоустойчивей чем один-два :)

ЗЫ. колбэк я имел в виду как универсальное решение, для пропарсивания данных и ошибок под разные шаблонизаторы. Если универсальность не нужна, то и усложнять, понятно, не нужно.
Метод "if", конечно, самый универсальный, но и рутинный довольно.

-~{}~ 17.10.06 00:59:

Kirill
Всего не предусмотришь, пытался раньше писать валидаторы на все случаи жизни - писать можно много и долго, а воспользоваться 1 раз.
То что валидаторы пишутся всегда на один раз - это нормально и разумнее примириться с сим и даже не мечтать написать полный комплект проверок всего.

Подход у вас более-менее правильный, но... СОВСЕМ НЕ учтена взаимозависимость полей и проверок.
Проблема появится в этой строке:
$page_array['fields'][$i]['check_function'] = 'function_name';
когда вы будете писать функцию валидации на соответствие пароля его потдверждению.
Как проверить поле emial на !empty ТОЛЬКО когда стоит галочка subscribe. И т.д. и т.п.
 

Фанат

oncle terrible
Команда форума
Теперь предположим нужно создать форму с нуля, у которой штук 10 обязательных полей, неужто интересно писать такую if-программу?
ну конечно. гораздо интереснее написать такой же объём кода только вызова функций валидации, постоянно чертыхаясь на ограничения, накладываемые валидатором, в котором в результате появится метод вырезания гланд через задниу - вызова пользовательской функции нестандартной валидации.

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

-~{}~ 17.10.06 01:13:

Теперь предположим нужно создать форму с нуля, у которой штук 10 обязательных полей, неужто интересно писать такую if-программу?
я, составляя программу на языке пхп, решу проблему валидации 10 полей на обязательность одной строчкой.
Без того, чтобы заполнять безумные конфиги выставляя единичку для каждого поля.

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

denver

?>Скриптер
Фанат
Спасибо за неожиданно подробный ответ.

Для уточнения:
- Я НЕ за абсолютную абстракцию, а за золотую середину. Ведь череда if-ов это уж точно рудиментарный подход (потому что система там чувствуется), а HTML_QuickForm - лишь "видимость" комплексного решения.

- По поводу свободного PHP... Да, хаос -- свобода, а закономерность -- клетка. Но если удастся систематизировать без ущерба свободе, то почему бы и нет. Обрабатывать форму "по-старинке" уже просто скучно.
 

Фанат

oncle terrible
Команда форума
потому что система там чувствуется
я считаю, что это ложное ощущение.
Это только кажется, что там есть система.
А на самом деле, как раз те самые сложные взаимосвязанные проверки, о которых ты, как раз и говоришь - не формализуются.

Лично у меня ощущения противоположные.
И на основании собственного опыта я пришёл к тому, что велосипед получится гораздо более громоздким, чем ноги, которые он призван заменить.

Кстати, ещё к предыдущему твоему каменту у меня претензия была.
Непонятно, к чему ты приплёл три пункта, выделенные жирненьким. Совсем непонятно.
Хотя, приходит тут мне в голову, что я понимаю - к чему.
У тебя опять то же самое ложное ощущение. Одно и то же слово встречается в описании поля три раза - имя поля в хтмл, имя переменной в валуе и имя поля в сообщении об ошибке.
И у тебя появляется ощущение, что это можно оптимизнуть!
У меня тоже такое ощущение было.
Но потом я понял, что за эту оптимизацию я заплачу ТАКИМ геморроем, что цена будет несравнима.
и с тех пор пишу в хтмл шаблоне по три одинаковых слова на поле. скучно, ага.
Но зато форма у меня - это ОБЫЧНЫЙ шаблон, а не конструктор лего, в котором никто, кроме программера, не разберётся.
 

crocodile2u

http://vbolshov.org.ru
Лично я использовал QuickForm (до сих пор считаю QuickForm очень хорошим пакетом, который великолепно справляется со своими задачами). Однако, в последнее время отказываюсь от такого рода вещей, предпочитаю и формы рисовать руками, и проверять их также руками. Жизнь - очень сложная штука, и ограничения часто встают костью в горле. Да и подключать до 400 Кб кода библиотеки тоже не очень-то хорошо..
 

denver

?>Скриптер
Фанат
У тебя опять то же самое ложное ощущение. Одно и то же слово встречается в описании поля...
Хм.. возможно. Кроме того, согласен, что те три жирных пукнкта выше это что-то напдобие побочных функций в is_form_valid(), но именно эти три действия делаются всегда, и про них хочется забыть:
1) валидация поля
3) парсинг значения
2) парсинг ошибки

2й и 3й можно и не реализовывать. Только первый пункт у всех полей различен, но в нём то и загвоздка. Главная проблема, которая решается только if-ами: валидатор не всегда принадлежит конкретном полю, иногда он нужен для "группы" полей. Но я думаю, что если сложную форму записать "иерархически", то валидатор можно (если нужно) прописывать у каждого ветвления. Получается, что если нужно (очень редко конечно), то свой валидатор можно писать и у "основания" дерева формы, этот последний будет получать соответственно доступ ко всем полям формы.

Например, вместо "плоской" формы ответов на каком-ниюудь форуме. Было:

<form name="answer">
Поля:
1. subject
2. message
3. login
4. password
</form>

Строим иерархическую модель:
PHP:
1. "Форма"
(валидатор: сочетания тема + сообщения нет в БД)
    1.1. "тема"
    (валидатор: >3 символов)
    1.2. "сообщение"
    (валидатор: не пустое)
    1.3. "юзер"
    (валидатор: сочетание логин + пароль есть в БД)
        1.3.1. "логин"
        (валидатор: не пустой)
        1.3.2. "пароль"
        (валидатор: не пустой)
Стало:
1. answer[subject]
2. answer[message]
3. answer[user][login]
4. answer[user][password]

В итоге получаем чуть другие названия полей. Вроде ничего существенного, но добавилось пара "псевдополей" answer[user] (массив с логином и паролем) и answer (массив со всеми значениями формы). К этим псевдополям уже вешаем "надпроверки" как описано на схеме выше.

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

По-моему, система пока есть.
 

Фанат

oncle terrible
Команда форума
строй. свои иерархические модели.
хоть в 200 этажей.
и потом гордись ими.
 

texrdcom

Новичок
Фанат
Сколько ты написал строк за свою жизнь
тип isset($_POST[login]) === true
is_string($_POST[login]) === true
и так дальше ведь нужны даже такие елементарные проверки
для поля чтоб не вылетали ошибки - согласен ?
и тебе не жалко своих рук.

У людей правильная мысль похожий подход существует в java.

p/s
Конечно создавать конфиг для формы в 10 полей трудно - и нудно но и писать if или назначать классу валидатору обьекты
проверки - тоже не весело.

Потому проще написать веб интерфейс где и будут задваться
проверки для всех типов полей формы - всех громко сказанно
их аж 13 - если не ошибаюсь :)

Да не льзя написать унивирасальные проверки но можно всегда задать объект который сделает уникальную проверку
для нужного - поля. Причем в php это вобщем не проблема.

-~{}~ 19.10.06 01:26:

Фанат
20208 - постов я в шоке тебе наверное не трудно и не нудно писать :) ....
 

tf

крылья рулят
denver, ну а как насчет такое инициализаиции
$item_form->add_object('pos',array('type'=>'text','float'=>1));
$item_form->add_object('name',array('type'=>'textarea'));
$item_form->add_object('img1',array('type'=>'file','path'=>$upload_path));
помоему удобно
а насчет вложенных полей, думаю можно создать надстроку (проверку выходных данных отдельно)

-~{}~ 19.10.06 08:46:

а вообще вроде бы это уже обсуждалось http://phpclub.ru/talk/showthread.php?s=&threadid=58865&rand=48
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: denver
Подскажите плиз идею (или решение, или докажите отсутствие решения :)) такого валидатора полей формы чтоб форма задавалась одним махом (массив или еще как) без всякой PHP логики. HTML_QuickForm на мой взгляд не самое лучшее решение, хотя кажется расчитан на форму любой сложности. Не нравится мне куча методов (addField, AddGroup и т.п.) неужто нельзя форму со всеми валидаторами и дефолтными значениями задать одним массивом например?
А в чём прикол задания проверок массивом (структуру к-рого ещё надо помнить) против задания проверок методами, названия которых нормальные редакторы всё равно подсказывают, да ещё и PHPDoc для них услужливо выводят? ;)

-~{}~ 19.10.06 12:34:

Автор оригинала: crocodile2u
Лично я использовал QuickForm (до сих пор считаю QuickForm очень хорошим пакетом, который великолепно справляется со своими задачами). Однако, в последнее время отказываюсь от такого рода вещей, предпочитаю и формы рисовать руками, и проверять их также руками. Жизнь - очень сложная штука, и ограничения часто встают костью в горле. Да и подключать до 400 Кб кода библиотеки тоже не очень-то хорошо..
Ничаво, вот скоро допишем HTML_QuickForm2, будешь подключать 500 кб. :)

Вчера вот закоммитил элемент <select>, небольшая иллюстрация:
Код:
HTML_Common2
   |
   --HTML_QuickForm2_AbstractElement
      |
      --HTML_QuickForm2_Element
         |
         --HTML_QuickForm2_Element_Select


HTML_Common2
   |
   --HTML_QuickForm2_Element_Select_OptionContainer
      |
      --HTML_QuickForm2_Element_Select_Optgroup


RecursiveArrayIterator
   |
   --HTML_QuickForm2_Element_Select_OptionIterator
-~{}~ 19.10.06 13:03:

Автор оригинала: Фанат
ну конечно. гораздо интереснее написать такой же объём кода только вызова функций валидации, постоянно чертыхаясь на ограничения, накладываемые валидатором, в котором в результате появится метод вырезания гланд через задниу - вызова пользовательской функции нестандартной валидации.

По ходу, абсолютная абстракция - зло похлеще преждевременной оптимизации.
И точно так же бесполезно с ним бороться.
Фанат, ну ты же знаешь, что абстракция бывает двух видов
1) Хорошая: позволяет быстро и легко решать простые и частые задачи. При этом позволяет решать и сложные редкие задачи, хотя может быть и со всякими дополнительными ужимками и прыжками.
2) Плохая: позволяет быстро и легко решать задачи, которые авторам кажутся простыми и частыми. При этом сложные задачи решать либо невозможно, либо уж очень через ж@пу.

Писать if, конечно, веселей, чем addRule(), но когда ты пишешь в QuickForm'е addRule(..., 'required', ...), то у тебя уже есть
1) Пометка поля как обязательного к заполнению,
2) Вывод ошибки рядом с полем
3) Автоматическая генерация javascript'а для проверки на стороне клиента

Если начать вспоминать сколько if'ов понадобится для реализации всего этого без библиотеки, то повод задуматься таки есть.

Автор оригинала: denver
ожно и не реализовывать. Только первый пункт у всех полей различен, но в нём то и загвоздка. Главная проблема, которая решается только if-ами: валидатор не всегда принадлежит конкретном полю, иногда он нужен для "группы" полей. Но я думаю, что если сложную форму записать "иерархически", то валидатор можно (если нужно) прописывать у каждого ветвления. Получается, что если нужно (очень редко конечно), то свой валидатор можно писать и у "основания" дерева формы, этот последний будет получать соответственно доступ ко всем полям формы.
Неудачная идея, проще цеплять проверки друг к другу при помощи обёрток вокруг булевых операторов NOT, AND и OR.

С другой стороны, если бороться с объектами и вызовами методов при помощи массивов, то это будет представлять некую сложность. ;)
 

Phristen

Новичок
Объекты надо использовать.
Каждое поле формы превращается в объект, который заранее содержит все валидационные штучки: регулярное выражение, максимальную, и минимальную длину. В том-же файле создаётся массив этих полей (у меня их на весь сайт штук 30 вышло), и метод checkForm() :)

Типичный вызов выглядит так:
checkForm (МАССИВ_ОБЯЗАТЕЛЬНЫХ ПОЛЕЙ, МАССИВ_НЕОБЯЗАТЕЛЬНЫХ_ПОЛЕЙ, СЛОВАРЬ_СОВПАДАЮЩИХ_ПОЛЕЙ);

Если сайт не слишком сложный, то этого должно хватить. мне хватает :)
 

Lifeline

Новичок
Хотелось бы вернуться к теме.

Что сейчас актуально ? Желательно полный набор из фронтенд (с автоматической генерацией JS) и бэкенд работающий из того же конфига, желательно под смарти.

нашел как вариант
http://www.propagator.net/program/fore/formcat.php?part=docs
для фроненда

и
http://www.phpinsider.com/php/code/SmartyValidate/
для бэкнденда.

оба под смарти, но как-то не слаженно оно, в разных местах надо по несколько раз прописывать одно и тоже ..
 

WP

^_^
Как-то я уже затрагивал эту тему, но искать тот пост не хочу.

У многих возникает ощущение что если есть кучка похожего на глаз кода, то его можно (нужно) "оптимизировать" - т.е. привести к такому виду где некий вызов делается несколько раз, неся в себе условия для каждого из вариантов. Например
Код:
<img src="1.jpg" />
<img src="2.jpg" />
<img src="3.jpg" />
хотят заменить на
PHP:
<?php for ($i = 1, $i <= 3; $i++) {echo '<img src="'.$i.'.jpg" />
';} ?>
Но на примере Ассемблера можно видеть что несколько INC будут быстрее чем ADD. Да и вышеприведенный код будет производительнее чем цикличный аналог. Хотя, справедливости ради стоит упомянуть что изменять в ряде случаев его будет быстрее: например, убрать ' /'. Но, если нужно будет сделать изменение только части итераций цикла это повлечет геморрой с условиями, и в получившейся каше разберется только программист.
Если рассмотреть формализацию проверки форм, то станет ясно одно: можно сделать мета-механизм любой сложности, и он будет проверять любые формы используя callback'и, объекты полей, кучу всяких примочек, и т.д. Хотя в конечном счете будут все те же яйца, только сбоку, просто будет иллюзия абстракции. Хотя бОльшая абстракция подразумевает больше возможности безболезненной заменяемости частей программы. Но, естественно механизм (API) менять безболезненно для программы нельзя, но казалось бы можно использовать одну проверку в нескольких местах за счет валидатора, но на самом деле это можно делать и при if'ах, куда эффективнее. А валидатор менее производительный, и более громоздкий.
При этом я не отказываюсь от таких функций как например is_email(), они помогают мне при написании стандартных проверок. А для разрешения вопросов с генерацией HTML-форм я не использовал ублюдочных объектных генераторов, а пошел следующим образом: в шаблонизаторе я сделал теги {select}, {input} и прочие. Пишу {input type='text' name='string' value=$quicky.requeststring.string}, это компилируется в нужный PHP-код, и теперь при повторном показе формы в поле будет введенное значение, не нужно заботиться об htmlspecialchars и т.д. Некоторые могут меня обсудить, мол нельзя в шаблонах напрямую обращаться к $_REQUEST, но я практик, и считаю что программирование для человека, а не человек для программирования, и тогда когда это удобно можно пренебречь условностями. А для вывода ошибок по-моему достаточно массива $errors, который наполняется при выполнение условных блоков, и выводится шаблоном в цикле. По количеству кода, обращения в валидатору ничуть не меньше чем традиционный способ, ведь можно создать функции для частоиспользуемых проверок.
Так что ребята, предлагаю энергию по созданию валидаторов направить нужное русло :) Но это Imho (IмеюMнениеHренOспоришь)
Теперь перейдем в вопросам затронутым радиослушателями.
> Автоматическая генерация javascript'а для проверки на стороне клиента
{input type='text' name='test' pattern='/^[a-z]$/' onunmatch='alert("Неверно заполнено поле test"); this.focus()'}
Опять же Ваша "автоматическая" генерация не даст такой свободы изменения.
> Вывод ошибки рядом с полем
А какая проблема создать ассоциативный массив ошибок где ключи элементов это имена полей, а значения - текст ошибки? А потом в шаблоне проверять и подставлять. Верстальщики по голове не погладят за такие извращения с "автоматической" генерацией :)
И еще, блин, знаете что Long Horn требует 2 гб оперативы уже? Хотя не так уж давно был 95 с 32 мб оперативки. Т.е. теперь операционка кушает в 64 раза больше, хотя по сути в ней ничего не изменилось. А все потому что находятся программисты которым пофиг на ресурсы, и они поразитируют на хорошем железе, вместо того чтобы экономить каждый килобайт памяти.

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

-~{}~ 30.04.07 14:27:

А также стоит упомянуть о частой необходимости использовать внешние данные при проверки поля, например сравнить введенный E-Mail с тем который лежит в БД, или в переменной. А если делать callback то нужно делать класс, обращаться к его статическому свойству из callback... в общем обои через замочную скважину клеить.
 

Bermuda

Новичок
Некоторые могут меня обсудить, мол нельзя в шаблонах напрямую обращаться к $_REQUEST, но я практик, и считаю что программирование для человека, а не человек для программирования, и тогда когда это удобно можно пренебречь условностями.
Ага-ага, "это не бага, это фича такая".
 

Lifeline

Новичок
WP, сорри но аргументация сильно страдает. Я юзаю валидатор на стороне сервера

Вид примрено такой

PHP:
$profile = array(
      // array variables are not supported.
      'required' => array(
                     'required_var'
                  ),
      'optional' => array('optional_var',
         			    'action',
                   		'username',
                   		'new_user_name',
                   		'address_type',
                   		'email',
                   		'street',
                   		'city',
                   		'state',
                   		'zip',
                   		'move_node',
                   		'id',
                   		'pid'
                         ),
      'dependencies' => array(
                         // if key's value is a hash (named array), 
                         // dependencies are on the key's value, not it's name.
                                     
                         'action' => array(
                                        'new' => 'username',
                                        'rename' => array('username','new_user_name'),
                                        ),
                         'address_type' => array(
                                         'electronic' => 'email',
                                         'physical' => array('street',
                                                             'city',
                                                             'state',
                                                             'zip'
                                                             )
                                          ),
                          
                          // key's value is an array.  (key is an integer, not a string)
                          // dependencies are the array values 
                          
                          'username' => 'action',
                          'new_user_name' => array('action','username'),
                          'move_node' => array('id','pid'),
                          
                          ),
      'field_filters' => array(
                          'username'=>'alphanum',
                          'new_user_name'=>'alphanum',
                          'id'=>'pos_integer',
                          'pid'=>'pos_integer'
                          ),
      'constraints' => array(
                          'email'=>'email',
                          'zip'=>'zip',
                          'state'=>'state'
                          )
                 );
Юзается на ура. Причем между проектами копируется этот явный и наглядный код, который так же можно выносить в отдельный файл.

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

Lifeline

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