Walidacja formularzy za pomocą Constraint Validation
Gdy po raz pierwszy miałem do czynienia z natywną walidacją formularzy, pomyślałem sobie, że nie ma takiej opcji, aby zastąpiła ona własnoręcznie wykonane mechanizmy sprawdzania. Wydawało mi się, że głównymi problemami będą: stosunkowo nieduża elastyczność oraz niekompletne wsparcie przeglądarek. Pomimo, iż nadal w wielu przypadkach nie zdecydowałbym na takie posunięcie, to jednak okazuje się, że Constraint Validation ma naprawdę spore możliwości. Dla niewymagających może się to okazać w sam raz.
Temat jest naprawdę dość złożony, dlatego pozwolę sobie przedstawić tylko wybrane elementy Constraint Validation, by wstępnie przybliżyć to zagadnienie. Więcej szczegółowych informacji znajduje się w źródłach, do których linkuję na końcu artykułu.
Czym jest Constraint Validation?
Constraint Validation jest natywnym mechanizmem walidacji formularzy, stosowanym przez nowoczesne przeglądarki. Wykorzystywane są do tego dodatkowe atrybuty pól, takie jak np. required, min, max, step, pattern. Walidacja następuje w momencie próby wysłania formularza, jednak można ją uruchomić w dowolnym momencie dzięki użyciu Constraint Validation API. Możliwe jest również zmodyfikowanie zarówno treści domyślnych komunikatów błędów, jak i ich zachowania oraz wyglądu (w zależności od przeglądarki mogą występować pewne różnice).
Możliwości Constraint Validation
W pewnych okolicznościach walidacja natywna przeglądarek może zastąpić własnoręcznie przygotowaną dynamiczną walidację. Constraint Validation znacząco ułatwia weryfikację wprowadzonych danych. Wystarczy dodać kilka kolejnych atrybutów do pól formularza, by bez dodatkowych nakładów pracy poinformować użytkownika o zauważonych problemach. Można w ten sposób zapobiec wysłaniu formularza w sytuacji, gdy pola są puste, gdy wpisane dane są nieprawidłowe, przekraczają zakres lub nie są odpowiednie dla danego typu pola. Wszystko to w bardzo łatwy sposób pozwala na wykonanie podstawowej walidacji. Dodatkowo można w stosunkowo prosty sposób dostosować otrzymywane komunikaty błędów, bez potrzeby dołączania do strony zewnętrznej biblioteki lub pisania dziesiątek linii kodu.
Uwaga! Walidacja po stronie klienta nie zwalnia z walidacji po stronie serwera!
Przykład 1: pola wymagane
<form method="post">
<input type="text" required="required" />
<input type="submit" value="Wyślij" />
</form>
Przykład 2: wymagany typ pola
<form method="post">
<input type="email" placeholder="Wpisz adres e-mail" />
<input type="number" placeholder="Wpisz liczbę" />
<input type="submit" value="Wyślij" />
</form>
Przykład 3: format danych
<form method="post">
<input type="text" pattern="[0-9][0-9]-[0-9][0-9][0-9]" placeholder="Kod pocztowy" />
<input type="text" pattern="[a-zA-Z0-9]+" placeholder="Tylko liczby i litery" />
<input type="submit" value="Wyślij" />
</form>
Przykład 4: zakres i krok
<form method="post">
<input type="number" min="1000" max="9999" step="2" />
<input type="submit" value="Wyślij" />
</form>
Liczba z zakresu 1000 do 9999 (tylko co druga)
Metody Constraint Validation API (DOM API)
Constraint Validation dodaje do modelu DOM kilka nowych metod i właściwości. Zwykle służą one do określania statusu walidacji (np. willValidate czy validationMessage) bądź pozwalają na nadpisanie domyślnych komunikatów i zachowań (setCustomValidity oraz checkValidity).
Spis wszystkich metod oraz właściwości można znaleźć tutaj: http://www.html5rocks.com/en/tutorials/forms/constraintvalidation/#toc-dom-api
Dodatkowe atrybuty HTML
Część z atrybutów pojawiła się już w zamieszczonych wyżej przykładach. Lista dodatkowych atrybutów przedstawia się następująco:
- maxlength – określa maksymalną ilość znaków pola,
- max – określa maksymalną wartość,
- min – określa wartość minimalną,
- step – określa krok dostępnych wartości (np. 3 – tylko co trzecia wartość),
- pattern – określa prawidłową wartość za pomocą wyrażenia regularnego,
- type – określa typ pola (np. email, number, date, text),
- novalidate – nadawany dla formularza – wyłącza sprawdzanie formularza podczas wysyłania,
- formnovalidate – nadawany dla elementu button lub pola submit – działa podobnie, zawsze nadpisuje atrybut novalidate i nakazuje wysłanie formularza niezależnie od nadanych ustawień.
Pseudoklasy CSS
Constraint Validation udostępnia także dodatkowe pseudoklasy CSS, które mogą posłużyć do zdefiniowania własnego wyglądu pól formularza z uwzględnieniem tego, czy wpisane dane są poprawne bądź nie. Najważniejszymi i powszechnie obsługiwanymi są:
- :invalid – odwołuje się do pól wypełnionych nieprawidłowo,
- :valid – odwołuje się do pól, które są poprawne i nie zgłaszają błędów.
Istnieją również inne pseudoklasy, jednak dotyczą one tylko szczególnych przeglądarek i nie są powszechnie stosowane.
Podsumowanie
Czy warto stosować Constraint Validation? Jak zwykle wszystko zależy od konkretnej sytuacji, jednak dla pewnych mało wymagających zastosowań takie rozwiązanie może okazać się zupełnie wystarczające.
Nie wolno jednak zapominać, że walidacja danych wyłącznie po stronie użytkownika nie jest bezpieczna i nie można ją uznać za wystarczającą. Nie zwalnia ona z przeprowadzenia walidacji danych po stronie serwera. Potrzeba naprawdę niewiele, by obejść każde, nawet najbardziej wymyślne walidacje i zabezpieczenia wdrożone wyłącznie po stronie przeglądarki. Wystarczy tylko nieco technicznej wiedzy, determinacja oraz FireBug lub inny inspektor kodu źródłowego. Tylko w przypadku zweryfikowania otrzymanych danych po stronie serwera mamy absolutną pewność, że nie zostały one zmanipulowane. Odpowiednio zmodyfikowane mogą służyć do nadużyć, a nawet do przeprowadzenia ataku na Twój serwis internetowy. Bezwzględnie przeprowadzaj walidację po stronie serwera! Zawsze.
Więcej informacji