Acasă / Prezentare generală Linux / Validat, validat... și validat! Compararea validatorilor de date în PHP. Validarea și curățarea datelor folosind PHP Insane validation php

Validat, validat... și validat! Compararea validatorilor de date în PHP. Validarea și curățarea datelor folosind PHP Insane validation php

Este foarte esențial să validați datele introduse în formularul dumneavoastră înainte de a prelua datele de trimitere a formularului pentru procesare ulterioară. Când există multe câmpuri în formular, scriptul de validare PHP devine prea complex. Mai mult, deoarece faceți aceeași validare sau similară pentru majoritatea formularelor pe care le faceți, este cheltuit prea mult efort duplicat pentru validările formularelor.

Despre acest script generic de validare a formularelor PHP

Acest script generic de validare a formularelor PHP face foarte ușor să adăugați validări la formularul dvs.

Creăm și asociem un set de „descriptori de validare” cu fiecare element din formular. „Descriptorul de validare” este un șir care specifică tipul de validare care trebuie efectuată. De exemplu, „req” înseamnă obligatoriu, „alpha” înseamnă permite doar caractere alfabetice și așa mai departe.

Fiecare câmp din formular poate avea zero, una sau mai multe validări. De exemplu, intrarea nu trebuie să fie goală, trebuie să aibă mai puțin de 25 de caractere, trebuie să fie alfanumeric etc.

Puteți asocia un set de descriptori de validare pentru fiecare câmp de intrare din formular.

Descărcați scriptul de validare a formularelor PHP

Puteți descărca scriptul de validare a formularelor PHP de mai jos:
Fișierul zip conține scriptul de validare a formularului formvalidator.php, documentație și mostre de utilizare.

