Пользователь
0,0
рейтинг
1 июня 2013 в 20:03

Разработка → jVForms.js — кроссбраузерный полифил проверки форм из песочницы


Что это?



  1. Автоматическая проверка форм HTML типа text|textarea.
  2. Проверка форм происходит по атрибутам `required` и `pattern` и разработан, преимущественно, для браузеров, не поддерживающих данные атрибуты.
  3. Встроенный набор шаблонов для быстрого использования.
  4. Возможность установить обработчик отправки формы на любой HTML элемент по клику как в форме так и за ее пределами.


Ну и зачем?



К сожалению не все браузеры способны поддерживать такие стандартные атрибуты как required и pattern, и к сожалению ни все и не всегда обновляют браузеры до последних версий.

Internet Explorer Chrome Opera Safari Firefox Android iOS
required 10.0 5.0+ 9.6+ x 4.0+ 2.3+ 3.0+
pattern 10.0 5.0+ 9.6+ x 4.0+ 2.3+ 3.0+


Ну да! А что делать?


Можно воспользоваться грамотным полифилом jVForms.js, который не займет много места, не нуждается в настройках (только иногда) и выполнит всю грязную работу по проверке форм за Вас.

А как?


Подключите jVForms.min.js в конце документа перед закрывающимся тегом `body` и инициализируйте его.

<script src="jVForms.min.js"></script>
<script>
    jVForms.initialize();
</script>


А дальше?


Добавьте атрибут `required=«required»` в поле формы, сделав тем самым элемент обязательным для заполнения.

<input type="text" name="field_1" value="" required="required"/>


HTML required-attribute

Добавьте атрибут `pattern=«RegExp»`, где `RegExp` — ваше регулярное выражение для проверки формы.
<input type="text" name="field_1" value="" required="required" pattern="^\d+$"/>


HTML pattern-attribute

А что такое регулярное выражение?


Если возникли трудности с добавлением регулярного выражения, можно воспользоваться готовым набором шаблонов, просто объявив их в классе.
<input type="text" name="field_1" value="" class="шаблон"/>


Список шаблонов:

  • vf-all: Любой символ, не являющийся символом-разделителем
  • vf-numInt: Число целое
  • vf-numFloat: Число десятичное
  • vf-notNum: Не число
  • vf-index: Индекс
  • vf-wordUpper: Слово на Ru или US в верхнем регистре и знак(-)
  • vf-wordLower: Слово на Ru или US в нижнем регистре и знак(-)
  • vf-wordRuUpper: Слово на Ru в верхнем регистре и знак(-)
  • vf-wordRuLower: Слово на Ru в нижнем регистре и знак(-)
  • vf-wordUSUpper: Слово на US в верхнем регистре и знак(-)
  • vf-wordUSLower: Слово на US в нижнем регистре и знак(-)
  • vf-stringRu: Сторка любая не содержащая US букв
  • vf-stringUS: Сторка любая не содержащая Ru букв
  • vf-timeHM: Время в формате час: минуты
  • vf-dateDMY: Дата в формате день/месяц/год
  • vf-dataDMYus: Дата в формате месяц/день/год
  • vf-cc: Кредитная карта в формате 9999 9999 9999 9999
  • vf-phone: Номер в формате 999 99 99 или 9999999 или 999-99-99 или 999-99 99
  • vf-phoneDash: Номер в формате (999) 999-9999 или (999) 999 9999
  • vf-phoneAlong: Номер в формате (999) 9999999


Шаблонов можно объявить сколько угодно, но работать будет только первый:
<input type="text" name="field_1" value="" class="vf-numInt vf-wordUSLower vf-dataDMYus otherClass"/>


При объявлении атрибута pattern и класса шаблона, класс шаблона работать не будет:
<input type="text" name="field_1" value="" required="required" pattern="^\d+$" class="vf-numInt"/>


Если атрибут `required=«required»` опущен и добавлен класс шаблона или атрибут `pattern`, то такое поле не является обязательным для заполнения,
но если оно все же будет заполнено, то будет проверено:
<input type="text" name="field_1" value="" class="vf-numInt"/>


Мне не подходит submit!


Для установки обработчика на любой другой элемент в пределах формы, необходимо добавить в него класс vf-submit:
<form>
    <input type="text" required="required" name="name" class="vf-numInt"/>
    <input type="text" name="phone"/>
    <textarea name="area"></textarea>
        
    <span class="vf-submit">Отправить</span>
</form>


Для установки обработчика на любой другой элемент вне формы, необходимо добавить в него класс vf-submit, а также связать этот элемент с формой.
Для этого у формы необходимо указать атрибут id или атрибут name и значение этого атрибута присвоить в виде класса элементу обработчику:
<form id="formId">
    <input type="text" required="required" name="name" class="vf-numInt"/>
    <input type="text" name="phone"/>
    <textarea name="area"></textarea>
</form>

<span class="vf-submit formId" >Отправить</span>


Хочу только ошибки.


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

  • Off: отключить уведомления;
  • All: подсвечивать правильные и неправильные поля;
  • Error: подсвечивать только неправильные поля;


