Dom / Problemy/ Lekkomyślna walidacja php. Zwalidowane, zwalidowane... i zwalidowane! Porównanie walidatorów danych w PHP

Lekkomyślna walidacja php. Zwalidowane, zwalidowane... i zwalidowane! Porównanie walidatorów danych w PHP

Bardzo ważne jest zweryfikowanie wprowadzonych danych przed przyjęciem danych przesłanych do formularza do dalszego przetwarzania. Gdy w formularzu jest wiele pól, skrypt sprawdzający poprawność PHP staje się zbyt skomplikowany. Ponieważ wykonujesz tę samą lub podobną weryfikację dla większości tworzonych formularzy, po prostu zbyt wiele wysiłku związanego z powielaniem jest poświęcane na sprawdzanie poprawności formularzy.

O tym ogólnym skrypcie sprawdzania poprawności formularza PHP

Ten ogólny skrypt walidatora formularzy PHP bardzo ułatwia dodawanie walidacji do formularza.

Tworzymy i łączymy zestaw „deskryptorów walidacji” z każdym elementem w formularzu. „Deskryptor walidacji” to ciąg określający typ walidacji, która ma zostać przeprowadzona. Na przykład „req” oznacza wymagane, „alpha” oznacza dozwolone tylko znaki alfabetu i tak dalej.

Każde pole w formularzu może mieć zero, jedną lub więcej walidacji. Na przykład dane wejściowe nie powinny być puste, powinny mieć mniej niż 25 znaków, powinny zawierać znaki alfanumeryczne itp.

Możesz powiązać zestaw deskryptorów sprawdzania poprawności dla każdego pola wejściowego w formularzu.

Pobierz skrypt sprawdzania poprawności formularza PHP

Możesz pobrać skrypt sprawdzający poprawność formularza PHP poniżej:
Plik ZIP zawiera skrypt sprawdzania poprawności formularza formvalidator.php, dokumentację i przykłady użycia.

Korzystanie ze skryptu sprawdzania poprawności formularza PHP

Dołącz formvalidator.php do skryptu przetwarzania formularza
Utwórz obiekt FormValidator i dodaj deskryptory sprawdzania poprawności formularza.

Pierwszym argumentem jest nazwa pola wejściowego w formularzu. Drugim argumentem jest deskryptor walidacji, który określa typ wymaganej walidacji. Trzeci argument to komunikat o błędzie, który zostanie wyświetlony, jeśli sprawdzanie poprawności zakończy się niepowodzeniem.

Sprawdź poprawność formularza, wywołując funkcję ValidateForm().

Błędy walidacji:

$inpname: $inp_err

przykład

Poniższy przykład rozjaśni ideę

