Validarea datelor cu o clasa PHP

Created at: octombrie 24, 2014; Last update: noiembrie 5, 2014

Peste tot pe internet poţi găsi tot felul de tutoriale/scripturi care îţi arată cum sa faci o clasă PHP care sa valideze datele venite de la utilizatori. De aceea m-am gândit că poate ar trebui să încerc şi eu să fac un astfel de tutorial/script. (Ultimul update: 05.11.2014) Te rog ca, orice întrebare, nelămurire sau propunere de schimbare a scriptului să o pui într-un comentariu. Nu există întrebări stupide, toate ascund în spatele lor un sâmbure de adevăr. De aceea, nu te sfii să îmi scrii un comentariu.

Filosofia din spatele acestui script

Am dorit să realizez o clasă care să permită validarea oricăror tipuri de date, indiferent că acestea vin dintr-un URL (date de tip GET), dintr-un formular (date de tip POST) ori pur şi simplu dintr-o variabilă.

Cineva ar putea spune că m-am întins mai mult decât îmi permite plapuma, dar m-am gândit că doar prin aşa ceva aş putea să aduc puţin mai mult decât celelalte tutoriale/scripturi.

De asemenea, aş dori ca acest script să fie oarecum “modular”, cu alte cuvinte să conţină doar elementele de care site-ul are nevoie în validare. Spre exemplu, de ce să oferi scriptului o validare pentru CNP, dacă nu ai nevoie de aşa ceva? De aceea, dacă vei folosi scriptul rezultat, îţi vei putea alege singur “modulele” necesare validări, eliminând aşadar pericolul de a face un script prea mare. Pe parcursul tutorialului/scriptului, vei vedea ce vreau să spun.

Trebuie să menţionez că acest tutorial/script este o entitate “vie”, adică ar putea suferi modificări pe parcurs, în funcţie de eventualele comentarii pe care le-ar putea primi.

Aşadar, să trecem la treabă.

Cum va funcţiona validarea

Presupunând că avem un script final (Validation.php), validarea va funcţiona astfel:

Întâi va trebui să ne asigurăm că avem clasa inclusă (nu voi sta aici să discut despre metodele de includere a clasei).

Apoi, vom instanţia clasa pentru a-i putea folosi metodele. Poate că nu vom folosi un constructor pentru această clasă, dar este bine să fim pregătiţi:

Acum, după instanţierea clasei, va trebui să spunem ce câmpuri dorim să validăm şi ce reguli de validare va avea fiecare câmp.

Ţinând cont că dorim ca acest script să valideze orice tip de date, fie ele de tip GET, de tip POST sau variabile, forma de adăugare a unui câmp va avea modelul:

$validation->field(‘nume_variabila’, ‘sursa_variabila_sau_valoare’, ‘regula1[argumente_optionale]<*mesaj de eroare optional*>|regula2[argumente_optionale]<*mesaj de eroare optional*>’,’cum_va_fi_afisat_campul_in_caz_de_eroare’);

unde:

  • ‘nume_variabila’ reprezinta felul cum se numeşte variabila. Astfel, dacă avem ceva de genul <input type=”text” name=”username” />, numele variabilei va fi ‘username’.
  • ‘sursa_variabila_sau_valoare’ reprezintă sursa de unde vine variabila. Astfel, dacă avem o variabilă venită dintr-un URL: http://siteultau.ro/index.php?page=1, vom putea transmite câmpul ‘page’, punând drept sursă ‘_GET’. În cazul câmpurilor de tip POST, vom pune drept sursă ‘_POST’. În cazul câmpurilor care sunt de fapt variabile putem pune direct valoarea. Astfel, dacă avem o variabila $text, nume_variabila va fi ‘text’, iar sursa_variabila_sau_valoare va fi $text.
  • ‘regula1’ şi ‘regula2’ reprezintă denumirea regulilor ce vor fi aplicate câmpurilor. Astfel, dacă dorim ca unui câmp să-i fie eliminate spaţiile goale din stânga şi din dreapta şi să fie un câmp obligatoriu, vom scrie ceva de genul: ‘trim|required’. Unora dintre aceste reguli li se vor putea ataşa argumente suplimentare (între paranteze pătrate []) şi un mesaj de eroare care să fie diferit de mesajul originar (mesajul urmând să fie scris între <* şi *>)

Aşadar, pentru variabile de tip POST vom avea:

Pentru variabile de tip GET singura diferenţă se va regăsi la _POST, acolo având de fapt _GET:

Pentru variabile simple vom avea:

După declararea câmpurilor, ne rămâne validarea şi eventuala afişare a erorilor

Astfel, vom avea metoda validate() care va returna true în cazul în care validarea s-a încheiat fără erori şi false în cazul în care unele câmpuri nu au respectat regulile de validare:

Erorile de validare vor putea fi preluate prin metoda errors(), care va returna erorile intr-un array:

În cazul în care vrem să afişăm erorile unui anumit câmp, le putem accesa sub formă de array, oferind ca parametru al metodei numele variabilei:

Accesarea valorilor câmpurilor o putem face folosindu-ne de metoda get_value(‘nume_camp’).

Acestei metode i-am ataşat mai mulţi parametri opţionali, care să ne permită administrarea mai uşoară a valorilor. Astfel, metoda arată aşa:

$validation->get_value(‘nume_camp’,’aplicare_filter_sanitize_string’,’tipul_in_care_returnez_valoarea’))

unde:

  • ‘nume_camp’ este numele câmpului.
  • ‘aplicare_filter_sanitize_string’ (default este TRUE) este o setare care aplica automat sanitize string.
  • ‘tipul_in_care_returnez_valoarea’ (default este ‘single’) este încercarea mea de validare a unor câmpuri ce pot avea mai multe valori (cum este în cazul elementelor de tip select multiple). Astfel, în mod normal se va returna valoarea, dar în cazul câmpurilor ce pot avea mai multe valori, putem seta ca tip de returnare ‘array’.

Pe lângă metodele prezentate mai sus am mai realizat încă una, care ne va permite să ataşăm mesaje suplimentare de eroare în cazul în care mai facem validări ce nu ţin neapărat de datele primite (ca de exemplu, după ce am primit datele dorim să verificăm în baza de date informaţii şi, în cazul în care nu ne plac rezultatele, sa adăugăm un mesaj de eroare care să atenţioneze utilizatorul în această privinţă).

Metoda se numeşte append_error() şi are forma următoare:

$validation->append_error(‘username’, ‘exists’, ‘Username-ul există deja în baza de date’);

În exemplul de mai sus am adăugat o eroare prin care atenţionez utilizatorul asupra unei erori, folosindu-mă de câmpul ‘username’ căruia îi ataşez un identificator de eroare ce poartă numele ‘exists’ cu un mesaj aferent.

Scriptul de bază

Voi scrie mai jos scriptul de bază şi voi explica liniile:

Dorim să păstrăm într-un singur loc mesajele de eroare. Am putea la fel de bine să definim toate erorile aici, dar am ales sa adaug elemente array-ului la fiecare metodă de validare în parte.

Trebuie să păstrăm de asemenea toate erorile într-un loc.

Erorile vor fi afişate în conainere HTML, în acest caz în cadrul elementului <div class=”error”></div>

În $_fields vom păstra câmpurile ce vor fi oferite clasei Validation