Значение по умолчанию: «All». Чтобы сменить это значение на «Off», например, необходимо в инициализирующую функцию передать следующее:
<script>
    jVForms.initialize({
	    notice: 'Off'
	});
</script>


И что в итоге?


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

Git: jVForms.js

Спасибо за внимание!

Демонстрация здесь!
Кирилл @Lubaev
карма
6,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (42)

  • +2
    А если форма динамически создается?
    • –2
      Все хорошо. Главное чтобы скрипт, отвечающий за создание динамической формы, был подключен до инициализирующей функции.
      • +1
        А если форма создается. потом уничтожается, потом создается другая? Не будет ли утечек памяти?
        • 0
          А так ли страшны утечки на стороне клиента?
          Другое дело, если у вас какая-то игра или соц сеть где не надо перезагружать страницу. Я вот всегда стараюсь, как можно больше на сторону клиента перенести.
          • 0
            Я думаю, если бы у вас gmail или вконтактик истекал памятью, вы вряд ли были бы этому рады.
            • –1
              К сожалею, утечка памяти будет, так как обработчики не удаляются. И возвращаясь к Вашему первому вопросу, хотел бы уточнить, что если форма создается динамически, но скажем до инициализации, то она будет обработана, а если, скажем по клику мыши в процессе работы, то увы нет.
              Если только на этот же клик не повесить функцию, скажем
              onclick="return jVForms.initialize({notice: 'Error'});"
              
  • 0
    Где можно посмотреть примеры?
    • –2
      К сожалению примеров нет. Да я думаю в примерах он и не нуждается, там нет ничего сложного и сверхъестественного.
      • +2
        Существует негласное правило — всё что связанно с js,html,css требует примеров. хотя бы на jsfiddle. благо их сделать — 5 минут.

        З.Ы. Поясню почему:
        Если я вижу статью про js библиотеку или css-трюк, первым делом — я смотрю демо, что бы убедиться в работоспособности того что в этой статье описывается. Только увидев код в деле появляется желание читать статью с подробностями по использованию.

        К тому же ваша статья из песочницы, что совсем не добавляет уверенности в том, что библиотека не будет сбоить.
    • +1
  • +5
    А зачем использовать аттрибут class для шаблонов? Надо следовать стандартам по мере возможностей. Я бы на вашем месте использовал один из data-* аттрибутов.
    • +1
      Более того, его и нужно использовать. Как минимум валидаторы должны ругаться на кастомные аттрибуты.
      • +1
        Какие кастомные атрибуты?
    • –2
      Хороший вопрос, спасибо! Честно говоря я не подумал про данный атрибут. Но если попытаться ответить сходу на Ваш вопрос, то я отвечу так:
      «Атрибут class, скажем, более известен и более прост для понимания, (наверное я старомоден). И, наверное, jVForms это не тот проект, где плюсом было бы использовать data-, нежели class для связи с js. Тем ни менее, это хороший атрибут, и может быть он появиться. „
      • 0
        Не совсем понял аргументацию. Есть стандарты. Разработчики должны по мере возможности следовать стандартам, так как стандарты помогают содержать код в чистоте и делают поведение кода более понятным и предсказуемым для других людей.

        htmlbook.ru/html/attr/class
        «Задает стилевой класс, который позволяет связать определенный тег со стилевым оформлением.»

        Это мелочь конечно, мир не рухнет, однако когда таких мелочей становится много, то проект превращается в кошмар :)

        • –2
          Я не буду спорить, это дело Вашего вкуса. К примеру если бы я начал пользоваться jVForms.js и не знал рег. выр., для меня было бы проще написать нужный класс, нежели атрибут data.
          Например я не знаю атрибут data, и мне для начала нужно обратиться к спецификации HTML, чтобы узнать о нем подробнее, а потом уже писать правило. Хотя это конечно же мелочь.
          Во-вторых, может быть придется задать стилевое оформление через класс, тогда не нужно писать лишний атрибут, и увеличивать длину кода, хотя это быть может тоже не аргумент.

          Тут играет роль, вопрос юзабилити для конечного пользователя. А пользователь, который не знает рег. выр., думаю и не особо знает новый атрибут data.

          P.S. Вы меня заинтриговали, и я решил почитать про него, на что мне W3.org ответил -> Not Found
          • 0
            При чем тут мой вкус никак не пойму. Речь о стандартах.

            Также не пойму почему написать class=«blabla» легко, а data-*=«blabla» тяжело. Bootstrap, Foundation и многие другие популярные библиотеки не стестняются его использовать, никто не жалуется. Так-что аргумент о юзабилити не катит.

            И если конечный пользователь (веб-разработчик) не знаком с аттрибутом data-*, тот тут вина не аттрибута а пользователя, так как он, как веб разработчик обязан знать вдоль и поперек технологию с которой работает, а если не знает — стремиться к этому, пусть читает доки, гуглит, дело его. А если он и на это не способен — вон из професии.
            • +1
              data-* это вообще очень удобно и это как мне кажется как данность, его не стоит сторониться или как то обходить… это удобно и нормально и все тут.
  • +1
    A min, max и step поддерживаются?
    • 0
      Аааа. Не понял?
      • 0
        • 0
          jVForms проверяет только поля типа text и textarea. На сколько я понимаю атрибуты min, max, step применимы к
          <input type="number" step="число" max="число" min="max"/>
          <input type="range" step="число" max="число" min="max"/>
          <input type="date" min="нижняя дата"/>
          
          • 0
            Почему так?
            • 0
              Не понимаю я Вас что-то совсем. Что почему так? Почему так проверяет или почему min, man, step применимы только к полям которые я описал?
              • 0
                Виноват что плохо пояснил.

                Я спросил почему вы сделали что «jVForms проверяет только поля типа text и textarea».
                Было бы круто, если бы ваш плагин работал по уже существующим стандартам в тех браузерах, где нет поддержки HTML5.
                • –2
                  Такую задачу я перед собой не ставил, к сожалению. Целью было только то, что получилось, не больше этого.
  • 0
    Ещё нужна кастомная функция, чтоб можно было проверить на диапазон дату либо идентичность одного поля другому для случаев вроде «Введите пароль ещё раз, ну и тд.»
    • 0
      Целью jVForms является поддержка HTML атрибутов required=«required» и pattern для тех боаузеров, которые их не тянут. Так же он расширяет возможности по созданию рег. выр. через класс. А об ответе на Ваш вопрос должен думать другой человек, который и будет реализовывать механизм идентичности или проверки диапазона дат.
      • 0
        Вы пожалуй правы, но если хотите популяризации проекта, то наверное понимаете, что разработчику не нужны полумеры. Мало кто имеет одну машину для работы, вторую для рыбалки и третью «выходного дня». Я бы пользовался подобной библиотекой, но видя, что нужно прикручивать jquery validate для покрытия минимума валидаций — постараюсь реализовать всё в одном ключе, то есть выбор будет не в пользу вашей библиотеки.
        • 0
          Прикрутить не сложно, было бы желание. Сложно всего и сразу предусмотреть, другой вопрос надо ли?

          Но если будет спрос и пожелания, то сделать «швейцарский нож» не стоит труда.
  • +2
  • 0
    С ошибка пользователю обьяснятся как будет? Проверка идет по регулярке.
    • –1
      Если ошибка, поле подсвечивается красным, если правильно, то зеленым.
      В режиме All, подсвечиваются оба поля, правильные и неправильные;
      В режиме Error, только ошибочные поля;
      Если Off, то подсветка отключена;

      Проверка происходит сразу после начала ввода с клавиатуры + после изменения поля по рег. выражению. Подробности здесь.
      • 0
        Подсветку я понял. Но ведь пользователю надо сказать, почему именно его ввод не верный. Какую он ошибку допустил. Разве нет? Например «длина пароля слишком маленькая» и т.п.
        • –1
          К сожалению, нет. За то, какую ошибку допустил пользователь, должен позаботиться тот, кому это нужно. При создании у меня такой цели не было. По идеи, это как HTML атрибуты required и pattern, которые оповещают лишь о том, что поле обязательно для заполнения или что вводимые символы не допустимы на соответствие шаблону pattern. Эту идею можно развить, если Вам интересно. jVForms с открытым кодом, поэтому Вам и карты в руки.
  • –3
    В статье ни слова о проверке валидации на стороне сервера и регулярках и это пугает.
    Неужели кому-то лень изучить рас и навсегда регулярные выражения, которые пригодятся в таких штуках, как php, js, mod_rewrate. Да даже, если и лень можно полно примеров, есть даже сайты целиком посвященные этим примерам.
    А если лень самому писать проверку на стороне сервера и клиента есть уже готовые библиотеки jQuickForm, Zend_Form, HTML_QuickForm2
    • 0
      mod_rewrite
    • –2
      При чем тут сервер? Зачем вообще перегружать сервер ненужными запросами, если есть возможность проверить у клиента...(
  • 0
    Молодцы, продолжайте проверять и дальше у клиента… И xss блокируйте у клиента на стороне. И mySQL injection там же. И закидайте тапками всех, кто нагружает сервер бессмысленной валидацией.

    PS Я сторонник того что бы на клиента переложить все расчеты которые понадобится ему в работе с сайтом. Но никогда, слышите, никогда не доверяйте данным от клиента. Будь то http заголовки, куки, гет пост данные. И всякие другие идущие как сокет.
    • 0
      Эта статья про валидацию данных на клиенте, про поддержку html5 атрибутов require и pattern. Конечно никто не отменяет проверку данных на сервере, просто зачем делать лишние запросы, если всё можно подготовить и проверить на клиенте и моментально сообщить об этом юзеру.

      P.S. Я даже картинки жму на клиенте, а сервере проверяю только mime и размер.
      • 0
        Да я всеми руками за то чтобы предварительно делать проверку на клиенте и не трогать лишний раз сервер. Я просто негодую о том, что сервер пропустит не валидные данные в случае использования только контент статьи.

        PS С картинками проще, можно в директории права запретить. У вас ведь стоит .htaccess со строкой php_flag engine 0 в той директории. Чем жмете если не секрет?
  • 0
    ParsleyJS смотрели?
    Валидация работает как часы.

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