Спор

У меня сложился спор с одним человеком по поводу валидации форм, помогите понять кто прав. Есть 2 варианта реализации, оба ajax

1) Простая клиентская форма которая отправляет данные на сервер, сервер в свою очередь проверяет каждое поле и возвращает ошибки по очереди, ну например если не правильно заполнены 3 поля то покажет только про первое, затем когда исправят первое, покажет про второе и т.д.

2) Валидация формы регулярками на js, дальше на сервере валидация такими же регулярками но в случае не совпадении с чем-то просто делать return из метода, то есть при плохих данных сервер не вернёт ошибку, а просто вернёт пустоту.

Важно мнение каждого, и желательно обосновать почему именно так

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

3) Во-первых, валидация на JS с рюшечками и интерактивом. Делается для пользователя
Во-вторых, полновесная серверная валидация с проверкой полей, возвратом читаемых пользователем ошибок. Разумеется, ошибок для всех полей сразу. С расстановкой ошибок напротив или рядом непосредственно с полями ввода и примером, как писать надо.
Над формой одним списком - гораздо хуже, но можно.

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

-----
PostgreSQL DBA

В п1 подразумевается серверная валидация и вывод всплывающего окошка где-то в углу и описание ошибки.

Это не входило в п2 из-за сокращения кода, т.к. полей около 10.

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

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

Так это не дает защиты при внесении данных в бд на сервере. js валидацию банально можно отключить вручную и отправить форму.

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

(Отредактировано автором: 15 Мая, 2014 - 14:39:50)

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

3 вариант

3 вариант который предложил мелкий это типа смесь первого и второго, и на клиенте проверяем, и с сервера ошибки возвращаем, но зачем? Зачем возвращать ошибки с сервера если клиент и сам про них знает и уже скорее всего вывел (кроме случаев проверки данных в бд)?

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

OrmaJever, на случай если вдруг забыли "синхронизировать" все проверки на клиенте и сервере(к примеру: забыли на клиенте проверку для максимального значения нового поля).
Да и лучше давать хоть какой-то ответ со списком ошибок, чем ничего не возвращать с сервера.

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

таким образом объединяется клиентская и серверная часть (кто-то может возмутиться что мы шлем много запросов, но в распространенных случаях на небольших проектах и/или формах которые предполагается слать не так часто этот вариант работает)

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

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

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

-----
Just do it