Вътре в jQuery валидира приставката, SavePearlHarbor
Още едно копие на хабора
Главно меню
След навигация
Какво научаваме от тази статия:
1. Как да проверите формуляр.
2. Съобщения за проверка и как работят.
3. Добавяне на собствени правила за валидиране.
4. Какво точно се случва, когато извикаме метода за валидиране.
Как да проверя формуляр
Има 2 основни начина за валидиране на формуляр.
1. Използвайте имена на класове като правила
Как работи
Добавяме атрибута "class" html към полето, което ще бъде проверено, и това ще даде възможност за проверка.
Така че, ако искаме текстовото поле да се изисква, добавяме стойността на атрибута class = "reqiured" към входния елемент
По този начин можете да добавите множество правила към определени класове.
Плюсове и минуси на този подход:
Работи само с правила, които не вземат аргументи.
Използваме атрибута html "class" за това, за което не е предназначен.
Но е лесно да се инсталира.
Използване на метода "AddClassRules"
Използването на функцията "addClassRules" ни дава възможността да използваме сложно правило за един клас.
Този код добавя 2 нови правила за класовете "name" и "zip" и ако имаме елемент "input" с клас "zip", тогава правилата се отнасят за него: неговата стойност е задължителна, потребителят може да въведе само числата и дължината трябва да са точно 5 знака.
Информация: За да използваме персонализирано съобщение за конкретно правило за изискване в съставно правило, трябва да измислим псевдоним за правилото „задължително“, да създадем ново правило с този псевдоним и да зададем съобщение по подразбиране за него.
Или можем да използваме атрибута html "title", стойността му ще бъде съобщението за грешка за сложното правило.
Забележка: Проверката по име на клас работи само за правила за проверка, които не вземат никакви аргументи.
2. Добавяне на правила като JSON обект към метода validate ()
По името трябваше да предположите, че този метод за валидиране приема json обект, за да можем да дефинираме полетата, които трябва да проверим, и правилата за валидиране за тях.
Забележка: Когато предаваме обекта „rules“ на функцията „валидиране“, ключът трябва да е стойността на атрибута „name“, а не стойността „id“. Както можете да видите в примера: ключът е "userEmail", стойността на атрибута е "name", а атрибутът "id" има различна стойност.
Плюсове и минуси на този подход:
Този подход ни позволява да използваме повече правила за валидиране, които вземат аргументи като minlength, remote, jednakTo и т.н.
Отличен и ръчно конфигурируем контрол върху всичко.
Но потребителят трябва да направи отделна функция "валидиране" с различни опции за всяка форма.