addValidation("Nazwa","req","Proszę podać nazwę"); $validator->addValidation("Email","email", "Wejście dla Email powinno być prawidłową wartością email"); $validator->addValidation("E-mail","req","Proszę podać adres e-mail"); if($validator->ValidateForm()) ( echo "

Sukces walidacji!

"; $show_form=false; ) else ( echo " Błędy walidacji:"; $error_hash = $validator->GetErrors(); foreach($error_hash as $inpname => $inp_err) ( echo "

$inpname: $inp_err

\n"; ) ) ) if(true == $show_form) ( ?>

Dodanie niestandardowej walidacji

Jeśli chcesz dodać niestandardowe sprawdzanie poprawności, które nie jest dostarczane przez deskryptory sprawdzania poprawności, możesz to zrobić. Oto kroki:

Utwórz klasę dla niestandardowej walidacji i zastąp funkcję DoValidate().

class MyValidator rozszerza CustomValidator ( function DoValidate(&$formars,&$error_hash) ( if(stristr($formars["Comments"],"http://")) ( $error_hash["Comments"]="Niedozwolone adresy URL w komentarzach”; zwróć fałsz; ) zwróć prawdę; ) )

Dodaj niestandardowy obiekt sprawdzania poprawności

$walidator = new FormValidator(); $validator->addValidation("Nazwa","req","Proszę podać nazwę"); $validator->addValidation("Email","email", "Wejście dla Email powinno być prawidłową wartością email"); $validator->addValidation("E-mail","req","Proszę podać adres e-mail"); $custom_validator = new MyValidator(); $validator->AddCustomValidator($custom_validator);

Niestandardowa funkcja walidacji zostanie wywołana automatycznie po innych walidacjach.

Tabela deskryptorów walidacji

Oto lista wszystkich deskryptorów sprawdzania poprawności:

Deskryptor walidacji	Stosowanie
wymaganie	Pole nie powinno być puste
maxlen=???	sprawdza długość wprowadzonych danych do maksimum. Na przykład, jeśli maksymalny dozwolony rozmiar to 25, podaj deskryptor walidacji jako „maxlen=25”
Minlen=???	sprawdza długość wprowadzonego ciągu do wymaganego minimum. przykład "minlen=5"
album	Sprawdź dane, czy zawierają inne znaki niż znaki alfabetyczne lub numeryczne
album_s	Dozwolone są tylko znaki alfabetu, cyfry i spacje
liczba	Sprawdź dane liczbowe
alfa	Sprawdź dane alfabetyczne.
alfa_s	Sprawdź dane alfabetyczne i zezwól na spacje.
e-mail	Pole jest polem e-mail i sprawdź poprawność danych.
lt=??? mniej niż=???	Sprawdź, czy dane są mniejsze niż przekazana wartość. Dotyczy tylko pól numerycznych. przykład: jeśli wartość ma być mniejsza niż 1000 podaj opis walidacji jako „lt=1000”
gt=??? większy niż=???	Sprawdź, czy dane są większe niż przekazana wartość. Dotyczy tylko pól numerycznych. przykład: jeśli wartość ma być większa niż 10 podaj opis walidacji jako „gt=10”
wyrażenie regularne=???	Sprawdź za pomocą wyrażenia regularnego, czy wartość powinna pasować do wyrażenia regularnego. przykład: „regexp=^(1,20)$” dopuszcza maksymalnie 20 znaków alfabetu.
nie wybieraj=??	Ten deskryptor sprawdzania poprawności jest przeznaczony dla wybranych elementów wejściowych (list). Zwykle pola listy wyboru zawierają jeden element z napisem „Wybierz jeden”. Użytkownik powinien wybrać opcję inną niż ta opcja. jeśli wartość tej opcji to „Wybierz jeden”, opis walidacji powinien brzmieć „dontselect=Select One”
nie wybieraj	Ten deskryptor sprawdzania poprawności jest przeznaczony dla pól wyboru. Użytkownik nie powinien zaznaczać danego checkboxa. Zapewnić wartość pola wyboru zamiast ?? Na przykład: dontselectchk=on
powinienselchk	Ten deskryptor sprawdzania poprawności jest przeznaczony dla pól wyboru. Użytkownik powinien zaznaczyć dany checkbox. Podaj wartość pola wyboru zamiast ?? Na przykład shouldselchk=on
nie wybieraj radia	Ten deskryptor sprawdzania poprawności jest przeznaczony dla przycisków radiowych. Użytkownik nie powinien wybierać danego przycisku radiowego. Podaj wartość przycisku radiowego zamiast ?? Na przykład, nie wybieraj radia=NIE
wybierz radio	Ten deskryptor sprawdzania poprawności jest przeznaczony dla przycisków radiowych. Użytkownik powinien wybrać dany przycisk radiowy. Podaj wartość przycisku radiowego zamiast ?? Na przykład wybierz radio=tak
semin=??	Wybierz co najmniej n pól wyboru z grupy pól wyboru. Na przykład: semin=3
samotny	Sprawia, że grupa radiowa jest obowiązkowa. Użytkownik powinien wybrać co najmniej jedną pozycję z grupy radiowej.
równanie=???	porównaj dwa elementy w formularzu i upewnij się, że wartości są takie same Na przykład „hasło” i „potwierdź hasło”. Zastąp ??? z nazwą innego elementu wejściowego. Na przykład: eqelmnt=confirm_pwd

W poprzednim artykule obiecałem napisać porównanie własnej biblioteki z innymi dostępnymi rozwiązaniami, dlatego dzisiaj przyjrzymy się walidacji z wykorzystaniem Aura.Filter , Respect Validation , Sirius Validation oraz Valitron .

Wyobraźmy sobie, że rozwijamy jakąś usługę publiczną, która polega na rejestrowaniu użytkowników w celu uzyskania pełnego dostępu do wszystkich funkcji. Tym samym formularz rejestracyjny będzie zawierał następujące pola:

Nazwa. Musi zawierać dokładnie dwa słowa, gdzie pierwsze to imię użytkownika, a drugie to nazwisko.
Zaloguj sie. Jeśli wartość jest przekazywana, musi zawierać tylko litery łacińskie, łączniki i podkreślenia.
e-mail. Musi zawierać prawidłowy adres e-mail.
hasło. Musi być zainstalowany i nie dłuższy niż 64 znaki.
Zgoda. Typowy checkbox, który użytkownik musi zaznaczyć, aby potwierdzić zgodę na warunki korzystania z usługi.

Mamy więc pięć pól, które użytkownik musi wypełnić, aby zarejestrować się w naszym wyimaginowanym serwisie. Wyobraźmy sobie, że jako dane wejściowe otrzymaliśmy całkowicie nieprawidłowe dane:

$data = [ "name" => "Albert", // Powinno być dwa słowa "login" => "@lbert", // "Zakazany" znak @ "email" => "coś nie tak", / / To powinno być e-mailem "hasło" =>

Filtr Aury

Walidacja za pomocą Aura.Filter zaczyna się od fabryki filtrów. Musimy utworzyć tak zwany „filtr tematyczny”, ponieważ będziemy sprawdzać poprawność tablicy, a nie pojedynczej wartości.

Definiowanie zasad

użyj Aura\Filter\FilterFactory; $filtr = (nowa FabrykaFilterów)->nowyFiltrPodmiotu(); $filter->validate("nazwa") ->isNotBlank() ->is("dwa_słowa") ->setMessage("Nazwa musi składać się z dwóch słów."); $filter->validate("login") ->isBlankOr("alnum") ->setMessage("Jeśli podasz login, musi on zawierać tylko znaki łacińskie."); $filter->validate("email") ->isNotBlank() ->is("email") ->setMessage("Wprowadź poprawny adres e-mail."); $filter->validate("hasło") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Proszę wprowadzić hasło."); $filter->validate("agreed") ->is("callback", function($subject, $field) ( return $subject->($field) === true; ))->setMessage("Musisz zaakceptuj warunki korzystania z usługi.");

Jak widać, opis zasad jest dość prosty. Aura.Filter zapewnia cały zestaw przydatnych reguł, a niektóre z nich zostały użyte w powyższym przykładzie:

metoda isNotBlank. Określa, że pole nie może mieć wartości null.
album. Ta reguła dopuszcza tylko litery łacińskie.
e-mail. I takie jasne :)
strlenMax. Określa, że pole nie może przekraczać długości określonej przez drugi argument metody is.
oddzwonić. Ten typ reguły jest podobny do zamknięć z Kontrolio. Pozwala zdefiniować regułę jako zamknięcie. Do tego zamknięcia Aura.Filter przekazuje „subject”, naszą tablicę danych z formularza oraz pole, w tym przypadku uzgodnione.

Być może zauważyłeś, że nie określiłem zasady two_words. Oczywiście w Aura.Filter nie ma takiej reguły, więc musimy ją stworzyć. Jak mówi dokumentacja, odbywa się to za pomocą oddzielnej klasy dla reguły:

/** * Reguła sprawdzająca poprawność nazwy użytkownika. * Nazwa użytkownika składa się z dwóch słów: imienia i nazwiska, oddzielonych jedną spacją. */ class UserNameRule ( /** * Sprawdza poprawność nazwy użytkownika. * * @param object|array $subject * @param string $field * @param int $max * * @return bool */ public function __invoke($subject, $field , $max = null) ( $value = $subject->($field); if (! is_scalar($value)) ( return false; ) return (bool) preg_match("/^+\s+$/u", $wartość); ) )

Drugim krokiem jest powiadomienie fabryki filtrów o naszej nowej zasadzie. Odbywa się to poprzez przekazanie pierwszego argumentu jako tablicy reguł do fabryki filtrów:

Kolejnym krokiem jest powiadomienie Aura.Filter, że stworzyliśmy nową regułę i chcemy jej użyć. Odbywa się to poprzez przekazanie tablicy reguł do pierwszego argumentu fabrycznego:

użyj Aura\Filter\FilterFactory; $rules = [ "two_words" => function() ( zwraca nową regułę nazwy użytkownika; ) ]; $filter = (new FilterFactory($rules))->newSubjectFilter();

Teraz nasza reguła dwa_słowa może być używana tak samo, jak każda inna reguła z dystrybucji standardowej.

Informacja zwrotna

Jak pamiętacie, dane wejściowe, które sprawdzamy, są całkowicie błędne, ponieważ każde pole zawiera błędną wartość lub nie zawiera jej wcale. Dlatego zakłada się, że w wyniku walidacji otrzymamy błędy i odpowiadające im komunikaty o nich.

Weryfikujemy za pomocą Aura.Filter w następujący sposób:

$poprawne = $filtr->zastosuj($dane); if (! $poprawne) ( $błędy = $filter->getFailures(); $messages = $błędy->getMessages(); )

W $wiadomości tablica jest zapisana, więc potrzebujemy dwóch zagnieżdżonych fore, aby wyświetlić komunikaty:

$błędy) ( foreach ($błędy jako $błąd) ( printf("", $błąd); ) ) ?>

Szanuj walidację

Drugą biblioteką, której użyłem do porównania, jest stosunkowo popularne rozwiązanie o nazwie Respect Validation. Ponieważ ludzie jej ufają, myślę, że jest tam coś do zobaczenia.

Dla czystości eksperymentu, porównując biblioteki, użyjemy tego samego zbioru danych, który zdefiniowaliśmy na początku:

użyj Respect\Validation\Validator jako v; $data = [ "name" => "Albert", // Powinno być dwa słowa "login" => "@lbert", // "Zakazany" znak @ "email" => "coś nie tak", / / To powinno być e-mailem "hasło" => "" // Brak hasła // "zgoda" nie występuje w tablicy, ponieważ użytkownik nie zaznaczył pola ];

Definiowanie zasad

Podobnie jak w przypadku Aura.Filter, potrzebujemy własnej reguły sprawdzania poprawności nazwy użytkownika, więc zacznijmy od tego:

przestrzeń nazw Moja przestrzeń nazw; użyj Respect\Validation\Rules\AbstractRule; class UserNameRule extends AbstractRule ( public function validate($input) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

Interfejs API reguł zewnętrznych jest prawie identyczny z Aura.Filter, tylko metoda uprawomocnić() zamiast magii __odwołać się(). Wydawało mi się, że ten interfejs API jest prostszy i bardziej zrozumiały. No to bliżej do Kontrolio :)

Nie znalazłem o tym żadnej wzmianki w dokumentacji, jednak oprócz samej reguły konieczne jest stworzenie dla niej własnego typu wyjątku. Nazwa klasy wyjątku musi składać się z nazwy klasy reguły i przyrostka Wyjątek.

użyj Respect\Validation\Exceptions\NestedValidationException; klasa UserNameRuleException rozszerza NestedValidationException ( // )

Wreszcie możemy zweryfikować nasze dane. Najpierw przekazujemy naszą nową regułę walidatorowi, aby o tym wiedział, abyśmy mogli z niej skorzystać w przyszłości. W Respect Validation odbywa się to poprzez wywołanie metody z() wraz z przeniesieniem przestrzeni nazw, w której znajdują się reguły niestandardowe.

v::with("MojaPrzestrzeńNazw\\");

Teraz wszystkie niestandardowe reguły, które znajdują się w przestrzeni nazw mojaprzestrzeńnazw, zostanie „zidentyfikowany” przez walidator. Kolejnym krokiem jest opisanie wymaganych reguł i przeprowadzenie walidacji.

v::attribute("nazwa", v::userNameRule()) ->attribute("login", v::alnum("-_")) ->attribute("email", v::email()) ->attribute("hasło", v::notEmpty()->stringType()->length(null, 64)) ->attribute("zgoda", v::trueVal()) ->assert((obiekt) $dane);

Zwróć uwagę, jak stosujemy naszą regułę do atrybutu Nazwa. Tutaj nazwa klasy reguły została przekształcona w nazwę metody walidatora. Reszta zasad jest generalnie intuicyjna.

Osobno warto wspomnieć, dlaczego wprowadzamy tablicę $dane do obiektu. Faktem jest, że Respect Validation przyjmuje obiekty jako dane wejściowe, a nie tablice. Należy to wziąć pod uwagę podczas opracowywania przy użyciu tej biblioteki.

Informacja zwrotna

W przeciwieństwie do Aura.Filter, walidator Respect zgłasza wyjątek, gdy walidacja się nie powiedzie. Ten wyjątek zawiera komunikaty o błędach sprawdzania poprawności. Dlatego właśnie pokazany przykład powinien być zapisany w następujący sposób:

try ( v::with("RespectValidationExample\\"); v::attribute("name", v::userNameRule()) ->attribute("login", v::alnum("-_")) - >attribute("email", v::email()) ->attribute("hasło", v::notEmpty()->stringType()->length(null, 64)) ->attribute("uzgodniono", v::trueVal()) ->assert((object) $data); ) catch (NestedValidationException $ex) ( $messages = $ex->getMessages(); )

Za pomocą pobierzWiadomości(), otrzymamy płaską tablicę wszystkich komunikatów, które walidator zebrał podczas procesu walidacji. Zrzucając tablicę, otrzymujemy coś takiego:

array(5) ( => string(29) „Weryfikacja danych nie powiodła się dla %s” => string(60) „login musi zawierać tylko litery (a-z), cyfry (0–9) i „-_” => string (25) „adres e-mail musi być prawidłowym adresem e-mail” => string(26) „hasło nie może być puste” => string(32) „Uzgodniony atrybut musi być obecny” )

Możesz zmienić wiadomości na własne. Być może jakoś źle zrozumiałem tę bibliotekę, ale ten proces nie wydawał mi się taki oczywisty: trzeba użyć metody znajdźWiadomości() na obsługiwanym wyjątku, w którym definiujesz komunikaty nie dla atrybutów, ale dla reguł.

$ex->findMessages([ "userNameRule" => "Nazwa użytkownika musi składać się z dwóch słów.", "alnum" => "Nie podoba nam się Twoja nazwa użytkownika.", "email" => "Oczywiście nie chcesz podaj nam swój adres e-mail.", "notEmpty" => "Gdzie jest twoje hasło?", "agreed" => "Przepraszamy, nie zgadzasz się." ]);

Nie wiem, na czym polega błąd, ale jest kilka rzeczy, których nadal nie rozumiem. Oto, co otrzymamy, definiując reguły w powyższy sposób:

array(5) ( => string(40) „Nazwa użytkownika musi składać się z dwóch słów.” => string(31) „Nie podoba nam się Twoja nazwa użytkownika.” => string(25) „adres e-mail musi być prawidłowym adresem e-mail” => string(5) "Gdzie jest twoje hasło?" => string(9) "Przepraszamy, że się nie zgadzasz." )

Jak widać komunikat do pola email nie został zastosowany, pozostał standardowy. Ale przesłanie za indeksem 4 jest odwrotne! I to pomimo tego, że nie użyłem nazwy reguły, a nazwy pola. Natomiast gdybym użył nazwy reguły (trueVal), moja wiadomość gdzieś by się zgubiła. Komentarze doświadczonych użytkowników tej biblioteki są bardzo mile widziane.

Weryfikacja Syriusza

Ok, przejdźmy do następnej biblioteki i zobaczmy, jak radzi sobie z podobnymi zadaniami.

Definiowanie zasad

Ponownie musimy zdefiniować regułę dla nazwy użytkownika. Napiszemy to mniej więcej tak:

class UserNameRule extends AbstractRule ( // Komunikaty o błędach const MESSAGE = "Nazwa użytkownika musi składać się z dwóch słów."; const LABELED_MESSAGE = "(etykieta) musi składać się z dwóch słów."; public function validate($value, $valueIdentifier = null ) ( return ( bool) preg_match("/^+\s+$/u", $value); ) )

Zwróć uwagę na różnice w podejściach w porównaniu z rozważanymi już bibliotekami. Definiujemy dwa rodzaje komunikatów w stałych, zamiast używać właściwości, metod lub argumentów reguł.

Teraz opiszmy logikę walidacji:

$walidator = nowy walidator; $validator ->add("name", "required | MyApp\Validation\Rule\UserNameRule") ->add("login", "required | alphanumhyphen", null, "Login może zawierać tylko litery łacińskie, myślniki i podkreślenia. ") ->add("adres e-mail", "wymagane | adres e-mail", null, "Wprowadź prawidłowy adres e-mail.") ->add("hasło", "wymagane | maksymalna długość(64)", null, "Twoje hasło, proszę pana.") ->add("zgadzam się", "wymagane | równe(prawda)", null, "Dlaczego się nie zgodziłeś?");

Jak widać, zestaw zasad jest dość prosty i czytelny. W opisach używamy nazw oddzielonych poziomymi kreskami. To podejście jest podobne do tego stosowanego przez Laravel i Kontrolio.

Argument metody czwartej Dodaj() opisuje komunikat o błędzie sprawdzania poprawności, którego używa Syriusz, jeśli sprawdzanie poprawności się nie powiedzie. Dlaczego nie dodaliśmy wiadomości dla naszej nowej reguły Reguła nazwy użytkownika?

$validator->add("nazwa", "wymagane | MojaAplikacja\Walidacja\Rule\UserNameRule")

Dzieje się tak, ponieważ komunikaty są już opisane w stałych klasach:

class UserNameRule extends AbstractRule ( // Komunikaty o błędach const MESSAGE = "Nazwa użytkownika musi składać się z dwóch słów."; ...

Inną opcją jest użycie metody addMessage() samego walidatora:

$validator->addMessage("email", "Proszę wprowadzić poprawny e-mail.");

Zauważ, że niestandardowe reguły są identyfikowane przez pełną nazwę ich klasy, podczas gdy w Kontrolio możesz ustawić alias/alias.

Informacja zwrotna

Aby przeprowadzić walidację, wywołujemy metodę walidatora uprawomocnić(), przekazując do niego dane:

W przeciwieństwie do Szacunku, Syriusz nie rzuci wyjątku, po prostu powróci fałszywy. Komunikaty o błędach walidacji można odbierać za pomocą metody walidatora pobierzWiadomości(). Zwraca błędy pogrupowane według atrybutów, więc potrzebujemy dwóch pętli foreach, aby przejrzeć błędy:

foreach ($validator->getMessages() as $attribute => $messages) ( foreach ($messages as $message) ( echo $message->getTemplate() . "\n"; ) )

Tutaj $message jest obiektem klasy Syriusz\Walidacja\Komunikat o błędzie, który ma metodę pobierz szablon(), co zwraca dokładnie taką wiadomość, jakiej potrzebujemy.

Walitron

Definiowanie zasad

Pierwsza różnica polega na tym, że nie trzeba tworzyć oddzielnej klasy, aby dodać nową regułę. Możesz po prostu użyć zamknięcia, które zwraca wynik logiczny.

Istnieje statyczna metoda dodawania niestandardowych reguł do Valitron dodaj regułę(), gdzie pierwsze dwa argumenty są wymagane, a trzeci jest opcjonalny. Podobała mi się ta metoda, ponieważ tutaj identyfikator reguły, logika i komunikat o błędzie są wskazywane w jednym miejscu naraz.

użyj Valitron\Validator; Validator::addRule("two_words", function($field, $value) (return (bool) preg_match("/^+\s+$/u", $value); ), "Nazwa użytkownika musi składać się dokładnie z dwóch słów ");

Druga różnica polega na tym, jak reguły są stosowane do atrybutów. We wszystkich poprzednich przypadkach widzieliśmy, że atrybut jest niejako rzeczą podstawową.

Valitron poszedł w drugą stronę i na pierwszym miejscu umieścił zasady walidacji. Opisując reguły, w pewnym sensie stosujesz atrybuty do tych reguł, a nie odwrotnie.

$walidator = nowy Walidator($dane); $validator ->rule("dwa_słowa", "nazwa")->label("") ->rule("wymagane", [ "nazwa", "login", "e-mail", "hasło", "zgoda" ] ) ->rule("slug", "login") ->rule("e-mail", "e-mail") ->rule("zaakceptowano", "zgodził się");

Jak widać na przykładzie, w metodzie reguła() najpierw piszemy nazwę reguły, a dopiero potem określamy atrybuty, które muszą pasować do tej reguły. Bardziej wyraźnym przykładem jest wymagana reguła, która pokazuje, w jaki sposób atrybuty „należą” do reguły.

Valitron (podobnie jak inne rozwiązania, którym się przyglądaliśmy) zapewnia standardowe komunikaty o błędach. Jeśli po prostu ich użyjesz, zobaczysz, że każda wiadomość zaczyna się od nazwy odpowiedniego atrybutu.

Valitron zastępuje nazwy atrybutów w tekście komunikatu, nawet jeśli używane są niestandardowe komunikaty o błędach. Dlatego użyliśmy metody label() z pustym łańcuchem, aby usunąć nazwę atrybutu.

$walidator->reguła("dwa_słowa", "nazwa")->etykieta("")

Informacja zwrotna

W szczególności, jeśli chodzi o walidację, API biblioteki Valitron praktycznie nie różni się od tego, co widzieliśmy już w artykule. Aby przeprowadzić walidację, wywołujemy metodę walidatora uprawomocnić():

$walidator->walidacja();

Komunikaty o błędach sprawdzania poprawności można uzyskać za pomocą metody getErrors():

$walidator->błędy();

Wiadomości są tutaj pogrupowane według atrybutów dokładnie tak samo jak w Sirius Validation, z tą różnicą, że nie ma osobnej klasy dla wiadomości i otrzymujemy zwykłą wielowymiarową tablicę.

foreach ($validator->errors() as $attribute => $messages) ( foreach ($messages as $message) ( echo $message . "\n"; ) )

kontrola

I wreszcie ostatnia biblioteka na dziś to mój własny program o nazwie Kontrolio .

Definiowanie zasad

Ponownie, po raz piąty, utworzymy regułę sprawdzania poprawności nazwy użytkownika. Wszystko jest stosunkowo proste i standardowe:

przestrzeń nazw Mój projekt\Walidacja\Reguły; użyj Kontrolio\Rules\AbstractRule; class TwoWords rozszerza Kontrolio\Rules\AbstractRule ( public function isValid($input = null) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

Teraz tworzymy fabrykę i rejestrujemy w niej regułę za pomocą metody rozszerzyć():

przestrzeń nazw Mój projekt; użyj Control\Factory; użyj MyProject\Validation\Rules\TwoWords; $factory = Kontrolio\Factory::getInstance()->extend();

Po zarejestrowaniu reguły możemy z niej korzystać m.in. po nazwie - two_words . Stwórzmy walidator:

$data = [ "name" => "Albert", // Powinno być dwa słowa "login" => "@lbert", // "Zakazany" znak @ "email" => "coś nie tak", / / To powinno być e-mailem "hasło" => "" // Brak hasła // "zgoda" nie występuje w tablicy, ponieważ użytkownik nie zaznaczył pola ]; $rules = [ "nazwa" => "dwa_słowa", "login" => "czasami|alphadash", "email" => "email", "hasło" => "długość:1,64", "zgoda" = > "zaakceptowany"]; $messages = [ "name" => "Twoja nazwa użytkownika musi składać się z dwóch słów.", "login" => "Nie podoba nam się Twój login.", "email" => "Oczywiście nie chcesz nam podać twój adres e-mail .", "hasło" => "Więc gdzie jest twoje hasło?", "zgoda" => "Przepraszamy, że się nie zgadzasz." ]; $walidator = $fabryka->make($dane, $reguły, $wiadomości);

Zasady opisaliśmy używając składni podobnej do tej używanej w Laravelu, chociaż mogliśmy użyć bardziej szczegółowej wersji:

$rules = [ "name" => new TwoWords, "login" => , "email" => new Email, "password" => new Length(1, 64), "agreed" => new Accepted ];

Informacja zwrotna

Walidacja jest uruchamiana tą samą metodą uprawomocnić():

$walidator->walidacja();

Teraz możemy uzyskać komunikaty o błędach za pomocą jednej z metod getErrors() lub getErrorsList(). Pierwsza metoda pozwala na bardziej złożone wyjście błędów, podczas gdy druga zwraca płaską tablicę. Za pomocą getErrors() możemy wyświetlać takie komunikaty:

z getErrorsList() możesz zrobić prostszą listę wiadomości:

getErrorsList(); ?>

Wynik

W tym artykule pokazałem przykłady wykorzystania następujących bibliotek:

Filtr Aury
Szanuj walidację
Weryfikacja Syriusza
Walitron
kontrola

„Przykład z prawdziwego świata” może wydawać się zbyt prosty. Muszę się zgodzić, ponieważ rzeczywiście niektóre funkcje bibliotek zostały pominięte w artykule. Zasadniczo, jeśli jesteś zainteresowany, możesz sam przestudiować ich funkcje.

Każda z bibliotek oferuje swoje chipy, ma swoje ciemne strony, więc myślę, że to kwestia gustu i zadania – wybrać tę właściwą.

Dziękuje za przeczytanie. Dokonać dobrego wyboru.

Tagi:

walidacji danych
php
Jazda rowerem

Dodaj tagi

Nazwa. Musi zawierać dokładnie dwa słowa, gdzie pierwsze to imię użytkownika, a drugie to nazwisko.
Zaloguj sie. Jeśli wartość jest przekazywana, musi zawierać tylko litery łacińskie, łączniki i podkreślenia.
e-mail. Musi zawierać prawidłowy adres e-mail.
hasło. Musi być zainstalowany i nie dłuższy niż 64 znaki.
Zgoda. Typowy checkbox, który użytkownik musi zaznaczyć, aby potwierdzić zgodę na warunki korzystania z usługi.

$data = [ "name" => "Albert", // Powinno być dwa słowa "login" => "@lbert", // "Zakazany" znak @ "email" => "coś nie tak", / / To powinno być e-mailem "hasło" =>

Filtr Aury

Walidacja za pomocą Aura.Filter zaczyna się od fabryki filtrów. Musimy utworzyć tak zwany „filtr tematyczny”, ponieważ będziemy sprawdzać poprawność tablicy, a nie pojedynczej wartości.

Definiowanie zasad

Jak widać, opis zasad jest dość prosty. Aura.Filter zapewnia cały zestaw przydatnych reguł, a niektóre z nich zostały użyte w powyższym przykładzie:

metoda isNotBlank. Określa, że pole nie może mieć wartości null.
album. Ta reguła dopuszcza tylko litery łacińskie.
e-mail. I takie jasne :)
strlenMax. Określa, że pole nie może przekraczać długości określonej przez drugi argument metody is.
oddzwonić. Ten typ reguły jest podobny do zamknięć z Kontrolio. Pozwala zdefiniować regułę jako zamknięcie. Do tego zamknięcia Aura.Filter przekazuje „subject”, naszą tablicę danych z formularza oraz pole, w tym przypadku uzgodnione.

Drugim krokiem jest powiadomienie fabryki filtrów o naszej nowej zasadzie. Odbywa się to poprzez przekazanie pierwszego argumentu jako tablicy reguł do fabryki filtrów:

Kolejnym krokiem jest powiadomienie Aura.Filter, że stworzyliśmy nową regułę i chcemy jej użyć. Odbywa się to poprzez przekazanie tablicy reguł do pierwszego argumentu fabrycznego:

użyj Aura\Filter\FilterFactory; $rules = [ "two_words" => function() ( zwraca nową regułę nazwy użytkownika; ) ]; $filter = (new FilterFactory($rules))->newSubjectFilter();

Teraz nasza reguła dwa_słowa może być używana tak samo, jak każda inna reguła z dystrybucji standardowej.

Informacja zwrotna

Weryfikujemy za pomocą Aura.Filter w następujący sposób:

$poprawne = $filtr->zastosuj($dane); if (! $poprawne) ( $błędy = $filter->getFailures(); $messages = $błędy->getMessages(); )

W $wiadomości tablica jest zapisana, więc potrzebujemy dwóch zagnieżdżonych fore, aby wyświetlić komunikaty:

$błędy) ( foreach ($błędy jako $błąd) ( printf("", $błąd); ) ) ?>

Szanuj walidację

Drugą biblioteką, której użyłem do porównania, jest stosunkowo popularne rozwiązanie o nazwie Respect Validation. Ponieważ ludzie jej ufają, myślę, że jest tam coś do zobaczenia.

Dla czystości eksperymentu, porównując biblioteki, użyjemy tego samego zbioru danych, który zdefiniowaliśmy na początku:

Definiowanie zasad

Podobnie jak w przypadku Aura.Filter, potrzebujemy własnej reguły sprawdzania poprawności nazwy użytkownika, więc zacznijmy od tego:

użyj Respect\Validation\Exceptions\NestedValidationException; klasa UserNameRuleException rozszerza NestedValidationException ( // )

v::with("MojaPrzestrzeńNazw\\");

Zwróć uwagę, jak stosujemy naszą regułę do atrybutu Nazwa. Tutaj nazwa klasy reguły została przekształcona w nazwę metody walidatora. Reszta zasad jest generalnie intuicyjna.

Informacja zwrotna

Za pomocą pobierzWiadomości(), otrzymamy płaską tablicę wszystkich komunikatów, które walidator zebrał podczas procesu walidacji. Zrzucając tablicę, otrzymujemy coś takiego:

Nie wiem, na czym polega błąd, ale jest kilka rzeczy, których nadal nie rozumiem. Oto, co otrzymamy, definiując reguły w powyższy sposób:

Weryfikacja Syriusza

Ok, przejdźmy do następnej biblioteki i zobaczmy, jak radzi sobie z podobnymi zadaniami.

Definiowanie zasad

Ponownie musimy zdefiniować regułę dla nazwy użytkownika. Napiszemy to mniej więcej tak:

Teraz opiszmy logikę walidacji:

Jak widać, zestaw zasad jest dość prosty i czytelny. W opisach używamy nazw oddzielonych poziomymi kreskami. To podejście jest podobne do tego stosowanego przez Laravel i Kontrolio.

$validator->add("nazwa", "wymagane | MojaAplikacja\Walidacja\Rule\UserNameRule")

Dzieje się tak, ponieważ komunikaty są już opisane w stałych klasach:

class UserNameRule extends AbstractRule ( // Komunikaty o błędach const MESSAGE = "Nazwa użytkownika musi składać się z dwóch słów."; ...

Inną opcją jest użycie metody addMessage() samego walidatora:

$validator->addMessage("email", "Proszę wprowadzić poprawny e-mail.");

Zauważ, że niestandardowe reguły są identyfikowane przez pełną nazwę ich klasy, podczas gdy w Kontrolio możesz ustawić alias/alias.

Informacja zwrotna

Aby przeprowadzić walidację, wywołujemy metodę walidatora uprawomocnić(), przekazując do niego dane:

foreach ($validator->getMessages() as $attribute => $messages) ( foreach ($messages as $message) ( echo $message->getTemplate() . "\n"; ) )

Tutaj $message jest obiektem klasy Syriusz\Walidacja\Komunikat o błędzie, który ma metodę pobierz szablon(), co zwraca dokładnie taką wiadomość, jakiej potrzebujemy.

Walitron

Definiowanie zasad

Pierwsza różnica polega na tym, że nie trzeba tworzyć oddzielnej klasy, aby dodać nową regułę. Możesz po prostu użyć zamknięcia, które zwraca wynik logiczny.

Druga różnica polega na tym, jak reguły są stosowane do atrybutów. We wszystkich poprzednich przypadkach widzieliśmy, że atrybut jest niejako rzeczą podstawową.

Valitron poszedł w drugą stronę i na pierwszym miejscu umieścił zasady walidacji. Opisując reguły, w pewnym sensie stosujesz atrybuty do tych reguł, a nie odwrotnie.

$walidator->reguła("dwa_słowa", "nazwa")->etykieta("")

Informacja zwrotna

$walidator->walidacja();

Komunikaty o błędach sprawdzania poprawności można uzyskać za pomocą metody getErrors():

$walidator->błędy();

foreach ($validator->errors() as $attribute => $messages) ( foreach ($messages as $message) ( echo $message . "\n"; ) )

kontrola

I wreszcie ostatnia biblioteka na dziś to mój własny program o nazwie Kontrolio .

Definiowanie zasad

Ponownie, po raz piąty, utworzymy regułę sprawdzania poprawności nazwy użytkownika. Wszystko jest stosunkowo proste i standardowe:

Teraz tworzymy fabrykę i rejestrujemy w niej regułę za pomocą metody rozszerzyć():

przestrzeń nazw Mój projekt; użyj Control\Factory; użyj MyProject\Validation\Rules\TwoWords; $factory = Kontrolio\Factory::getInstance()->extend();

Po zarejestrowaniu reguły możemy z niej korzystać m.in. po nazwie - two_words . Stwórzmy walidator:

Zasady opisaliśmy używając składni podobnej do tej używanej w Laravelu, chociaż mogliśmy użyć bardziej szczegółowej wersji:

$rules = [ "name" => new TwoWords, "login" => , "email" => new Email, "password" => new Length(1, 64), "agreed" => new Accepted ];

Informacja zwrotna

Walidacja jest uruchamiana tą samą metodą uprawomocnić():

$walidator->walidacja();

z getErrorsList() możesz zrobić prostszą listę wiadomości:

getErrorsList(); ?>

Wynik

W tym artykule pokazałem przykłady wykorzystania następujących bibliotek:

Filtr Aury
Szanuj walidację
Weryfikacja Syriusza
Walitron
kontrola

Każda z bibliotek oferuje swoje chipy, ma swoje ciemne strony, więc myślę, że to kwestia gustu i zadania – wybrać tę właściwą.

Dziękuje za przeczytanie. Dokonać dobrego wyboru.

Tagi: Dodaj tagi

Laravel posiada prosty, wygodny system walidacji (sprawdzanie danych wejściowych pod kątem zgodności z regułami) i odbierania komunikatów o błędach - klasa Validation.

Najprostszy przykład walidacji

$validator = Validator::make(array("nazwa" => "Daleka"), array("nazwa" => "wymagane|min:5"));

Pierwszym parametrem przekazanym do metody make są dane do sprawdzenia. Drugim parametrem są reguły, które należy do nich zastosować.

Używanie tablic do określania reguł

Wiele reguł może być oddzielonych kreską do przodu (|) lub oddzielnymi elementami tablicy.

$validator = Validator::make(array("nazwa" => "Daleka"), array("nazwa" => array("wymagane", "min:5")));

Walidacja wielu pól

$validator = Validator::make(array("nazwa" => "Daleka", "hasło" => "złe hasło", "e-mail" => " [e-mail chroniony]"), array("nazwa" => "wymagane", "hasło" => "wymagane|min:8", "email" => "wymagane|e-mail|unikatowe"));

Po utworzeniu instancji Validator do przeprowadzenia walidacji można użyć metody fails (lub pass) .

If ($validator->fails()) ( // Przekazane dane nie powiodły się podczas sprawdzania poprawności )

Jeśli walidator znalazł błędy, możesz otrzymać następujące komunikaty:

$wiadomości = $walidator->wiadomości();

Możesz także uzyskać tablicę reguł, które nie przeszły weryfikacji bez samych komunikatów:

$niepowodzenie = $walidator->niepowodzenie();

Sprawdzanie plików

Klasa Validator zawiera kilka początkowych reguł sprawdzania poprawności plików, takich jak size , mimes i inne. Aby przeprowadzić walidację plików, po prostu prześlij te pliki wraz z innymi danymi.

Hak po walidacji

Laravel po zakończeniu walidacji może uruchomić Twoją funkcję zamykającą, w której możesz na przykład sprawdzić coś specjalnego lub dodać własny komunikat o błędzie. Odbywa się to za pomocą metody after():

$walidator = Walidator::make(...); $validator->after(function($validator) ( if ($this->somethingElseIsInvalid()) ( $validator->errors()->add("field", "Coś jest nie tak z tym polem!"); ) )); if ($validator->fails()) ( // )

W razie potrzeby możesz dodać wiele po s.

Walidacja w kontrolerach

Pisanie pełnego kodu weryfikacyjnego za każdym razem, gdy trzeba zweryfikować dane, jest niewygodne. Dlatego Laravel udostępnia kilka rozwiązań upraszczających tę procedurę.

Kontroler podstawowy App\Http\Controllers\Controller zawiera cechę ValidatesRequests, która zawiera już metody sprawdzania poprawności:

/** * Zapisz wpis na blogu. * * @param Żądanie $request * @return Response */ public function store(Request $request) ( $this->validate($request, [ "title" => "required|unique|max:255", "body" => "wymagane", ]); // )

Jeśli sprawdzanie poprawności zakończy się pomyślnie, kod będzie nadal działał. Jeśli nie, generowany jest wyjątek Illuminate\Contracts\Validation\ValidationException. Jeśli nie złapiesz tego wyjątku, framework go złapie, wypełni zmienne flasha komunikatami o błędach walidacji i przekieruje użytkownika do poprzedniej strony z formularzem - sam!

W przypadku żądania AJAX nie ma przekierowania, framework zwraca odpowiedź z kodem HTTP 422 i JSON z błędami walidacji.

Powyższy kod jest podobny do tego:

/** * Zapisz wpis na blogu. * * @param Żądanie $request * @return Response */ public function store(Request $request) ( $v = Validator::make($request->all(), [ "title" => "wymagane|unikatowe|maks. :255", "treść" => "wymagane", ]); if ($v->fails()) ( return redirect()->back()->withErrors($v->errors()); ) // )

Zmiany formatu błędu

Jeśli chcesz dostosować komunikaty o błędach sprawdzania poprawności, które są przechowywane w zmiennych flash sesji podczas przekierowań, zastąp metodę formatValidationErrors w swoim kontrolerze:

/** * (@inheritdoc) */ funkcja chroniona formatValidationErrors(\Illuminate\Validation\Validator $validator) ( return $validator->errors()->all(); )

Poproś o weryfikację

W przypadku bardziej złożonych scenariuszy walidacji wygodne mogą być tak zwane Zapytania Formularzowe. Są to specjalne klasy żądań HTTP, które zawierają logikę sprawdzania poprawności. Przetwarzają żądanie, zanim dotrze ono do kontrolera.

Aby utworzyć klasę żądania, użyj polecenia make:request artisan:

php artisan make:request StoreBlogPostRequest

Klasa zostanie utworzona w folderze app/Http/Requests. Dodaj niezbędne reguły sprawdzania poprawności do metody reguł:

/** * Pobierz reguły sprawdzania poprawności, które mają zastosowanie do żądania. * * @return array */ public function rules() ( return [ "title" => "wymagane|unikatowe|maks.:255", "body" => "wymagane", ]; )

Aby framework przechwycił żądanie przed kontrolerem, dodaj tę klasę do argumentów wymaganej metody kontrolera:

Przy odpowiednim wykorzystaniu walidacji żądań możesz być pewien, że w Twoich kontrolerach zawsze znajdują się tylko zweryfikowane dane wejściowe!

Jeśli walidacja się nie powiedzie, framework wypełnia zmienne flash błędami walidacji i zwraca przekierowanie do poprzedniej strony. W przypadku żądania AJAX zwracana jest odpowiedź z kodem 422 i JSON z błędami walidacji.

Kontrola dostępu

Klasy Form Request zawierają również metodę autoryzacji. W tej metodzie można sprawdzić, czy użytkownik ma uprawnienia do wykonania tej akcji, zaktualizować dany zasób. Na przykład, jeśli użytkownik próbuje edytować komentarz do posta, czy jest autorem posta?

/** * Określ, czy użytkownik jest upoważniony do wysłania tego żądania. * * @return bool */ public functionauthorize() ( $commentId = $this->route("comment"); return Comment::where("id", $commentId) ->where("user_id", Auth: :id())->istnieje(); )

Zwróć uwagę na powyższe wywołanie metody route(). Ta metoda daje dostęp do parametrów w adresie URL (w tym przypadku (komentarz)) zdefiniowanym w trasie:

Route::post("komentarz/(komentarz)");

Jeśli metoda Authorize zwróci wartość false, struktura wygeneruje odpowiedź HTTP 403 i natychmiast ją wyśle. Metoda kontrolera nie jest wykonywana.

/** * Określ, czy użytkownik jest upoważniony do wysłania tego żądania. * * @return bool */ funkcja publiczna autoryzuj() ( zwróć prawdę; )

Zmiany formatu błędów w zmiennych Flash

/** * (@inheritdoc) */ funkcja chroniona formatValidationErrors(\Illuminate\Validation\Validator $validator) ( return $validator->errors()->all(); )

Praca z komunikatami o błędach

Po wywołaniu metody message obiektu Validator otrzymasz obiekt MessageBag, który posiada zestaw przydatnych metod dostępu do komunikatów o błędach.

Pobieranie pierwszej wiadomości dla pola

echo $wiadomości->pierwszy("e-mail");

Pobieranie wszystkich komunikatów dla jednego pola

foreach ($messages->get("email") jako $message) ( // )

Pobieranie wszystkich komunikatów dla wszystkich pól

foreach ($messages->all() as $message) ( // )

Sprawdzanie komunikatu dla pola

if ($messages->has("email")) ( // )

Otrzymanie błędu w podanym formacie

echo $messages->first("e-mail", "");

Notatka: Domyślnie posty są formatowane w sposób odpowiedni dla Twitter Bootstrap.

Pobierz wszystkie wiadomości w danym formacie

foreach($wiadomości->wszystko("

:wiadomość

") jako wiadomość $) ( // )

Błędy i wzorce

Po zakończeniu sprawdzania poprawności będziesz potrzebować łatwego sposobu przekazywania błędów do szablonu. Laravel pozwala Ci to zrobić w wygodny sposób. Mamy na przykład takie trasy:

Route::get("register", function() ( return View::make("user.register"); )); Route::post("register", function() ( $rules = array(...); $validator = Validator::make(Input::all(), $rules); if ($validator->fails( )) (redirect redirect("register")->withErrors($validator); ) ));

Zauważ, że gdy kontrole się nie powiodą, przekazujemy obiekt Validator do obiektu Redirect za pomocą metody withErrors. Ta metoda przechowuje komunikaty o błędach w jednorazowych zmiennych sesji flash, dzięki czemu są dostępne dla następnego żądania.

Należy jednak pamiętać, że nie przekazujemy View::make("user.register"); $błędy zmiennych do szablonu. Laravel sam sprawdza dane sesji pod kątem obecności zmiennych i automatycznie przekazuje je do szablonu, jeśli są dostępne. Dlatego ważne jest, aby pamiętać, że zmienna $errors będzie dostępna dla wszystkich szablonów przez cały czas, na każde żądanie. . Pozwala to założyć, że zmienna $errors jest zawsze zdefiniowana i można jej bezpiecznie używać. Zmienna $errors jest instancją klasy MessageBag.

Tym samym po przekierowaniu można skorzystać ze zmiennej $errors ustawionej automatycznie w szablonie:

pierwszy("e-mail"); ?>

Nazwany MessageBag

Jeśli masz wiele formularzy na stronie, możesz wybrać nazwę obiektu MessageBag, w którym będą zwracane teksty błędów, abyś mógł je poprawnie wyświetlić dla żądanego formularza.

Return redirect("register")->withErrors($validator, "login");

Uzyskaj tekst błędu z MessageBag o nazwie login:

Zasady walidacji

Poniżej znajduje się lista wszystkich dostępnych reguł i ich funkcji:

przyjęty

Pole musi zawierać wartość tak, na lub 1 . Jest to przydatne do sprawdzania akceptacji reguł i licencji.

aktywny_url

Pole musi być prawidłowym adresem URL dostępnym za pośrednictwem funkcji checkdnsrr.

po: data

Pole musi być datą późniejszą niż data

alfa

Pole musi zawierać tylko znaki alfabetu.

alfa_kreska

Pole może zawierać tylko znaki alfabetu, cyfry, podkreślenia (_) i łączniki (-).

numer_alfa

Pole musi zawierać tylko litery i cyfry.

szyk

Pole musi być tablicą.

zanim: data

Pole musi być datą wcześniejszą niż data. Ciągi są konwertowane na daty za pomocą funkcji strtotime.

pomiędzy: min,maks

Pole musi mieścić się w zakresie min zanim maks. Ciągi znaków, liczby i pliki są traktowane podobnie jak reguła rozmiaru.

logiczna

Pole musi być logiczne (boolowskie). Dozwolone wartości to true , false , 1 , 0 , "1" i "0" .

Potwierdzony

Wartość pola musi być zgodna z wartością pola o tej nazwie plus foo_confirmation . Na przykład, jeśli sprawdzane jest pole hasła, jako dane wejściowe należy przekazać pasujące pole password_confirmation.

data

Pole musi zawierać prawidłową datę zgodnie z funkcją strtotime.

format daty: format

Pole musi być zgodne z formatem daty format zgodnie z funkcją date_parse_from_format.

różne: pole

Wartość pola podlegającego walidacji musi być różna od wartości pola pole.

e-mail

Pole musi zawierać prawidłowy adres e-mail.

istnieje: stół,kolumna

Pole musi istnieć w określonej tabeli bazy danych.

Proste użycie:

"stan" => "istnieje:stany"

Określanie nazwy pola w tabeli:

"stan" => "istnieje:stany,skrót"

Możesz także określić więcej warunków do dodania do zapytania „WHERE”:

"email" => "exists:personel,email,account_id,1"

obraz

Przesłany plik musi być obrazem w formacie jpeg, png, bmp, gif lub svg.

w: bla,bar,...

Wartość pola musi być jedną z wymienionych ( bla, bar itp.).

liczba całkowita

Pole musi mieć prawidłową wartość całkowitą.

ip

Pole musi zawierać prawidłowy adres IP.

maks: wartość

Wartość pola musi być mniejsza lub równa wartość

mimy: bla,bar,...

Typ MIME przesyłanego pliku musi być jednym z wymienionych.

Proste użycie:

"zdjęcie" => "mimy:jpeg,bmp,png"

min: wartość

Wartość pola musi być większa niż wartość. Linie, liczby i pliki są traktowane podobnie jak pliki .

nie w: bla,bar,...

Wartość pola nie musi być jednym z wymienionych bla, bar itp.).

liczbowy

Pole musi mieć prawidłową wartość liczbową lub ułamkową.

wyrażenie regularne: wzorzec

Pole musi pasować do określonego wyrażenia regularnego.

Uwaga: podczas korzystania z tej reguły może być konieczne wyliczenie innych reguł jako elementów tablicy, zwłaszcza jeśli wyrażenie zawiera znak pionowej kreski (|).

wymagany

Pole podlegające walidacji musi być obecne i mieć niepustą wartość.

wymagane_jeśli: pole,wartość,...

Pole podlegające walidacji musi być obecne i mieć niepustą wartość, jeśli inne pole pole jest obecny i ma dowolną z wartości wartość.

wymagane_z: bla,bar,...

Co najmniej jedno z wymienionych pól jest obecne i ma niepustą wartość ( bla, bar itp.).

wymagane_z_wszystkim: bla,bar,...

Testowane pole musi być obecne i mieć niepustą wartość, ale tylko wtedy, gdy wszystkie wymienione pola są obecne i mają niepustą wartość ( bla, bar itp.).

wymagane_bez: bla,bar,...

Pole podlegające walidacji musi być obecne i mieć niepustą wartość, ale tylko wtedy, gdy nie co najmniej jedno z wymienionych pól jest obecne lub puste ( bla, bar itp.).

wymagane_bez_wszystkiego: bla,bar,...

Pole podlegające walidacji musi być obecne i mieć niepustą wartość, ale tylko wtedy, gdy nie wszystkie wymienione pola są obecne lub puste ( bla, bar itp.).

to samo: pole

Pole musi mieć taką samą wartość jak pole pole.

rozmiar: wartość

Pole musi się zgadzać wartość Rozmiar. Dla stringów oznacza długość, dla liczb- numer, dla plików- rozmiar w kilobajtach.

strefa czasowa

Pole musi zawierać identyfikator strefy czasowej (strefa czasowa), jeden z wymienionych w funkcji php timezone_identifiers_list

unikalny: stół,kolumna,oprócz,idKolumna

Wartość pola musi być unikalna w danej tabeli bazy danych. Jeśli kolumna nie zostanie określona, zostanie użyta nazwa pola.

Łatwe użytkowanie

"email" => "unikatowi:użytkownicy"

Określanie nazwy pola w tabeli

"email" => "unikatowe:użytkownicy,adres_email"

Ignorowanie określonego identyfikatora

"email" => "unique:users,email_address,10"

Dodanie dodatkowych warunków

Możesz także określić więcej warunków do dodania do zapytania „WHERE”:

"email" => "unikatowe:użytkownicy,adres_email,NULL,identyfikator,identyfikator_konta,1"

W powyższej regule tylko wiersze z identyfikatorem konta równym 1 zostaną uwzględnione w sprawdzeniu.

adres URL

Pole musi zawierać prawidłowy adres URL.

Notatka: Używana jest funkcja PHP filter_var

Zasady warunkowe

Czasami trzeba zweryfikować pole tylko gdy jest obecny na wejściu. Aby to zrobić, dodaj regułę czasami:

$v = Validator::make($data, array("email" => "czasami|wymagane|e-mail",));

W powyższym przykładzie pole e-mail uruchomi sprawdzanie poprawności tylko wtedy, gdy istnieje $data["email"].

Złożone reguły warunkowe

Czasami chcesz, aby pole miało wartość tylko wtedy, gdy inne pole ma wartość większą niż, powiedzmy, 100. Możesz też wymagać dwóch pól tylko wtedy, gdy określono również trzecie. Można to łatwo osiągnąć za pomocą reguł warunkowych. Najpierw utwórz obiekt Validator z zestawem reguł statycznych, które nigdy się nie zmieniają:

$v = Validator::make($data, array("email" => "wymagany|e-mail", "gry" => "wymagany|numeryczny",));

Załóżmy teraz, że Twoja aplikacja jest napisana dla kolekcjonerów gier. Jeśli zarejestruje się kolekcjoner z ponad 100 grami, to chcemy go zapytać, dlaczego potrzebuje ich tak wiele. Na przykład mogą mieć sklep lub po prostu cieszyć się ich kolekcjonowaniem. Aby więc dodać taką regułę warunkową, używamy metody Validator.

$v->czasami("powód", "wymagane|maks.:500", function($input) ( return $input->games >= 100; ));

Pierwszym parametrem tej metody jest nazwa sprawdzanego pola. Drugi parametr to reguła, którą chcemy dodać, jeśli przekazana funkcja zamknięcia (trzeci parametr) zwróci true . Ta metoda ułatwia tworzenie złożonych reguł sprawdzania poprawności danych wejściowych. Możesz nawet dodać te same reguły warunkowe do wielu pól jednocześnie:

$v->czasami(array("powód", "koszt"), "wymagane", function($input) ( return $input->games >= 100; ));

Notatka: Parametr $input przekazany do zamknięcia jest obiektem Illuminate\Support\Fluent i może służyć do odczytywania zweryfikowanych danych wejściowych i plików.

Własne komunikaty o błędach

Możesz podać niestandardowe komunikaty o błędach zamiast domyślnych. Można to zrobić na kilka sposobów.

Przekazywanie wiadomości do Walidatora

$messages = array("required" => "Pole:atrybut musi być wypełnione.",); $validator = Validator::make($input, $rules, $messages);

Notatka: string:attribute zostanie zastąpiony nazwą sprawdzanego pola. Możesz także użyć innych ciągów zmiennych.

Korzystanie z innych zmiennych łańcuchowych

$messages = array("same" => "Wartości :attribute i :other muszą być zgodne.", "size" => "Pole:attribute musi być równe dokładnie:size.", "między" => "The:attribute value must be from:min to:max.", "in" => "Pole:attribute musi mieć jedną z następujących wartości: :values",);

Określanie komunikatu niestandardowego dla pojedynczego pola

Czasami może być konieczne podanie niestandardowej wiadomości dla określonego pola.

$messages = array("email.required" => "Musimy znać Twój adres e-mail!",);

Określanie własnych komunikatów w pliku lokalizacyjnym

Możliwe jest również zdefiniowanie komunikatów walidacyjnych w pliku lokalizacyjnym zamiast przekazywania ich bezpośrednio do Walidatora. Aby to zrobić, dodaj komunikaty do niestandardowej tablicy pliku lokalizacyjnego app/lang/xx/validation.php.

"custom" => array("email" => array("required" => "Musimy znać Twój adres e-mail!",),),

Własne zasady walidacji

Rejestrowanie własnej reguły sprawdzania poprawności

Laravel zawiera wiele przydatnych reguł od razu po wyjęciu z pudełka, ale może być konieczne utworzenie własnych. Jednym ze sposobów zarejestrowania dowolnej reguły jest użycie metody Validator::extend.

Walidator::extend("foo", function($atrybut, $wartość, $parametry) ( return $value == "(!LANG:foo"; }); !}

Notatka: nazwa reguły musi być w formacie_with_underscores.

Przekazane zamknięcie wymaga trzech parametrów: nazwy pola $attribute do sprawdzenia, wartości pola $value oraz tablicy parametrów $parameters przekazanych do reguły.

Zamiast funkcji możesz przekazać odwołanie do metody klasy do metody extend:

Walidator::extend("foo", " [e-mail chroniony]");

Należy pamiętać, że konieczne będzie również zdefiniowanie komunikatu o błędzie dla nowej reguły. Możesz to zrobić, przekazując go jako tablicę ciągów znaków do Validator lub zapisując go w pliku lokalizacyjnym.

Rozszerzenie klasy Validator

Zamiast używać funkcji zamknięcia do rozszerzenia zestawu dostępnych reguł, możesz rozszerzyć samą klasę Validator. Aby to zrobić, utwórz klasę, która dziedziczy Illuminate\Validation\Validator . Możesz dodać nowe metody sprawdzania poprawności, zaczynając ich nazwę od validate .

Rejestrowanie nowej klasy walidatora

Następnie musisz zarejestrować to rozszerzenie sprawdzania poprawności. Możesz to zrobić na przykład u swojego usługodawcy lub w plikach startowych.

Validator::resolver(function($translator, $data, $rules, $messages) ( zwraca new CustomValidator($translator, $data, $rules, $messages); ));

Czasami podczas tworzenia własnej klasy walidacji może być konieczne zdefiniowanie własnych łańcuchów zmiennych (takich jak „:foo”), które będą zastępowane w komunikatach o błędach. Odbywa się to poprzez utworzenie klasy zgodnie z powyższym opisem i dodanie funkcji o nazwach takich jak replaceXXX .

Chroniona funkcja replaceFoo($message, $attribute, $rule, $parameters) ( return str_replace(":foo", $parameters, $message); )

Jeśli chcesz dodać swoją wiadomość bez użycia Validator::extend , możesz użyć metody Validator::replacer:

Validator::replacer("reguła", function($message, $attribute, $rule, $parameters) ( // ));