Vom permite utilizatorului să îşi definească singur containerele pentru erori acesta folosindu-se de metoda set_error_container(). Exemplu: $validation->set_error_container(‘<li class=”error”>’,'</li>’);

Metoda field() va permite adăugarea de câmpuri în array-ul $_fields. În funcţie de parametrii oferiţi, metoda va ştii cum să acceseze valorile date câmpurilor.

Metoda _get_rules() este apelată de metoda field(), rostul acesteia fiind acela de a adăuga regulile scrise sub formă de string într-un array care se va adăuga la fiecare câmp din $_fields având drept cheie string-ul ‘rules’.

Metoda validate() pur şi simplu ia fiecare câmp în parte şi îi aplică metoda specifică fiecărei reguli de validare, returnând false în cazul în care cel puţin o regulă nu a fost întrunită sau true dacă toate regulile au fost respectate. După cum poţi vedea, în funcţie de regulă, numele metodei care se va ocupa de regulă va avea formatul _validate_regula($denumire_camp, $valoare_initiala, $alti_parametri).

Metoda get_value() returnează valoarea câmpului cerut.

Metoda errors() returnează erorarea/erorile de validare în cadrul containerelor HTML.

Metoda _write_error() va fi folosită de către metodele vare validează valoarea câmpurilor pentru a scrie mesajele de eroare.

Metoda append_error() va permite adăugarea de erori ce nu au neapărată legătură cu validarea ci vor fi scrise din afara clasei de către aplicaţie.

Regulile de validare

Acum sa trecem la regulile de validare

TRIM – Scurtare extremităţi

Exemple utilizare:

Cod:

Trim nu este la rigoare o regulă de validare, ci este o etapă în validarea unui câmp. Astfel, dacă consideri că este neapărat necesar ca înainte de validare (sau, cine ştie, poate după validare) să elimini spaţiile sau orice alte caractere de la extremităţi, este o idee bună să faci asta folosindu-te de regula ‘trim’. Ai putea întreba atunci “de ce ai pus în denumirea metodei sintagma validate dacă nu se face o validare?”. Am făcut acest lucru pentru a permite artificiul pe care l-am folosit la metoda validate(), acela de a chema metodele de validare fără prea multă bătaie de cap.

REQUIRED – Câmp obligatoriu

Exemple utilizare:

Cod:

Prima regulă de validare, pe formatul căreia vor apărea şi celelalte, este ‘required’. Astfel, dacă printre reguli va apărea ‘required’ metoda validate() va chema metoda _validate_required(), oferindu-i acestei metode parametrii necesari pentru identificarea câmpului ce urmează a fi validat, dar şi eventuali parametri suplimentari ($args). În cazul _validate_required() nu avem parametri suplimentari, dar nu ştim cum va evolua clasa de validare, aşa ca vom păstra un format ce va permite ulterior adăugarea de parametri.

Trebuie văzut aici faptul că nu am făcut întâi un trim, permiţând astfel ca câmpurile să poată avea şi spaţii goale ca valoare. Astfel, un câmp care va fi “required” poate avea ca valoare ‘ ‘. Este important de menţionat aici că, dacă dorim să ne asigurăm că se introduce o valoare, trebuie ca la regulile câmpului să facem întâi un ‘trim’ şi apoi un ‘required’: $validation->field(‘username’,’_POST’,’trim|required’);. Dacă am face invers: ‘required|trim’, atunci un câmp la care s-ar pune spaţii goale ar trece de examenul validării. Asta s-ar întâmpla pentru că întâi ar avea loc regula required, care ar fi considerat validă valoarea ‘ ‘, pentru ca apoi să se facă un trim care ar duce la o valoare vidă (care, în condiţiile acestea, nu ar mai fi respectat regula required).

LENGTH – Lungime string

Exemple utilizare:

Cod:

Length ne permite sa stabilim o lungime de caractere pe care o putem accepta ca regula de validare pentru stringuri.

ALPHA – Caractere alfabetice (si nu numai)

Exemple utilizate:

Cod:

Aceasta validare ar fi putut fi simplă, totul putându-se termina după un…

Cu toate acestea, mereu mi-am dat seama că sunt momente când vrei sa accepţi doar caractere alfabetice pentru un anumit input, dar in acelasi timp ai dori sa ai in conţinutul stringului introdus de utilizatori şi caractere precum “-” sau “_” etc.

De aceea, acest validate acceptă ca parametri suplimentari caractere ce nu sunt neapărat litere. În cazul în care în string-ul analizat există altceva decât ce i s-a permis să existe, funcţia va returna un mesaj de eroare.

ALPHANUMERIC – Caractere alfanumerice (şi nu numai)

Exemple utilizate:

Cod:

Regula de validare alphanumeric funcţionează pe acelaşi principiu ca regula alpha, aceasta permiţând însă by default, pe lângă caracterele alfabetice, şi caractere numerice.

NUMERIC – Caractere numerice (şi nu numai)

Exemple utilizate:

Cod:

Regula de validare numeric funcţionează pe acelaşi principiu ca regulile alpha şi alphanumeric.

INTEGER – Numere întregi (şi nu numai)

Regulile INTEGER şi FLOAT pot primi ca parametri limite de comparaţie. Cu alte cuvinte în regula de validare poţi stabili ca numerele acceptate să nu fie mai mari, mai mici sau să fie egale cu limitele dorite de utilizator. Astfel, numărul poate fi negativ sau pozitiv, în funcţie de dorinţele utilizatorului stabilite în cadrul parametrilor. Vezi exemplele de mai jos:

Exemple utilizate:

Cod:

FLOAT – Numere cu virgulă mobilă (şi nu numai)

La fel ca în cazul INTEGER, regula FLOAT poate primi ca parametri limite de comparaţie. Cu alte cuvinte în regula de validare poţi stabili ca numerele acceptate să nu fie mai mari, mai mici sau să fie egale cu limitele dorite de utilizator. Astfel, numărul poate fi negativ sau pozitiv, în funcţie de dorinţele utilizatorului stabilite în cadrul parametrilor. Vezi exemplele de mai jos:

Exemple utilizate:

Cod:

Bineînţeles (după cum poate că şi vezi) cele două reguli, INTEGER şi FLOAT se bazează pe o funcţie numită _compare_values(), regulă pe care ţi-o indic mai jos:

Pe lângă aceste reguli, mai există câteva care cred ca nu mai merită explicaţii, acestea neacceptând parametri suplimentari ci doar mesaje de eroare personalizate:

EMAIL

URL

IP

BOOLEAN

Versiune finală

Mai jos vei găsi codul clasei în totalitatea sa. Cu toate acestea, cel puţin pentru moment, te sfătuiesc să analizezi cu grijă maximă tot ce găseşti mai jos deoarece codul de mai jos nu a fost verificat decât pănă la metoda _validate_required():

 

2 thoughts on “Validarea datelor cu o clasa PHP

Lasă un răspuns

Your email address will not be published. Required fields are marked *

No spam? * Time limit is exhausted. Please reload CAPTCHA.