Folosind scriptul de validare a formularelor PHP
  • Includeți formvalidator.php în scriptul dvs. de procesare a formularelor
  • require_once "formvalidator.php"
  • Creați un obiect FormValidator și adăugați descriptorii de validare a formularului.
  • $validator = nou FormValidator(); $validator->addValidation("Nume","req","Vă rugăm să completați numele"); $validator->addValidation("E-mail","e-mail", "Intrarea pentru e-mail ar trebui să fie o valoare de e-mail validă"); $validator->addValidation("E-mail","req","Vă rugăm să completați e-mailul");

    Primul argument este numele câmpului de intrare din formular. Al doilea argument este descriptorul de validare care spune tipul de validare necesar. Al treilea argument este mesajul de eroare care trebuie afișat dacă validarea eșuează.

  • Validați formularul apelând funcția ValidateForm().
  • if(!$validator->ValidateForm()) ( echo "Erori de validare:"; $error_hash = $validator->GetErrors(); foreach($error_hash as $inpname => $inp_err) ( echo "

    $inpname: $inp_err

    \n"; ) ) Exemplu

    Exemplul de mai jos va clarifica ideea

    Nume: Email:

    Adăugarea de validare personalizată

    Dacă doriți să adăugați o validare personalizată, care nu este furnizată de descriptorii de validare, puteți face acest lucru. Iată pașii:

  • Creați o clasă pentru validarea personalizată și suprascrieți funcția DoValidate().
  • clasa MyValidator extinde CustomValidator ( funcția DoValidate(&$formars,&$error_hash) ( if(stristr($formars["Comments"],"http://")) ( $error_hash["Comments"]="Nu sunt permise adrese URL în comentarii"; returnează fals; ) returnează adevărat; ))

  • Adăugați obiectul de validare personalizat
  • $validator = nou FormValidator(); $validator->addValidation("Nume","req","Vă rugăm să completați numele"); $validator->addValidation("E-mail","e-mail", "Intrarea pentru e-mail ar trebui să fie o valoare de e-mail validă"); $validator->addValidation("E-mail","req","Vă rugăm să completați e-mailul"); $custom_validator = new MyValidator(); $validator->AddCustomValidator($validator_personalizat);

    Funcția de validare personalizată va fi apelată automat după alte validări.

    Tabelul descriptorilor de validare

    Iată lista tuturor descriptorilor de validare:

    Descriptor de validareUtilizare
    solicitatCâmpul nu trebuie să fie gol
    maxlen=???verifică la maximum lungimea datelor introduse. De exemplu, dacă dimensiunea maximă permisă este 25, dați descriptorul de validare „maxlen=25”
    minlen=???verifică lungimea șirului introdus la minimul necesar. exemplu „minlen=5”
    alnumVerificați datele dacă conțin alte caractere decât caracterele alfabetice sau numerice
    alnum_sPermite numai caractere alfabetice, numerice și spațiale
    numVerificați datele numerice
    alfaVerificați datele alfabetice.
    alfa_sVerificați datele alfabetice și permiteți spații.
    e-mailCâmpul este un câmp de e-mail și verifică validitatea datelor.
    lt=???
    mai putin de=???
    Verificați ca datele să fie mai mici decât valoarea transmisă. Valabil numai pentru câmpurile numerice.
    exemplu: dacă valoarea ar trebui să fie mai mică de 1000, dați descrierea de validare ca „lt=1000”
    gt=???
    mai mare de=???
    Verificați ca datele să fie mai mari decât valoarea transmisă. Valabil numai pentru câmpurile numerice.
    exemplu: dacă valoarea ar trebui să fie mai mare de 10, dați descrierea validării ca „gt=10”
    regexp=???Verificați cu o expresie regulată valoarea ar trebui să se potrivească cu expresia regulată.
    exemplu: „regexp=^(1.20)$” permite până la 20 de caractere alfabetice.
    dontselect=??Acest descriptor de validare este pentru elementele de intrare selectate (liste). În mod normal, casetele cu listă selectate vor avea un articol care spune „Selectați unul”. Utilizatorul ar trebui să selecteze o altă opțiune decât această opțiune. Dacă valoarea acestei opțiuni este „Select One”, descrierea de validare ar trebui să fie „dontselect=Select One”
    dontselectchkAcest descriptor de validare este pentru casetele de selectare. Utilizatorul nu trebuie să bifeze caseta de selectare dată. Furnizați valoarea casetei de selectare în loc de ??
    De exemplu, dontselectchk=on
    shouldselchkAcest descriptor de validare este pentru casetele de selectare. Utilizatorul ar trebui să selecteze caseta de selectare dată. Furnizați valoarea casetei de selectare în loc de ??
    De exemplu, shouldselchk=on
    dontselectradioAcest descriptor de validare este pentru butoanele radio. Utilizatorul nu trebuie să selecteze butonul radio dat. Furnizați valoarea butonului radio în loc de ??
    De exemplu, dontselectradio=NU
    selectradioAcest descriptor de validare este pentru butoanele radio. Utilizatorul trebuie să selecteze butonul radio dat. Furnizați valoarea butonului radio în loc de ??
    De exemplu, selectradio=yes
    selmin=??Selectați cel puțin n număr de casete de selectare dintr-un grup de casete de selectare.
    De exemplu: selmin=3
    seloneFace obligatoriu un grup radio. Utilizatorul ar trebui să selecteze cel puțin un articol din grupul radio.
    eqelmnt=???comparați două elemente din formular și asigurați-vă că valorile sunt aceleași. De exemplu, „parolă” și „confirmați parola”. Înlocuiește ??? cu numele celuilalt element de intrare.
    De exemplu: eqelmnt=confirm_pwd

    Într-un articol anterior am promis că voi scrie o comparație a propriei biblioteci cu alte soluții disponibile, așa că astăzi ne vom uita la validarea folosind Aura.Filter, Respect Validation, Sirius Validation și Valitron.


    Să ne imaginăm că avem un anumit serviciu public în dezvoltare care presupune înregistrarea utilizatorilor pentru acces complet la toate functiile. Astfel, formularul de înregistrare va conține următoarele câmpuri:

  • nume. Trebuie să conțină exact două cuvinte, unde primul este prenumele utilizatorului și al doilea este numele de familie.
  • log in. Dacă se transmite o valoare, aceasta trebuie să conțină numai litere latine, cratime și liniuțe de subliniere.
  • e-mail. Trebuie să conțină o adresă validă e-mail.
  • parolă. Trebuie să fie setat și să nu aibă mai mult de 64 de caractere.
  • a fost de acord.
  • O casetă de selectare tipică pe care un utilizator trebuie să o bifeze pentru a confirma acceptarea termenilor și condițiilor.


    Deci, avem cinci câmpuri pe care utilizatorul trebuie să le completeze pentru a se înregistra la serviciul nostru imaginar. Să ne imaginăm că am primit date complet nevalide ca intrare:

    $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail „parolă” => Aura.Filter

    Validarea folosind Aura.Filter începe cu o fabrică de filtre. Trebuie să creăm un așa-numit „filtru de subiect”, deoarece vom valida o matrice, nu o valoare individuală.

    Definim regulile de utilizare Aura\Filter\FilterFactory; $filtru = (nou FilterFactory)->newSubjectFilter(); $filtru->validate(„nume”) ->isNotBlank() ->is(„două_cuvinte”) ->setMessage(„Numele trebuie să fie de două cuvinte.”); $filter->validate("login") ->isBlankOr("alnum") ->setMessage("Dacă specificați un login, acesta trebuie să conțină doar caractere latine."); $filter->validate("email") ->isNotBlank() ->is("email") ->setMessage("Vă rugăm să introduceți o adresă de e-mail validă."); $filter->validate("parola") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Vă rugăm să scrieți parola."); $filtru->validate(„de acord”) ->is(„callback”, function($subiect, $câmp) ( return $subiect->($câmp) === adevărat; ))->setMessage(„Ai nevoie de sunt de acord cu termenii și condițiile.”);

  • După cum puteți vedea, descrierea regulilor este destul de simplă. Aura.Filter oferă un întreg set de reguli utile din cutie, iar unele dintre ele au fost folosite în exemplul de mai sus:
  • metoda isNotBlank.
  • Specifică faptul că câmpul nu poate avea o valoare nulă.
  • alnum.
  • Această regulă permite doar litere latine. e-mail. Și e atât de clar :) strlenMax.
  • Probabil ați observat că nu am specificat regula două_cuvinte. Desigur, nu există o astfel de regulă în Aura.Filter, așa că trebuie să creăm una. După cum spune documentația, acest lucru se face folosind o clasă separată pentru regulă:


    /** * Regula care validează numele de utilizator.

    * Numele de utilizator este format din două cuvinte: nume și prenume, separate printr-un spațiu.


    */ class UserNameRule ( /** * Validează numele utilizatorului. * * @param object|array $subiect * @param șir $câmp * @param int $max * * @return bool */ funcție publică __invoke($subiect, $ câmp , $max = nul) ( $valoare = $subiect->($câmp); if (! is_scalar($value)) ( return false; ) return (bool) preg_match("/^+\s+$/u" , $valoare);


    Al doilea pas este să informați fabrica de filtre despre noua noastră regulă. Se face prin trecerea primului argument ca o matrice de reguli către fabrica de filtre:

    Următorul pas este să anunțăm Aura.Filter că am creat o nouă regulă și dorim să o folosim. Acest lucru se face prin trecerea unui set de reguli la primul argument al fabricii:

    utilizați Aura\Filter\FilterFactory; $rules = [ "două_cuvinte" => function() ( returnează o nouă regulă UserName; ) ]; $filtru = (nou FilterFactory($reguli))->newSubjectFilter();

    Acum regula noastră two_words poate fi folosită în același mod ca orice altă regulă standard.


    Feedback


    După cum vă amintiți, datele primite pe care le validăm sunt complet invalide, deoarece fiecare câmp conține o valoare incorectă sau nu o conține deloc. Prin urmare, se presupune că în urma validării vom primi erori și mesaje corespunzătoare despre acestea.

    Validăm cu Aura.Filter după cum urmează: $valid = $filtru->aplica($date); dacă (! $valid) ( $eșecuri = $filtru->getEșecuri(); $mesaje = $eșecuri->getMessages(); )ÎN


    $mesaje

    se scrie o matrice, deci pentru a afișa mesaje avem nevoie de două imbricate pentru fiecare:


    Respectați validarea


    utilizați Respect\Validation\Validator ca v; $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail aici "parola" => "" // Parola nu este specificată deloc // "de acord" nu este în matrice deoarece utilizatorul nu a bifat caseta ];

    Definirea regulilor


    Ca și în cazul Aura.Filter, avem nevoie de propria noastră regulă de validare pentru numele de utilizator, așa că să începem de acolo:

    namespace MyNamspace; utilizați Respect\Validation\Rules\AbstractRule; clasa UserNameRule extinde AbstractRule (funcția publică validate($input) ( return (bool) preg_match("/^+\s+$/u", $input); ) )


    API-ul regulilor externe este aproape identic cu Aura.Filter, doar metoda validate() este folosită în loc de magia __invoke(). Mi s-a părut, acest API, mai simplu și mai ușor de înțeles. Ei bine, este mai aproape de Kontrolio :).


    Nu am găsit nicio mențiune despre acest lucru în documentație, cu toate acestea, pe lângă regula în sine, trebuie să creați propriul tip de excepție pentru aceasta. Numele clasei de excepție trebuie să fie format din numele clasei de reguli și un postfix

    Excepţie


    utilizați Respect\Validation\Exceptions\NestedValidationException; clasa UserNameRuleException extinde NestedValidationException ( // )

    Ei bine, în sfârșit ne putem valida datele. În primul rând, transmitem noua noastră regulă validatorului, astfel încât el să știe despre ea și să o putem folosi în viitor. În Respect Validation, acest lucru se face prin apelarea metodei with(), trecând spațiul de nume în care se află regulile non-standard. v::with("MyNamspace\\"); Acum toate regulile non-standard situate în spațiul de nume


    MyNamspace

    , va fi „recunoscut” de validator. Următorul pas este de a descrie regulile necesare și de a efectua validarea. v::attribute(„nume”, v::userNameRule()) ->atribut(„login”, v::alnum(„-_”)) ->atribut(„e-mail”, v::email()) ->atribut(„parolă”, v::notEmpty()->stringType()->lungime(null, 64)) ->atribut(„de acord”, v::trueVal()) ->assert((obiect) $date); Observați cum ne aplicăm regula atributului


    nume . Aici numele clasei de reguli a fost transformat în numele metodei validatorului. Restul regulilor sunt, în general, intuitive. Merită menționat separat de ce oferim matricea

    utilizați Aura\Filter\FilterFactory; $rules = [ "două_cuvinte" => function() ( returnează o nouă regulă UserName; ) ]; $filtru = (nou FilterFactory($reguli))->newSubjectFilter();

    Spre deosebire de Aura.Filter, validatorul Respect lansează o excepție atunci când validarea eșuează. Și această excepție conține mesaje de eroare de validare. Prin urmare, exemplul care tocmai a fost arătat ar trebui scris după cum urmează:


    încercați ( v::with("RespectValidationExample\\"); v::attribute("nume", v::userNameRule()) ->attribute("login", v::alnum("-_")) - >atribut(„e-mail”, v::email()) ->atribut(„parolă”, v::notEmpty()->stringType()->lungime(null, 64)) ->atribut(„de acord”, v::trueVal()) ->assert((obiect) $date ) catch (NestedValidationException $ex) ( $mesaje = $ex->getMessages(); )

    Folosind getMessages() vom obține o matrice plată a tuturor mesajelor pe care validatorul le-a colectat în timpul procesului de validare. Prin descărcarea matricei, obținem ceva de genul acesta:


    array(5) ( => șir(29) „Validarea datelor a eșuat pentru %s” => șir(60) „autentificarea trebuie să conțină numai litere (a-z), cifre (0–9) și „-_”” => șir (25) „e-mailul trebuie să fie un e-mail valid” => string(26) „parola nu trebuie să fie goală” => string(32) „Atributul convenit trebuie să fie prezent” )

    Puteți schimba mesajele în propriile dvs. Poate că am înțeles cumva greșit această bibliotecă, dar acest proces nu mi s-a părut atât de evident: trebuie să utilizați metoda findMessages() pe o excepție gestionată, în care definiți mesajele nu pentru atribute, ci pentru reguli.


    $ex->findMessages([ "userNameRule" => "Numele de utilizator trebuie să fie format din două cuvinte.", "alnum" => "Nu ne place datele dvs. de conectare.", "email" => "Evident că nu vă place vrei să ne dai e-mail-ul tău.", "notEmpty" => "Ei bine, unde este parola ta?", "agreed" => "Păcat că nu ești de acord." ]);

    Nu știu ce e în neregulă, dar sunt câteva lucruri pe care încă nu le înțeleg. Aceasta este ceea ce obținem prin definirea regulilor în modul de mai sus:


    array(5) ( => string(40) „Numele de utilizator trebuie să fie din două cuvinte.” => string(31) „Nu ne place datele tale de conectare.” => string(25) „e-mailul trebuie să fie un e-mail valid” = > string(5) „Ei bine, unde este parola ta?” => string(9) „Este păcat că nu ești de acord.”

    După cum puteți vedea, mesajul pentru câmpul de e-mail nu a fost aplicat, a rămas cel standard. Dar mesajul de la indexul 4 este invers! Și asta în ciuda faptului că nu am folosit numele regulii, ci numele câmpului. În timp ce dacă aș fi folosit numele regulii (trueVal), mesajul meu s-ar fi pierdut undeva. Comentariile utilizatorilor experimentați ai acestei biblioteci sunt binevenite.

    Validare Sirius

    Ok, să trecem la următoarea bibliotecă și să vedem cum se descurcă cu sarcini similare.

    Definirea regulilor

    Încă o dată trebuie să definim o regulă pentru numele de utilizator. Vom scrie cam așa:


    clasa UserNameRule extinde AbstractRule ( // Mesaje de eroare const MESSAGE = "Numele de utilizator trebuie să fie din două cuvinte."; const LABELED_MESSAGE = "(eticheta) trebuie să fie două cuvinte."; funcția publică validate($value, $valueIdentifier = null ) ( return (bool) preg_match("/^+\s+$/u", $valoare) )

    Vă rugăm să rețineți diferența de abordări față de bibliotecile deja discutate. Definim două tipuri de mesaje în constante, mai degrabă decât să folosim proprietăți, metode sau argumente de regulă.


    Acum să descriem logica de validare:


    $validator = validator nou; $validator ->add(„nume”, „obligatoriu | MyApp\Validation\Rule\UserNameRule”) ->add(„login”, „obligatoriu | alphanumhyphen”, null, „Autentificarea poate conține numai litere latine, liniuțe și litere de subliniere. ") ->add("e-mail", "obligatoriu | e-mail", null, "Vă rugăm să introduceți un e-mail corect.") ->add("parolă", "obligatoriu | lungime maximă(64)", null, "Dvs. parola, domnule.") ->add("de acord", "necesar | egal(adevărat)", null, "De ce nu ați fost de acord?");

    După cum puteți vedea, setul de reguli este foarte simplu și ușor de citit. Pentru descriere, folosim nume separate prin bare orizontale. Această abordare este similară cu cea utilizată în Laravel și Kontrolio.


    Al patrulea argument al metodei add() descrie mesajul de eroare de validare pe care Sirius îl va folosi dacă validarea eșuează. De ce nu am adăugat un mesaj pentru noua noastră regulă? UserNameRule?


    $validator->add ("nume", "necesar | MyApp\Validation\Rule\UserNameRule")

    Acest lucru se datorează faptului că mesajele sunt deja descrise în constantele clasei:


    clasa UserNameRule extinde AbstractRule ( // Mesaje de eroare const MESSAGE = "Numele de utilizator trebuie să conțină două cuvinte."; ...

    O altă opțiune este să utilizați metoda addMessage() a validatorului însuși:


    $validator->addMessage("e-mail", "Vă rugăm să introduceți un e-mail valid.");

    Vă rugăm să rețineți că regulile personalizate sunt identificate prin numele complet al clasei lor, în timp ce în Kontrolio puteți specifica un alias/alias.

    utilizați Aura\Filter\FilterFactory; $rules = [ "două_cuvinte" => function() ( returnează o nouă regulă UserName; ) ]; $filtru = (nou FilterFactory($reguli))->newSubjectFilter();

    Pentru a efectua validarea, apelăm metoda validatorului validate() , transmițându-i datele:


    $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail aici "parola" => "" // Parola nu este specificată deloc // "de acord" nu este în matrice deoarece utilizatorul nu a bifat caseta ]; $validator->validate($date);

    Spre deosebire de Respect, Sirius nu va face o excepție, ci pur și simplu se va întoarce fals. Mesajele de eroare de validare pot fi obținute prin metoda de validare getMessages(). Returnează erori grupate după atribute, așa că avem nevoie de două bucle foreach pentru a trece prin erori:


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

    Aici $message este un obiect de clasă Sirius\Validation\ErrorMessage, care are o metodă getTemplate() care returnează chiar mesajul de care avem nevoie.

    Valitron Definirea regulilor

    Prima diferență: pentru a adăuga o nouă regulă, nu trebuie să creați o clasă separată. Puteți utiliza pur și simplu o închidere care returnează un rezultat boolean.


    Pentru a adăuga reguli personalizate, Valitron are o metodă statică addRule(), în care primele două argumente sunt necesare, iar al treilea este opțional. Mi-a plăcut această metodă, deoarece aici identificatorul regulii, logica și mesajul de eroare sunt indicate într-un singur loc.


    utilizați Valitron\Validator; Validator::addRule("două_cuvinte", function($câmp, $valoare) ( ​​return (bool) preg_match("/^+\s+$/u", $value); ), "Numele de utilizator trebuie să fie format exact din două cuvinte ");

    A doua diferență este modul în care regulile sunt aplicate atributelor. În toate cazurile anterioare, am văzut că un atribut este, parcă, un lucru primar.


    Valitron a luat o altă cale și a pus regulile de validare pe primul loc. Descriind reguli, se pare că aplicați atribute acestor reguli și nu invers.


    $validator = validator nou($date); $validator ->rule("două_cuvinte", "nume")->label("") ->rule("obligatoriu", [ "nume", "autentificare", "e-mail", "parolă", "de acord" ] ) ->rule("slug", "login") ->rule ("e-mail", "email") ->rule ("acceptat", "acordat");

    După cum se poate observa din exemplu, în metoda rule() scriem mai întâi numele regulii și abia apoi indicăm atributele care trebuie să corespundă acestei reguli. Un exemplu mai explicit este regula necesară, care arată cum atributele „aparțin” acelei reguli.


    Valitron (ca și alte soluții pe care le-am analizat) oferă mesaje de eroare standard. Dacă doar le folosiți, veți vedea că fiecare mesaj începe cu numele atributului corespunzător.


    Valitron înlocuiește numele atributelor în textul mesajului chiar și atunci când sunt utilizate mesaje de eroare non-standard. De aceea am folosit metoda label() cu un șir gol pentru a elimina numele atributului.


    $validator->rule("două_cuvinte", "nume")->label("") Feedback

    În ceea ce privește validarea, API-ul bibliotecii Valitron nu este practic diferit de ceea ce am văzut deja în articol. Pentru a efectua validarea apelăm metoda validatorului validate() :


    $validator->validate();

    Mesajele de eroare de validare pot fi preluate folosind metoda getErrors():


    $validator->erori();

    Mesajele de aici sunt grupate după atribute în același mod ca în Validarea Sirius, cu excepția faptului că nu există o clasă separată pentru mesaj și obținem o matrice multidimensională obișnuită.


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

    Și, în sfârșit, ultima bibliotecă de astăzi este propria mea dezvoltare numită Kontrolio.

    Definirea regulilor

    Din nou, pentru a cincea oară, vom crea o regulă de validare pentru numele de utilizator. Totul este relativ simplu și standard:


    spațiu de nume MyProject\Validation\Rules; utilizați Kontrolio\Rules\AbstractRule; clasa TwoWords extinde Controlul\Rules\AbstractRule (funcția publică esteValid($input = null) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

    Acum creăm o fabrică și înregistrăm o regulă în ea folosind metoda extend():


    spațiu de nume MyProject; utilizați Kontrolio\Factory; utilizați MyProject\Validation\Rules\TwoWords; $factory = Control\Factory::getInstance()->extend();

    După înregistrarea regulii, o putem folosi, inclusiv după nume - two_words. Să creăm un validator:


    $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail aici "parola" => "" // Parola nu este specificată deloc // "de acord" nu este în matrice deoarece utilizatorul nu a bifat caseta ]; $rules = [ "nume" => "două_cuvinte", "login" => "uneori|alphadash", "email" => "e-mail", "parolă" => "lungime: 1,64", "de acord" => " acceptat"]; $messages = [ "name" => "Numele de utilizator trebuie să fie format din două cuvinte.", "login" => "Nu ne place datele dvs. de conectare.", "email" => "Evident că nu doriți să oferiți trimite-ne adresa ta de e-mail .", "password" => "Ei bine, unde este parola ta?", "agreed" => "Pacat ca nu esti de acord." ]; $validator = $fabrica->make($date, $reguli, $mesaje);

    Am descris regulile folosind o sintaxă similară cu cea folosită în Laravel, deși am fi putut folosi o versiune mai verbosă:


    $rules = [ "nume" => DouăCuvinte noi, "login" => , "email" => e-mail nou, "parolă" => Lungime nouă (1, 64), "de acord" => nou Acceptat ];

    Feedback


    $validator->validate();

    Validarea este începută folosind aceeași metodă validate():



    Acum putem primi mesaje de eroare folosind una dintre metodele getErrors() sau getErrorsList(). Prima metodă permite o ieșire de eroare mai complexă, în timp ce a doua returnează un tablou plat. Folosind getErrors() putem scoate mesaje ca acesta:


    Și cu getErrorsList() puteți face o listă mai simplă de mesaje:

    Concluzie

  • În acest articol am arătat exemple de utilizare a următoarelor biblioteci:
  • Aura.Filtru
  • Respectați validarea
  • Validare Sirius
  • Valitron
  • controla


    Un „exemple din lumea reală” poate părea prea simplu. Trebuie să fiu de acord, deoarece, într-adevăr, unele capabilități ale bibliotecii au fost lăsate în afara articolului. În principiu, dacă ești interesat, le poți studia singur trăsăturile.


    Fiecare dintre biblioteci oferă propriile sale caracteristici și are părțile sale întunecate, așa că cred că este o chestiune de gust și provocare să o alegi pe aceea.

    Multumesc pentru lectura. Faceți alegerea corectă.

    Etichete: Adăugați etichete

    Bună seara tuturor (mai degrabă noaptea - nota editorului). Astăzi îl vom îmbunătăți puțin pe acesta. Mai întâi, să învățăm cum să facem validarea formularelor în PHP și să facem câteva manipulări de securitate.

    Deci, uitați-vă la codul de mai jos și rețineți următoarele modificări și următoarele motive pentru modificări. Am evidențiat toate liniile noi cu culoare.

    Numele câmpurilor formularului a fost schimbat. Vă puteți întreba – de ce naiba avem nevoie de asta? E simplu, iti raspund. Din câte știu, unii roboți de spam caută formulare pe site-uri și le completează pe baza numelor acestor câmpuri. În teorie, dacă nu găsesc o potrivire, atunci pleacă acasă, ceea ce ne dorim. Desigur, nu cred că gradul acestei protecție este deosebit de mare, dar nu ne va răni, iar dacă e-mailurile spam scad cu 1 literă, va fi bine =). Verificați dacă adresa de e-mail este introdusă corect. Linia 17 folosește operatorul elseif, care va fi verificat dacă dacă ni se returnează un răspuns pozitiv, adică spunea că adresa de e-mail lipsește deloc, adică nu a fost introdusă. Aici folosim funcția preg_match, care ne permite să comparăm adresa introdusă cu expresie regulată . Poate voi scrie pe scurt despre expresiile regulate mai târziu, dar deocamdată merită să știm că creează un șablon față de care este verificat șirul nostru. Și dacă, în cazul nostru, adresa introdusă nu se potrivește cu expresia, atunci din nou va fi afișată o eroare. De exemplu, iată mai multe expresii regulate:
    |^[-а-яе\s\.,;:\?!]+$|i– această expresie regulată vă permite să utilizați doar alfabetul rus și unele caractere precum spațiu, punct, virgulă etc.
    #http://[-a-z0-9_.]+[-a-z0-9_:@&?=+,.!/~*’%$]*\.(html?|php)#i– iar această expresie vă permite să verificați ortografia corectă a unei adrese pe Internet.

    Apoi, folosim operatorul else, unde tot codul nostru pentru trimiterea unei scrisori a fost deja transferat. Puteți crea singur reguli de verificare în orice cantitate, doar adăugați altele noi dacă, de exemplu, pentru verificarea unei adrese de e-mail, și veți fi mulțumit.




    Persoana de contact:



    E-mail de contact:



    Mesaj:






    Acesta este modul în care vă puteți valida formularele PHP fără a apela la ceva străin. Data viitoare, într-o postare pe tema formularelor, cred că se va lua în considerare validarea formularelor în jQuery. Între timp, aștept comentariile și urările voastre. Noapte buna si dimineata buna tuturor =).

    Vom vorbi despre validarea datelor POST sau GET, deși în principiu aceasta poate fi aplicată și datelor primite prin alte metode, precum cookie-urile. Pe măsură ce dezvoltați orice aplicație web, trebuie să scrieți o interfață pentru interacțiunea cu utilizatorii și să creați în mod natural diverse formulare pentru ca utilizatorii să trimită date către server. de exemplu, acestea ar putea fi comentarii. Cred că este clar și evident pentru toată lumea că datele primite trebuie verificate pentru a vedea dacă corespund tipului, mărimii și intervalului specificat. În primul rând, acest lucru este necesar pentru securitatea sistemului, a site-ului web sau a bazei de date, deoarece... Datele transmise incorect sau o solicitare deliberat prost formată pot deschide accesul unui atacator.

    În al doilea rând, datele neverificate, dacă sunt incorecte, pot provoca o funcționare instabilă a scriptului, a sistemului sau a întregului server. Prin urmare, toate datele trebuie verificate și verificate de două ori, poate cineva va spune că nu este nevoie de paranoia excesivă, dar cred că în această chestiune pur și simplu nu poate fi excesivă.

    Nu aveți încredere în datele primite de la utilizatori, sub niciun pretext, sub nicio circumstanță. Se întâmplă că pur și simplu suntem prea leneși să scriem cod care verifică încă o dată datele primite, sau sperăm că metode existente verificarea este suficientă, drept urmare ne facem concesii.

    O mică digresiune de la subiect:
    Lucrul la proiecte, dezvoltarea și programarea de site-uri web, scripturi și alte sisteme îmi ocupă aproape tot timpul liber (în afară de timpul de lucru), cu alte cuvinte, fac această muncă pentru numărul maxim posibil de ore pe zi. Din când în când este nevoie de a testa ceva, pentru distracție sau doar curiozitate. Drept urmare, site-urile realizate în grabă, folosind motoare de casă sau CMS din versiuni antice, devin șobolani de laborator similari de testare. Desigur, toate cele de mai sus suferă de cod scris strâmb, lipsa controlului datelor și pur și simplu plin de diverse erori. De fapt, în majoritatea cazurilor, într-o oră de experimente pe astfel de site-uri, reușesc să găsesc câteva vulnerabilități grave, iar cele mai multe constau în validarea insuficientă a datelor primite. ÎN în ultima vreme Acest lucru se găsește adesea în scripturile care procesează date POST care provin din JavaScript + Ajax.

    Aparent, programatorii care au scris aceste scripturi folosind Ajax cred că, deoarece toate solicitările apar în fundal, fără știrea utilizatorului sau pur și simplu fără a reîncărca pagina, atunci datele nu trebuie verificate în mod special.

    De regulă, destul de multe dintre aceste scripturi se dovedesc a fi atât de pline de găuri încât, fără prea mult efort, reușesc să facă o gaură mai mare și să-și inunde coaja. desigur, doar în scopul experimentării și nimic mai mult (administrarea unor astfel de site-uri este întotdeauna informată despre vulnerabilitățile existente).

    Cred că importanța validării este clară pentru toată lumea. Multă vreme, am scris aceeași bucată de cod de fiecare dată, apoi am folosit propriile funcții de validare a datelor, dintre care multe erau foarte primitive și, de obicei, împrăștiate diferite părți fisiere (atasate). Curând am început să fac cunoștință cu cadrele PHP Zend, CI, Kohana, fiecare dintre acestea implementând propria sa clasă de validare a datelor pe care le-am împrumutat pentru proiectele mele. În cele din urmă, am decis să adaptez una dintre clasele de CI după nevoile mele, dar s-a dovedit că autorul unuia dintre blogurile de programare se ocupase deja de asta. În continuare, împărtășesc lucrările lui, și anume biblioteca modificată CodeIgniter.

    Să ne uităm la următorul cod:

    Vedeți codul PHP

    require_once "validator.class.php" ;

    $validator = nou Validator() ; $validator -> set_rules ("nume" , "Numele dvs." , matrice ("necesar" => , "alpha" => ) ) ;$validator -> set_rules ("email" , "E-mailul dvs." , array ("required" => "Câmpul %s este necesar" , "valid_email" => ) ) ; if ($validator -> run () ) ( echo "Validarea a avut succes" ; ) else ( echo $validator -> get_string_errors () ; ).
    După cum puteți vedea din exemplu, în prima linie includem fișierul de clasă validator.calss.php la scenariul nostru. Apoi, creăm o instanță a clasei și salvăm obiectul într-o variabilă

    $validator

  • Apoi folosind metoda$validator->set_rules($câmp, $label, $rules)
  • setați câmpurile pentru validare. Această metodă ia 3 parametri:
  • $câmp- numele câmpului de validare (valoarea atributului nume din etichetă)
  • $label - numele câmpului de validare, va fi inserat în mesajele de eroare$reguli - o serie de reguli de validare, în care regula de validare este folosită ca cheie, iar mesajul de eroare pentru această regulă este folosit ca valoare După ce toate câmpurile pentru validare sunt setate, lansăm validatorul folosind metoda $validator->run().

    . Dacă validarea a avut succes, această metodă va returna valoarea

  • ADEVĂRAT, în caz contrar, dacă există erori, va reveni
  • FALS Există trei metode de a primi mesaje de eroare:
  • get_string_errors()- returnează toate mesajele de eroare ca șir
  • get_array_errors() — returnează toate mesajele ca o matrice, unde numele câmpului este folosit ca cheie și descrierea erorii pentru acest câmp este folosită ca valoare. form_error($câmp)- returnează un mesaj de eroare pentru câmpul trecut ca parametru $field

    În mod implicit, mesajele de eroare sunt împachetate într-o etichetă . Pentru a vă configura designul, utilizați metoda set_error_delimiters($prefix, $sufix) . De exemplu astfel:

    Acum mesajele de eroare se vor transforma în

    Vedeți codul PHP

    div

    cu clasa "eroare" După cum puteți vedea, totul este foarte simplu.

    Vedeți codul PHP

    $rules = array ( array ( "field" => "name" , "label" => "Numele dvs." , "rules" => array ( "required" => "Câmpul %s este obligatoriu" , "alpha" = > „Câmpul %s trebuie să conțină numai litere” ), matrice ( „field” => „e-mail” , „label” => „E-mailul dvs.” , „rules” => matrice ( „required” => „Câmpul % s este obligatoriu" , "valid_email" => "Câmpul %s trebuie să conțină o adresă de e-mail validă" ) ) ) ;

    $validator -> set_rules ($rules ) ;

    După cum puteți vedea, am notat aceleași reguli de validare ca în primul exemplu, doar sub forma unui tablou asociativ multidimensional. Puteți folosi oricare dintre metodele care vi se potrivesc cel mai bine într-o situație dată.

    Deci, ce reguli de validare acceptă această clasă? Am adus la această clasă cele mai comune reguli de validare pe care le întâlnește toată lumea. Aici lista completa

    aceste reguli:necesar
    Returnează FALSE dacă câmpul este golîntreg
    Returnează FALSE dacă valoarea nu este un număr întregplutire
    Returnează FALSE dacă valoarea nu este o valoare numericăvalid_url
    Returnează FALSE dacă valoarea nu este o adresă URL validăe-mail_valid
    Returnează FALSE dacă valoarea nu este o adresă de e-mail validăvalid_ip
    Returnează FALSE dacă adresa IP nu este validăchibrituri
    Returnează FALSE dacă elementul nu se potrivește cu valoarea altui element de câmpalfa
    Returnează FALSE dacă elementul conține mai mult decât literevalid_captcha
    Returnează FALSE dacă valoarea din câmpul sesiune nu este egală cu valoarea câmpului formulardata_validă

    Returnează FALSE dacă elementul conține o dată nevalidă

    Majoritatea acestor reguli folosesc filtre, care au devenit disponibile în PHP 5.

    Dacă doriți, puteți oricând extinde setul de reguli pentru validare adăugând funcțiile necesare la clasa Validator.

    Vedeți codul PHP

    Pentru a obține valoarea datelor POST procesate, utilizați următoarea metodă:


    Într-un articol anterior am promis că voi scrie o comparație a propriei biblioteci cu alte soluții disponibile, așa că astăzi ne vom uita la validarea folosind Aura.Filter, Respect Validation, Sirius Validation și Valitron.


    De obicei, această metodă este apelată pentru a șterge formularul după procesarea cu succes a formularului.

  • nume. Trebuie să conțină exact două cuvinte, unde primul este prenumele utilizatorului și al doilea este numele de familie.
  • log in. Dacă se transmite o valoare, aceasta trebuie să conțină numai litere latine, cratime și liniuțe de subliniere.
  • Să ne imaginăm că avem un anumit serviciu public în dezvoltare care impune utilizatorilor să se înregistreze pentru acces deplin la toate funcțiile. Astfel, formularul de înregistrare va conține următoarele câmpuri:
  • parolă. Trebuie să fie setat și să nu aibă mai mult de 64 de caractere.
  • a fost de acord.
  • O casetă de selectare tipică pe care un utilizator trebuie să o bifeze pentru a confirma acceptarea termenilor și condițiilor.


    Deci, avem cinci câmpuri pe care utilizatorul trebuie să le completeze pentru a se înregistra la serviciul nostru imaginar. Să ne imaginăm că am primit date complet nevalide ca intrare:

    $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail „parolă” => Aura.Filter

    Validarea folosind Aura.Filter începe cu o fabrică de filtre. Trebuie să creăm un așa-numit „filtru de subiect”, deoarece vom valida o matrice, nu o valoare individuală.

    Definim regulile de utilizare Aura\Filter\FilterFactory; $filtru = (nou FilterFactory)->newSubjectFilter(); $filtru->validate(„nume”) ->isNotBlank() ->is(„două_cuvinte”) ->setMessage(„Numele trebuie să fie de două cuvinte.”); $filter->validate("login") ->isBlankOr("alnum") ->setMessage("Dacă specificați un login, acesta trebuie să conțină doar caractere latine."); $filter->validate("email") ->isNotBlank() ->is("email") ->setMessage("Vă rugăm să introduceți o adresă de e-mail validă."); $filter->validate("parola") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Vă rugăm să scrieți parola."); $filtru->validate(„de acord”) ->is(„callback”, function($subiect, $câmp) ( return $subiect->($câmp) === adevărat; ))->setMessage(„Ai nevoie de sunt de acord cu termenii și condițiile.”);

  • După cum puteți vedea, descrierea regulilor este destul de simplă. Aura.Filter oferă un întreg set de reguli utile din cutie, iar unele dintre ele au fost folosite în exemplul de mai sus:
  • metoda isNotBlank.
  • Specifică faptul că câmpul nu poate avea o valoare nulă.
  • alnum.
  • e-mail. Trebuie să conțină o adresă de e-mail validă.
  • Probabil ați observat că nu am specificat regula două_cuvinte. Desigur, nu există o astfel de regulă în Aura.Filter, așa că trebuie să creăm una. După cum spune documentația, acest lucru se face folosind o clasă separată pentru regulă:


    /** * Regula care validează numele de utilizator.

    * Numele de utilizator este format din două cuvinte: nume și prenume, separate printr-un spațiu.


    */ class UserNameRule ( /** * Validează numele utilizatorului. * * @param object|array $subiect * @param șir $câmp * @param int $max * * @return bool */ funcție publică __invoke($subiect, $ câmp , $max = nul) ( $valoare = $subiect->($câmp); if (! is_scalar($value)) ( return false; ) return (bool) preg_match("/^+\s+$/u" , $valoare);


    Al doilea pas este să informați fabrica de filtre despre noua noastră regulă. Se face prin trecerea primului argument ca o matrice de reguli către fabrica de filtre:

    Următorul pas este să anunțăm Aura.Filter că am creat o nouă regulă și dorim să o folosim. Acest lucru se face prin trecerea unui set de reguli la primul argument al fabricii:

    utilizați Aura\Filter\FilterFactory; $rules = [ "două_cuvinte" => function() ( returnează o nouă regulă UserName; ) ]; $filtru = (nou FilterFactory($reguli))->newSubjectFilter();

    Acum regula noastră two_words poate fi folosită în același mod ca orice altă regulă standard.


    Feedback


    După cum vă amintiți, datele primite pe care le validăm sunt complet invalide, deoarece fiecare câmp conține o valoare incorectă sau nu o conține deloc. Prin urmare, se presupune că în urma validării vom primi erori și mesaje corespunzătoare despre acestea.

    Validăm cu Aura.Filter după cum urmează: $valid = $filtru->aplica($date); dacă (! $valid) ( $eșecuri = $filtru->getEșecuri(); $mesaje = $eșecuri->getMessages(); )ÎN


    $mesaje

    se scrie o matrice, deci pentru a afișa mesaje avem nevoie de două imbricate pentru fiecare:


    Respectați validarea


    utilizați Respect\Validation\Validator ca v; $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail aici "parola" => "" // Parola nu este specificată deloc // "de acord" nu este în matrice deoarece utilizatorul nu a bifat caseta ];

    Definirea regulilor


    Ca și în cazul Aura.Filter, avem nevoie de propria noastră regulă de validare pentru numele de utilizator, așa că să începem de acolo:

    namespace MyNamspace; utilizați Respect\Validation\Rules\AbstractRule; clasa UserNameRule extinde AbstractRule (funcția publică validate($input) ( return (bool) preg_match("/^+\s+$/u", $input); ) )


    API-ul regulilor externe este aproape identic cu Aura.Filter, doar metoda validate() este folosită în loc de magia __invoke(). Mi s-a părut, acest API, mai simplu și mai ușor de înțeles. Ei bine, este mai aproape de Kontrolio :).


    Nu am găsit nicio mențiune despre acest lucru în documentație, cu toate acestea, pe lângă regula în sine, trebuie să creați propriul tip de excepție pentru aceasta. Numele clasei de excepție trebuie să fie format din numele clasei de reguli și un postfix

    Excepţie


    utilizați Respect\Validation\Exceptions\NestedValidationException; clasa UserNameRuleException extinde NestedValidationException ( // )

    Ei bine, în sfârșit ne putem valida datele. În primul rând, transmitem noua noastră regulă validatorului, astfel încât el să știe despre ea și să o putem folosi în viitor. În Respect Validation, acest lucru se face prin apelarea metodei with(), trecând spațiul de nume în care se află regulile non-standard. v::with("MyNamspace\\"); Acum toate regulile non-standard situate în spațiul de nume


    MyNamspace

    , va fi „recunoscut” de validator. Următorul pas este de a descrie regulile necesare și de a efectua validarea. v::attribute(„nume”, v::userNameRule()) ->atribut(„login”, v::alnum(„-_”)) ->atribut(„e-mail”, v::email()) ->atribut(„parolă”, v::notEmpty()->stringType()->lungime(null, 64)) ->atribut(„de acord”, v::trueVal()) ->assert((obiect) $date); Observați cum ne aplicăm regula atributului


    nume . Aici numele clasei de reguli a fost transformat în numele metodei validatorului. Restul regulilor sunt, în general, intuitive. Merită menționat separat de ce oferim matricea

    utilizați Aura\Filter\FilterFactory; $rules = [ "două_cuvinte" => function() ( returnează o nouă regulă UserName; ) ]; $filtru = (nou FilterFactory($reguli))->newSubjectFilter();

    Spre deosebire de Aura.Filter, validatorul Respect lansează o excepție atunci când validarea eșuează. Și această excepție conține mesaje de eroare de validare. Prin urmare, exemplul care tocmai a fost arătat ar trebui scris după cum urmează:


    încercați ( v::with("RespectValidationExample\\"); v::attribute("nume", v::userNameRule()) ->attribute("login", v::alnum("-_")) - >atribut(„e-mail”, v::email()) ->atribut(„parolă”, v::notEmpty()->stringType()->lungime(null, 64)) ->atribut(„de acord”, v::trueVal()) ->assert((obiect) $date ) catch (NestedValidationException $ex) ( $mesaje = $ex->getMessages(); )

    Folosind getMessages() vom obține o matrice plată a tuturor mesajelor pe care validatorul le-a colectat în timpul procesului de validare. Prin descărcarea matricei, obținem ceva de genul acesta:


    array(5) ( => șir(29) „Validarea datelor a eșuat pentru %s” => șir(60) „autentificarea trebuie să conțină numai litere (a-z), cifre (0–9) și „-_”” => șir (25) „e-mailul trebuie să fie un e-mail valid” => string(26) „parola nu trebuie să fie goală” => string(32) „Atributul convenit trebuie să fie prezent” )

    Puteți schimba mesajele în propriile dvs. Poate că am înțeles cumva greșit această bibliotecă, dar acest proces nu mi s-a părut atât de evident: trebuie să utilizați metoda findMessages() pe o excepție gestionată, în care definiți mesajele nu pentru atribute, ci pentru reguli.


    $ex->findMessages([ "userNameRule" => "Numele de utilizator trebuie să fie format din două cuvinte.", "alnum" => "Nu ne place datele dvs. de conectare.", "email" => "Evident că nu vă place vrei să ne dai e-mail-ul tău.", "notEmpty" => "Ei bine, unde este parola ta?", "agreed" => "Păcat că nu ești de acord." ]);

    Nu știu ce e în neregulă, dar sunt câteva lucruri pe care încă nu le înțeleg. Aceasta este ceea ce obținem prin definirea regulilor în modul de mai sus:


    array(5) ( => string(40) „Numele de utilizator trebuie să fie din două cuvinte.” => string(31) „Nu ne place datele tale de conectare.” => string(25) „e-mailul trebuie să fie un e-mail valid” = > string(5) „Ei bine, unde este parola ta?” => string(9) „Este păcat că nu ești de acord.”

    După cum puteți vedea, mesajul pentru câmpul de e-mail nu a fost aplicat, a rămas cel standard. Dar mesajul de la indexul 4 este invers! Și asta în ciuda faptului că nu am folosit numele regulii, ci numele câmpului. În timp ce dacă aș fi folosit numele regulii (trueVal), mesajul meu s-ar fi pierdut undeva. Comentariile utilizatorilor experimentați ai acestei biblioteci sunt binevenite.

    Validare Sirius

    Ok, să trecem la următoarea bibliotecă și să vedem cum se descurcă cu sarcini similare.

    Definirea regulilor

    Încă o dată trebuie să definim o regulă pentru numele de utilizator. Vom scrie cam așa:


    clasa UserNameRule extinde AbstractRule ( // Mesaje de eroare const MESSAGE = "Numele de utilizator trebuie să fie din două cuvinte."; const LABELED_MESSAGE = "(eticheta) trebuie să fie două cuvinte."; funcția publică validate($value, $valueIdentifier = null ) ( return (bool) preg_match("/^+\s+$/u", $valoare) )

    Vă rugăm să rețineți diferența de abordări față de bibliotecile deja discutate. Definim două tipuri de mesaje în constante, mai degrabă decât să folosim proprietăți, metode sau argumente de regulă.


    Acum să descriem logica de validare:


    $validator = validator nou; $validator ->add(„nume”, „obligatoriu | MyApp\Validation\Rule\UserNameRule”) ->add(„login”, „obligatoriu | alphanumhyphen”, null, „Autentificarea poate conține numai litere latine, liniuțe și litere de subliniere. ") ->add("e-mail", "obligatoriu | e-mail", null, "Vă rugăm să introduceți un e-mail corect.") ->add("parolă", "obligatoriu | lungime maximă(64)", null, "Dvs. parola, domnule.") ->add("de acord", "necesar | egal(adevărat)", null, "De ce nu ați fost de acord?");

    După cum puteți vedea, setul de reguli este foarte simplu și ușor de citit. Pentru descriere, folosim nume separate prin bare orizontale. Această abordare este similară cu cea utilizată în Laravel și Kontrolio.


    Al patrulea argument al metodei add() descrie mesajul de eroare de validare pe care Sirius îl va folosi dacă validarea eșuează. De ce nu am adăugat un mesaj pentru noua noastră regulă? UserNameRule?


    $validator->add ("nume", "necesar | MyApp\Validation\Rule\UserNameRule")

    Acest lucru se datorează faptului că mesajele sunt deja descrise în constantele clasei:


    clasa UserNameRule extinde AbstractRule ( // Mesaje de eroare const MESSAGE = "Numele de utilizator trebuie să conțină două cuvinte."; ...

    O altă opțiune este să utilizați metoda addMessage() a validatorului însuși:


    $validator->addMessage("e-mail", "Vă rugăm să introduceți un e-mail valid.");

    Vă rugăm să rețineți că regulile personalizate sunt identificate prin numele complet al clasei lor, în timp ce în Kontrolio puteți specifica un alias/alias.

    utilizați Aura\Filter\FilterFactory; $rules = [ "două_cuvinte" => function() ( returnează o nouă regulă UserName; ) ]; $filtru = (nou FilterFactory($reguli))->newSubjectFilter();

    Pentru a efectua validarea, apelăm metoda validatorului validate() , transmițându-i datele:


    $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail aici "parola" => "" // Parola nu este specificată deloc // "de acord" nu este în matrice deoarece utilizatorul nu a bifat caseta ]; $validator->validate($date);

    Spre deosebire de Respect, Sirius nu va face o excepție, ci pur și simplu se va întoarce fals. Mesajele de eroare de validare pot fi obținute prin metoda de validare getMessages(). Returnează erori grupate după atribute, așa că avem nevoie de două bucle foreach pentru a trece prin erori:


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

    Aici $message este un obiect de clasă Sirius\Validation\ErrorMessage, care are o metodă getTemplate() care returnează chiar mesajul de care avem nevoie.

    Valitron Definirea regulilor

    Prima diferență: pentru a adăuga o nouă regulă, nu trebuie să creați o clasă separată. Puteți utiliza pur și simplu o închidere care returnează un rezultat boolean.


    Pentru a adăuga reguli personalizate, Valitron are o metodă statică addRule(), în care primele două argumente sunt necesare, iar al treilea este opțional. Mi-a plăcut această metodă, deoarece aici identificatorul regulii, logica și mesajul de eroare sunt indicate într-un singur loc.


    utilizați Valitron\Validator; Validator::addRule("două_cuvinte", function($câmp, $valoare) ( ​​return (bool) preg_match("/^+\s+$/u", $value); ), "Numele de utilizator trebuie să fie format exact din două cuvinte ");

    A doua diferență este modul în care regulile sunt aplicate atributelor. În toate cazurile anterioare, am văzut că un atribut este, parcă, un lucru primar.


    Valitron a luat o altă cale și a pus regulile de validare pe primul loc. Descriind reguli, se pare că aplicați atribute acestor reguli și nu invers.


    $validator = validator nou($date); $validator ->rule("două_cuvinte", "nume")->label("") ->rule("obligatoriu", [ "nume", "autentificare", "e-mail", "parolă", "de acord" ] ) ->rule("slug", "login") ->rule ("e-mail", "email") ->rule ("acceptat", "acordat");

    După cum se poate observa din exemplu, în metoda rule() scriem mai întâi numele regulii și abia apoi indicăm atributele care trebuie să corespundă acestei reguli. Un exemplu mai explicit este regula necesară, care arată cum atributele „aparțin” acelei reguli.


    Valitron (ca și alte soluții pe care le-am analizat) oferă mesaje de eroare standard. Dacă doar le folosiți, veți vedea că fiecare mesaj începe cu numele atributului corespunzător.


    Valitron înlocuiește numele atributelor în textul mesajului chiar și atunci când sunt utilizate mesaje de eroare non-standard. De aceea am folosit metoda label() cu un șir gol pentru a elimina numele atributului.


    $validator->rule("două_cuvinte", "nume")->label("") Feedback

    În ceea ce privește validarea, API-ul bibliotecii Valitron nu este practic diferit de ceea ce am văzut deja în articol. Pentru a efectua validarea apelăm metoda validatorului validate() :


    $validator->validate();

    Mesajele de eroare de validare pot fi preluate folosind metoda getErrors():


    $validator->erori();

    Mesajele de aici sunt grupate după atribute în același mod ca în Validarea Sirius, cu excepția faptului că nu există o clasă separată pentru mesaj și obținem o matrice multidimensională obișnuită.


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

    Și, în sfârșit, ultima bibliotecă de astăzi este propria mea dezvoltare numită Kontrolio.

    Definirea regulilor

    Din nou, pentru a cincea oară, vom crea o regulă de validare pentru numele de utilizator. Totul este relativ simplu și standard:


    spațiu de nume MyProject\Validation\Rules; utilizați Kontrolio\Rules\AbstractRule; clasa TwoWords extinde Controlul\Rules\AbstractRule (funcția publică esteValid($input = null) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

    Acum creăm o fabrică și înregistrăm o regulă în ea folosind metoda extend():


    spațiu de nume MyProject; utilizați Kontrolio\Factory; utilizați MyProject\Validation\Rules\TwoWords; $factory = Control\Factory::getInstance()->extend();

    După înregistrarea regulii, o putem folosi, inclusiv după nume - two_words. Să creăm un validator:


    $date = [ "name" => "Albert", // Trebuie să fie două cuvinte "login" => "@lbert", // caracterul "Interzis" @ "email" => "ceva în neregulă", // Ar trebui fie un e-mail aici "parola" => "" // Parola nu este specificată deloc // "de acord" nu este în matrice deoarece utilizatorul nu a bifat caseta ]; $rules = [ "nume" => "două_cuvinte", "login" => "uneori|alphadash", "email" => "e-mail", "parolă" => "lungime: 1,64", "de acord" => " acceptat"]; $messages = [ "name" => "Numele de utilizator trebuie să fie format din două cuvinte.", "login" => "Nu ne place datele dvs. de conectare.", "email" => "Evident că nu doriți să oferiți trimite-ne adresa ta de e-mail .", "password" => "Ei bine, unde este parola ta?", "agreed" => "Pacat ca nu esti de acord." ]; $validator = $fabrica->make($date, $reguli, $mesaje);

    Am descris regulile folosind o sintaxă similară cu cea folosită în Laravel, deși am fi putut folosi o versiune mai verbosă:


    $rules = [ "nume" => DouăCuvinte noi, "login" => , "email" => e-mail nou, "parolă" => Lungime nouă (1, 64), "de acord" => nou Acceptat ];

    Feedback


    $validator->validate();

    Validarea este începută folosind aceeași metodă validate():



    Acum putem primi mesaje de eroare folosind una dintre metodele getErrors() sau getErrorsList(). Prima metodă permite o ieșire de eroare mai complexă, în timp ce a doua returnează un tablou plat. Folosind getErrors() putem scoate mesaje ca acesta:


    Și cu getErrorsList() puteți face o listă mai simplă de mesaje:

    Concluzie

  • În acest articol am arătat exemple de utilizare a următoarelor biblioteci:
  • Aura.Filtru
  • Respectați validarea
  • Validare Sirius
  • Valitron
  • controla


    Un „exemple din lumea reală” poate părea prea simplu. Trebuie să fiu de acord, deoarece, într-adevăr, unele capabilități ale bibliotecii au fost lăsate în afara articolului. În principiu, dacă ești interesat, le poți studia singur trăsăturile.


    Fiecare dintre biblioteci oferă propriile sale caracteristici și are părțile sale întunecate, așa că cred că este o chestiune de gust și provocare să o alegi pe aceea.

    sună din nou. Acest tip de regulă este similar cu închiderile de la Kontrolio. Vă permite să definiți o regulă sub forma unei închideri. La această închidere, Aura.Filter trece „subiectul”, matricea noastră de date din formular și un câmp, în acest caz agreat.

    • Etichete:
    • validarea datelor
    • php
    clădire de biciclete