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

[Sad Spirit]

Автор оригинала: Lifeline
Причем между проектами копируется этот явный и наглядный код,

Упасть и не встать от явности и наглядности. А список возможных ключей в массиве у тебя распечатан на лист A3 и пришпилен к стене?

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

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

 

[tf]

почитал даты

 

[WP]

Bermuda
А где здесь вообще может быть баг? Это лишь один из вариантов, мнений.

 

[ONK]

Я уже как-то высказывался по подобному вопросу. Было это уже давно, но с тех пор я только убедился в относительной (не буду на 100% категоричным) правильности такого подхода.

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

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

 

[Sad Spirit]

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

П---ц.

Библиотеки --- плохо, копи-паст --- хорошо.
Библиотеки --- плохо, копи-паст --- хорошо.
Библиотеки --- плохо, копи-паст --- хорошо.
Библиотеки --- плохо, копи-паст --- хорошо.

Пора переходить с недоязыка PHP на что-то другое, а то уже начинают смеяться и пальцем показывать.

 

[WP]

Хороший язык. А библиотеки и правда плохо.

 

[zerkms]

WP
чем? quicky тоже плохо да?

по теме: из поста ONK соглашусь лишь с тем что генератор формы и валидатор на практике удобно отделять. про копипаст - ЛОЛ

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

по сему - имхо напрашивается решением набор хелперов для работы с ними в шаблоне и генерации формы + набор валидаторов для проверки данных

 

[Sad Spirit]

Автор оригинала: zerkms
Sad Spirit
раз уж ты здесь - генерация форм из пхп тоже несёт негативные последствия - например перенос отображения в код. имею ввиду указание стилей и прочих вещей в пхп - хотя логичнее это было бы делать в шаблоне. (в qf было так, про qf2 не знаю)

по сему - имхо напрашивается решением набор хелперов для работы с ними в шаблоне и генерации формы + набор валидаторов для проверки данных

Это уже другой вопрос, более интересный.

Идея на данный момент следующая: имеем на входе обычный html, в коем форма с кучей полей. html обрабатывается специально обученным скриптом, на выходе PHP-скрипт с набором

$form->addElement(...);

и html, в котором поля формы заменены чем-то типа

<?php echo $form->getElementById(...); ?>

Соответственно программист вообще может не интересоваться внешним видом формы, имея только список полей, а дизайнер --- проверками её правильности.

Ну естественно это всё ещё написать надо...

 

[zerkms]

<?php echo $form->getElementById(...); ?>

смотрится страшно, особенно если представить что в качестве шаблонайзера мб тот же смарти
всё таки мне после некоторого времени работы с хелперами - кажется что они всё таки гораздо более гибкие

 

[Sad Spirit]

Автор оригинала: zerkms
смотрится страшно, особенно если представить что в качестве шаблонайзера мб тот же смарти

Никто, в сущности, не мешает выплёвывать и шаблон для Смарти. Это уже частности.

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

 

[zerkms]

Sad Spirit
хм, интересно будет посмотреть на реализацию этого всего та же философия qf1 была явно не совсем удобной в этом плане

 

[ONK]

Sad Spirit, не надо столько экспресии

Нужные библиотеки это хорошо. Хорошо в квадрате, если они хорошие.

copy->paste тоже хорошо, особенно если аккуратно и с умом. Экономит время на написание кода, позволяет сократить время на отладку и исключить кучу ошибок.

Ты прям как ребёнок, разглядел паттерн copy->paste, вспомнил, что про него только плохое говорят, и сразу плакать. При этом, если внимательно посмотришь за процессом своей работы, то увидишь, что больше 50% кода получается именно в результате этого не хитрого набора операций.

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

 

[Sad Spirit]

Автор оригинала: ONK
copy->paste тоже хорошо, особенно если аккуратно и с умом. Экономит время на написание кода, позволяет сократить время на отладку и исключить кучу ошибок.

