Javascript проверка полей формы
Все мы когда-нибудь заполняли формы. Кое-кто даже обрабатывал собранные ими результаты, будь то сделанные в интернет-магазине заказы, или обратка по сервису. Прося пользователя заполнить какую-либо информацию, мы хотим, чтобы она соответствовала определенному формату, особенно если в дальнешем она обрабатывается CMS вроде 1C bitrix, WorldPress, и так далее. Ведь если в графе телефон пользователь зачем-то запишет свой логин Skype, может возникнуть ошибка обработки данных: они не запишутся, и пользователя снова выбросит на страницу заполнения формы. Следовательно, возникает вопрос о том, как бы провести проверку введенных данных в режиме он-лайн и не допустить отправку некорректных данных.
Работу описываемого решения, разработанного нами, можно сразу оценить на примере процедуры оформления заказа на сайте компании "Ньюком". А ниже начнем повествование о процессе его разработки, а так же приведем еще несколько примеров.
Постановка задачиСделать простенькую javascript-проверку полей формы перед ее отправкой на сервер – дело пары минут. Только вот когда эту простенькую пишешь десятый раз для одного только сайта, невольно задумаешься об автоматизации этого процесса. В какой-то момент мысли об этом стали столь навязчивы, что пришлось сесть и накатать миниатюрную библиотеку, разбирающуюся с полями.
Если разбить задачу на блоки, то получится примерно следующая схема: Ну, если схема есть, то давайте уж ее реализуем.
Анализ вариантов проверок.- Текстовые инпуты, которые, как правило, проверяются либо просто на заполненность, либо на несложные регулярные выражения вроде email-а или телефона.
- Чекбоксы, проверяемые на наличие отметки (вроде соглашения на обработку личных данных).
- Можно упомянуть и выпадающие списки, проверяемые на какое-нибудь непустое значение.
- Не стоит забывать и о коварных радиокнопках. Почему коварных? В проверке на отметку есть подводные камни.
Раз уж мы взялись писать более-менее универсальный скрипт, то нужно подумать и о извращенных необычных конструкциях, которые в дальнейшем будут называться «группы». Под этим словом будем подразумевать связанные друг с другом поля. Например, если пользователь поставил флажок «Присылать на почту новости» - становится обязательным к заполнению пункт «e-mail», или телефон нередко любят разделять на код и сам номер – тогда корректность должна проверяться по всем полям, а некорректность одного влечет за собой ошибку в обоих. Да и сообщение об ошибки надо выводить не у всех полей групы, а только у одного, иначе от их количества начнет в глазах рябить.
Какой вывод можно сделать? Надо организовать обычную проверку на текстовое поле, проверку на email и «цифровые» поля вроде телефона, возраста, итп. Чекбоксы и радиокнопки проверяем на свойство checked, выпадающие списки – по значению. Чтобы удовлетворить хитрые группы – написать обработчик и для них. Кроме того, обеспечить возможность проверки некоторых полей какой-нибудь пользовательской функцией для особо замороченных случаев.
Организация хранения информации о проверяемых полях и типах проверки.- Создаем javascript-объект, в котором храним необходимые для проверки поля.
- Засовываем информацию о проверках непосредственно в теги полей.
JS-объект будет быстрее работать, да и смотреться куда корректнее, нежели какие-то нестандартные атрибуты в тегах. Скажем, выглядеть он будет так:
Если программист добирается до сайта, когда он уже полностью сверстан ( то есть действие происходит в фантастическом романе ) – такой подход прекрасен. Но зачастую что-то обязательно будет доделываться, в том числе могут дописываться дополнительные поля или создаваться новые формы, а оставлять добавление обработчиков полей на совесть верстальщиков, даже при наличии написанного конструктора, - значит обрекать себя на постоянные обращения с их стороны в стиле «а у меня тут все поломалось». И тогда о главном постулате задумки, автоматизации (ну, точнее, избавлении себя-любимого от ненужных телодвижений), придется забыть.
Тогда можно попробовать засовывать данные о проверке в нестандартные атрибуты, превращая лаконичное в громоздкого монстра вроде Остановимся мы именно на этом варианте. Мы же за универсальность.
- Y – значит, надо проверять
- email или num – обозначает стандартную проверку на email или цифры/телефон при заполненности
- Y_email / Y_num – обязательная проверка на email или num
- groupID – заключение элемента в группу с идентификатором groupID с параметрами проверки, указанными в скобках
- на вход подаем указатель на форму, в которой делать проверку (у нас же много форм может быть на странице!);
- пробегаем по указанным элементам формы, проверяя корректность заполнения;
- если ошибки есть – маркеруем их, если нет – разрешаем проверку формы.
Наверное, уже пора выдать js-код, реализующий функционал хотя бы частично, раз уж отписана такая куча текста?
В качестве примера приведем так же особую функцию проверки, например, проверяющую на наличие двух слов в инпуте (Имя Фамилия или Имя,Фамилия). Инпут, запускающий проверку по этой функции реализуется таким образом: А функция проверки будет выглядеть, например, так: Ну и стиль надо бы какой-нибудь нашей проверке задать:
Скрипт валидации формы.Теперь в случае успешного выполнения функции cFM_checkFullness() (то есть возвращения true) скрипт должен отсылать форму на обработку. Как это реализовать - зависит уже от конкретной формы. Если подтверждение на отправку идет через кнопку submit - то можно подписаться на событие отправки формы (onsubmit) и в зависимости от результата проверки отсылать ее или нет. Например, так: Если же отправка идет с помощью ajax'а - то тут вообще все просто: вызывать его в зависимости от результата работы функции cFM_checktrueAttr($(this));
Дополнительные заморочки.В приведенном выше коде отсутствует проверка на группы (ибо громоздкость кода возрастает в разы, а размер полосы прокрутки данной статьи итак наверняка отпугнул многих посетителей). Различия же в алгоритме будут незначительны: проверка элементов по группам должна запускаться в отдельном блоке, и в зависимости от работы всего блока выдавать сообщение об ошибке в конкретном элементе. Правда, на этом моменте стоит притормозить и задуматься: а действительно ли необходимо дорабатывать код для поддержки групп, или можно ограничиться написанием отдельной функции проверки для пары сложных полей?
Что же мы имеем в итоге? Подключая пару файлов (.js и .css), получаем функционал проверки свойств, который можно со спокойной душой кидать на любые сайты, при условии подключенного jquery. Ведь куда приятнее иметь под рукой набор готовых инструментов, чем тратить кучу времени на их производство перед каждой однотипной задачей.
Подключение и примерыВо-первых нам понадобится библиотека jquery. Скачать ее можно, например, с официального сайта. Или же просто вставить в шапку (то, что внутри тега <head>) вашего сайта строку Затем качаем (правой клавишей -> понравившийся пункт со словом «сохранить») отсюда файл с js-кодом и, если нужно, файл с css-стилями для ошибочных полей отсюда. Добавляем в шапку и их тоже: Теперь нужно расставить атрибуты полям формы согласно таблице, в зависимости от того, какую проверку вы хотите совершить. Последний штрих - добавление тегу <form> события onsubmit: «onsubmit="return cFM_checktrueAttr($(this));"».
Давайте теперь попробуем реализовать проверку такой простенькой формы:
Оценить применение скрипта можно так же на сайте mosavtotrade, на всех формах стоит именно эта проверка.