Ты прям как ребёнок, разглядел паттерн copy->paste, вспомнил, что про него только плохое говорят, и сразу плакать.

Из вышеприведённого я согласен только с "экономит время", а вот сколько трудноотлавливаемых ошибок я сам наделал методом copy-paste, в том числе и из-за того, что (см. выше) забывал "просто исправить имена переменных"... Ээх.

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

 

[ONK]

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

 

[WP]

Это выдуманная проблема. Если человек страдает невнимательностью, ошибки сможет лепить где угодно.

 

[dark-demon]

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

 

[ONK]

dark-demon, я использую динамическое формирование форм на стороне клиента (в чате) и не понимаю, как скрипт может "не знать". Если логика приложения предпологает отпраку серверу каких-то данных, то это автоматически предполагает знание серверной частью способа их обработки. В любом случае, есть некое соглашение обмена данными, которое должно выполняться обеими сторонами.

WP, согласен, я например редко могу написать больше 3-х строчек кода без единой ошибки. Хорошо если эта ошибка вылезет на стадии парсировки или в виде варнинга, куда хуже если это будут теже имена элементов форм. Именно по этому я и говорю, что применяя copy->paste я сокращаю количество ошибок, время разработки и отладки.

 

[Sad Spirit]

Автор оригинала: dark-demon
тут никто не упомянул о такой фиче, как динамическое генерирование форм на стороне клиента. тобишь серверный скрипт не может заранее знать какие именно поля к нему придут. а при хорошей юзабилити почти все формы будут динамическими :-ъ
как на тех же QF реализуется формирование вариантов ответа для опроса?

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

Что касается QF, то для старой версии есть элементы типа repeat (сам использую в админке), но, к сожалению, они слишком большой хак и не могут быть добавлены в основной пакет. За новую версию пока говорить не готов, но уже сделанные изменения в архитектуре позволят избавиться от половины грязных хаков.

 

[jonjonson]

Гы

Нео, формы нет! (С) httpxhtmlcssphpjavascriptматрица

Точнее есть нечто в браузере. На сервер же приходит http запрос в котором нет формы. А раз нет формы, то её нельзя валидировать.

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

Низкий и тупой способ абстракции - это строить модель данных на основе отображения в браузере. Другой способ - это строить её как правильно и отображать как нужно. Первый - это, например, работа с формами. Второй, например, работа с пользователями, их акаунтами и т. д.

Единственное место правильной валидации формы - это браузер. Есть форма - есть и валидация.

Мы же на сервере, и значит формы нет. Есть request. Форма не может дать больше для Модели, чем реквест и её искусственное создание до отображения может иметь только один смысл. Этот смысл в связать её с моделью для получения из модели данных, но никак не предоставления этих данных самой Модели и валидации их перед этим. И лучше самой модели никто не разбирается в данных.

И ещё. Да можно и нужно писать валидаторы, но как рефакторинг. А значит стоит начинать с if. У вас точно накопиться набор чего-то своего универсального. Вопрос в другом, нужно ли это другим? И стоит ли из этого делать фетиш?

 

[Фанат]

И ещё. Да можно и нужно писать валидаторы, но как рефакторинг. А значит стоит начинать с if. У вас точно накопится набор чего-то своего универсального. Вопрос в другом, нужно ли это другим? И стоит ли из этого делать фетиш?

распечатаю и на стенку повешу.

-~{}~ 02.05.07 09:25:

Хотя, конечно, такие проекты, как QF - это, как раз, следующий виток того самого рефакторинга, когда "набор чего-то универсального" начинает быть "своим" уже для нескольких человек.
Другое дело, что зи этого получается другая засада, о которой я все время говорю - каждый "шишок" к общему дому хоть одно бревно - да прикатит. И в результате получается вещь, в сто раз большая по размеру, чем та форма, вместе с фалидатором, которую надо обработать...