On erittäin tärkeää, että lomakkeellesi syötetyt tiedot tarkistetaan ennen lomakkeen lähetystietojen siirtämistä jatkokäsittelyyn. Kun lomakkeessa on useita kenttiä, PHP-tarkistuskomentosarjasta tulee liian monimutkainen. Lisäksi, koska teet saman tai samankaltaisen validoinnin useimmille tekemillesi lomakkeille, lomakkeiden tarkistamiseen kuluu liian paljon päällekkäistä työtä.

Tietoja tästä yleisestä PHP-lomakkeen tarkistusskriptistä

Tämän yleisen PHP-lomakkeen tarkistuskomentosarjan avulla on erittäin helppo lisätä vahvistuksia lomakkeeseen.

Luomme ja yhdistämme joukon "validointikuvauksia" jokaiseen lomakkeen elementtiin. "Validointikuvaaja" on merkkijono, joka määrittää suoritettavan validoinnin tyypin. Esimerkiksi "req" tarkoittaa pakollista, "alfa" tarkoittaa sallia vain aakkosmerkit ja niin edelleen.

Jokaisella lomakkeen kentällä voi olla nolla, yksi tai useampi vahvistus. Esimerkiksi syöte ei saa olla tyhjä, sen tulee olla alle 25 merkkiä, sen tulee olla aakkosnumeerinen jne.

Voit liittää joukon vahvistuskuvauksia lomakkeen jokaiseen syöttökenttään.

Lataa PHP-lomakkeen tarkistusskripti

Voit ladata PHP-lomakkeen vahvistusohjelman alta:
Zip-tiedosto sisältää lomakkeen tarkistuskomentosarjan formvalidator.php, dokumentaation ja käyttöesimerkkejä.

PHP-lomakkeen tarkistuskomentosarjan käyttäminen

Sisällytä formvalidator.php lomakkeenkäsittelyohjelmaasi

request_once "formvalidator.php"

Luo FormValidator-objekti ja lisää lomakkeen vahvistuskuvaajat.

$validator = new FormValidator(); $validator->addValidation("Nimi","req","Täytä nimi"); $validator->addValidation("Sähköposti","sähköposti", "Sähköpostin syötteen tulee olla kelvollinen sähköpostiosoite"); $validator->addValidation("Sähköposti","req","Täytä sähköposti");

Ensimmäinen argumentti on lomakkeen syöttökentän nimi. Toinen argumentti on validointikuvaaja, joka kertoo vaadittavan validoinnin tyypin. Kolmas argumentti on virheilmoitus, joka näytetään, jos vahvistus epäonnistuu.

Vahvista lomake kutsumalla ValidateForm()-funktiota

if(!$validator->ValidateForm()) ( echo "Validation Errors:"; $error_hash = $validator->GetErrors(); foreach($error_hash as $inpname => $inp_err) ( echo "

$inpname: $inp_err

\n"; ) ) Esimerkki

Alla oleva esimerkki selventää ajatusta

Nimi: Sähköposti:

Mukautetun vahvistuksen lisääminen

Jos haluat lisätä mukautetun vahvistuksen, jota vahvistuskuvaajat eivät tarjoa, voit tehdä niin. Tässä ovat vaiheet:

Luo luokka mukautettua vahvistusta varten ja ohita DoValidate()-funktio

class MyValidator laajentaa CustomValidator ( funktio DoValidate(&$formars,&$error_hash) ( if(stristr($formars["Comments"],"http://")) ( $error_hash["Comments"]="Ei URL-osoitteita sallittu kommenteissa"; palauta false; ) palauta tosi; ) )

Lisää mukautettu vahvistusobjekti

$validator = new FormValidator(); $validator->addValidation("Nimi","req","Täytä nimi"); $validator->addValidation("Sähköposti","sähköposti", "Sähköpostin syötteen tulee olla kelvollinen sähköpostiosoite"); $validator->addValidation("Sähköposti","req","Täytä sähköposti"); $custom_validator = new MyValidator(); $validator->AddCustomValidator($custom_validator);

Mukautettu vahvistustoiminto kutsutaan automaattisesti muiden tarkistusten jälkeen.

Validointikuvaustaulukko

Tässä on luettelo kaikista validointikuvauksista:

Validointikuvaus	Käyttö
req	Kenttä ei saa olla tyhjä
maxlen=???	tarkistaa syötetyn tiedon pituuden maksimissaan. Jos esimerkiksi suurin sallittu koko on 25, anna vahvistuskuvaajaksi "maxlen=25"
minlen=???	tarkistaa syötetyn merkkijonon pituuden vaadittuun minimiin. esimerkki "minlen=5"
alnum	Tarkista tiedot, sisältävätkö ne muita merkkejä kuin aakkos- tai numeerisia merkkejä
alnum_s	Sallii vain aakkosmerkit, numerot ja välilyönnit
nro	Tarkista numeeriset tiedot
alfa	Tarkista aakkostiedot.
alfa_s	Tarkista aakkostiedot ja salli välilyönnit.
sähköposti	Kenttä on sähköpostikenttä ja varmistaa tietojen oikeellisuuden.
lt=??? vähemmän=???	Varmista, että tiedot ovat pienempiä kuin välitetty arvo. Koskee vain numeerisia kenttiä. esimerkki: jos arvon tulee olla pienempi kuin 1000, anna vahvistuskuvaus muodossa "lt=1000"
gt=??? suurempi kuin =???	Varmista, että tiedot ovat suurempia kuin välitetty arvo. Koskee vain numeerisia kenttiä. esimerkki: jos arvon pitäisi olla suurempi kuin 10, anna vahvistuskuvaus muodossa "gt=10"
regexp=???	Tarkista säännöllisellä lausekkeella, että arvon tulee vastata säännöllistä lauseketta. esimerkki: "regexp=^(1.20)$" sallii enintään 20 aakkosmerkkiä.
älä valitse =??	Tämä vahvistuskuvaus on tarkoitettu valituille syöttökohdille (luetteloille). Normaalisti valintaluetteloruuduissa on yksi kohde, jossa lukee "Valitse yksi". Käyttäjän tulee valita jokin muu vaihtoehto kuin tämä vaihtoehto. Jos tämän vaihtoehdon arvo on "Valitse yksi", vahvistuskuvauksen tulee olla "dontselect=Select One".
dontselectchk	Tämä vahvistuskuvaus on tarkoitettu valintaruutuihin. Käyttäjän ei tule valita annettua valintaruutua. Anna valintaruudun arvo ?? Esimerkiksi dontselectchk=on
pitäisi valita	Tämä vahvistuskuvaus on tarkoitettu valintaruutuihin. Käyttäjän tulee valita annettu valintaruutu. Anna valintaruudun arvo ?? Esimerkiksi shouldselchk=on
älä valitse radiota	Tämä vahvistuskuvaus on tarkoitettu valintanapeille. Käyttäjän ei tule valita annettua valintanappia. Anna valintanapin arvo ?? Esimerkiksi dontselectradio=NO
valitse radio	Tämä vahvistuskuvaus on tarkoitettu valintanapeille. Käyttäjän tulee valita annettu valintanappi. Anna valintanapin arvo ?? Esimerkiksi selectradio=yes
selmin=??	Valitse vähintään n määrä valintaruutuja valintaruuturyhmästä. Esimerkiksi: selmin=3
selone	Tekee radioryhmän pakolliseksi. Käyttäjän tulee valita radioryhmästä vähintään yksi kohde.
eqelmnt=???	vertaa lomakkeen kahta elementtiä ja varmista, että arvot ovat samat. Esimerkiksi "salasana" ja "vahvista salasana". Vaihda ??? toisen syöttöelementin nimellä. Esimerkiksi: eqelmnt=confirm_pwd

Edellisessä artikkelissa lupasin kirjoittaa vertailun omasta kirjastostani muihin saatavilla oleviin ratkaisuihin, joten tänään tarkastelemme validointia käyttämällä Aura.Filter-, Respect Validation-, Sirius Validation- ja Valitron-sovellusta.

Kuvittelemme, että meillä on kehitteillä tietty julkinen palvelu, johon liittyy käyttäjien rekisteröinti täysi pääsy kaikkiin toimintoihin. Ilmoittautumislomake sisältää siis seuraavat kentät:

nimi. Täytyy sisältää täsmälleen kaksi sanaa, joista ensimmäinen on käyttäjän etunimi ja toinen on sukunimi.

kirjaudu sisään.

Jos arvo välitetään, se saa sisältää vain latinalaisia ​​kirjaimia, yhdysmerkkejä ja alaviivoja. sähköposti..

Täytyy sisältää kelvollinen osoite

sähköposti

salasana. On oltava asetettu ja saa olla enintään 64 merkkiä pitkä.

sovittu.

Tyypillinen valintaruutu, joka käyttäjän on tarkistettava vahvistaakseen hyväksyvänsä käyttöehdot.

Meillä on siis viisi kenttää, jotka käyttäjän on täytettävä voidakseen rekisteröityä kuvitteelliseen palveluumme. Oletetaan, että saimme syötteenä täysin virheellisiä tietoja:

$data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla olla sähköposti "salasana" => Aura.Filter

Validointi Aura.Filterillä alkaa suodatintehtaasta. Meidän on luotava niin kutsuttu "aihesuodatin", koska vahvistamme taulukon, emme yksittäistä arvoa.

Määrittelemme säännöt käyttämällä Aura\Filter\FilterFactory; $suodatin = (uusi FilterFactory)->newSubjectFilter(); $filter->validate("nimi") ->isNotBlank() ->is("kaksi_sanaa") ->setMessage("Nimen tulee olla kaksi sanaa."); $filter->validate("login") ->isBlankOr("alnum") ->setMessage("Jos määrität kirjautumistunnuksen, sen tulee sisältää vain latinalaisia ​​merkkejä."); $filter->validate("email") ->isNotBlank() ->is("sähköposti") ->setMessage("Anna kelvollinen sähköpostiosoite."); $filter->validate("salasana") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Kirjoita salasanasi."); $filter->validate("sovittu") ->is("takaisinsoitto", function($subject, $field) ( return $subject->($field) === true; ))->setMessage("Tarvitset hyväksyä käyttöehdot.");

Kuten näet, sääntöjen kuvaus on melko yksinkertainen. Aura.Filter tarjoaa kokonaisen joukon hyödyllisiä sääntöjä heti, ja joitain niistä käytettiin yllä olevassa esimerkissä:

isNotBlank -menetelmä.

Määrittää, että kentällä ei voi olla nolla-arvoa. alnum. Tämä sääntö sallii vain latinalaiset kirjaimet.

Olet todennäköisesti huomannut, että en määrittänyt two_words -sääntöä. Luonnollisesti Aura.Filterissä ei ole tällaista sääntöä, joten meidän on luotava sellainen. Kuten dokumentaatiossa sanotaan, tämä tehdään käyttämällä erillistä luokkaa säännölle:

/** * Sääntö, joka vahvistaa käyttäjänimen.

* Käyttäjätunnus koostuu kahdesta sanasta: etu- ja sukunimi, erotettuna yhdellä välilyönnillä.

*/ class UserNameRule ( /** * Vahvistaa käyttäjänimen. * * @param object|array $subject * @param string $field * @param int $max * * @return bool */ julkinen funktio __invoke($subject, $field , $max = null) ( $arvo = $aihe->($kenttä); if (! is_scalar($value)) ( return false; ) return (bool) preg_match("/^+\s+$/u", $arvo);

Toinen vaihe on kertoa suodatintehtaalle uudesta säännöstämme. Se tehdään välittämällä ensimmäinen argumentti sääntöjoukona suodatintehtaalle:

Seuraava askel on ilmoittaa Aura.Filterille, että olemme luoneet uuden säännön ja haluamme käyttää sitä. Tämä tehdään välittämällä joukko sääntöjä tehtaan ensimmäiselle argumentille:

käytä Aura\Filter\FilterFactorya; $säännöt = [ "kaksi_sanaa" => function() (palauta uusi Käyttäjänimisääntö; ) ]; $suodatin = (uusi FilterFactory($säännöt))->newSubjectFilter();

Nyt kaksi_sana-sääntöämme voidaan käyttää samalla tavalla kuin mitä tahansa muuta vakiosääntöä.

Palaute

Kuten muistat, vahvistamamme saapuvat tiedot ovat täysin virheellisiä, koska jokainen kenttä sisältää virheellisen arvon tai ei sisällä sitä ollenkaan. Siksi oletetaan, että validoinnin tuloksena saamme virheitä ja niitä koskevia vastaavia viestejä.

Vahvistamme Aura.Filterillä seuraavasti: $valid = $suodatin->apply($data); if (! $valid) ( $epäonnistuminen = $suodatin->getFailures(); $viestit = $epäonnistuminen->getMessages(); ) IN

$viestiä

taulukkoa kirjoitetaan, joten viestien näyttämiseen tarvitsemme kaksi sisäkkäistä foreachia:

Kunnioita validointia

käytä Respect\Validation\Validator muodossa v; $data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla ole sähköposti täällä "password" => "" // Salasanaa ei ole määritetty ollenkaan // "sopiva" ei ole taulukossa, koska käyttäjä ei valinnut ruutua ];

Sääntöjen määrittely

Kuten Aura.Filterissä, tarvitsemme oman vahvistussäännön käyttäjätunnukselle, joten aloitetaan siitä:

nimiavaruus MyNamespace; käytä Respect\Validation\Rules\AbstractRule; luokka UserNameRule laajentaa AbstractRule:n ( julkinen funktio valide($input) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

Ulkoisten sääntöjen API on lähes identtinen Aura.Filterin kanssa, vain valide()-menetelmää käytetään __invoke()-taikuuden sijaan. Minusta tämä API näytti yksinkertaisemmalta ja ymmärrettävämmältä. No, se on lähempänä Kontroliota :).

En löytänyt dokumentaatiosta mainintaa tästä, mutta itse säännön lisäksi sinun on luotava sille oma poikkeustyyppi. Poikkeusluokan nimen tulee koostua sääntöluokan nimestä ja jälkiliitteestä

Poikkeus

käytä Respect\Validation\Exceptions\NestedValidationException; luokka UserNameRuleException laajentaa NestedValidationExceptionin ( // )

No, vihdoin voimme vahvistaa tietomme. Ensin välitämme uuden sääntömme validaattorille, jotta hän tietää siitä ja voimme käyttää sitä tulevaisuudessa. Respect Validationissa tämä tehdään kutsumalla with()-metodia, joka välittää nimitilan, jossa epästandardit säännöt sijaitsevat. v::with("OmaNimitila\\"); Nyt kaikki epästandardit säännöt sijaitsevat nimiavaruudessa

OmaNimiavaruus

, validaattori "tunnistaa". Seuraava vaihe on kuvata tarvittavat säännöt ja suorittaa validointi. v::attribute("nimi", v::userNameRule()) ->attribute("kirjautuminen", v::alnum("-_")) ->attribute("email", v::email()) ->attribuutti("salasana", v::notEmpty()->stringType()->length(null, 64)) ->attribute("sovittu", v::trueVal()) ->assert((objekti) $data); Huomaa, kuinka käytämme sääntöämme attribuutissa

nimi . Tässä sääntöluokan nimi on muutettu validointimenetelmän nimeksi. Loput säännöt ovat yleensä intuitiivisia. On syytä mainita erikseen, miksi tarjoamme taulukon

käytä Aura\Filter\FilterFactorya; $säännöt = [ "kaksi_sanaa" => function() (palauta uusi Käyttäjänimisääntö; ) ]; $suodatin = (uusi FilterFactory($säännöt))->newSubjectFilter();

Toisin kuin Aura.Filter, Respect-validaattori antaa poikkeuksen, kun vahvistus epäonnistuu. Ja tämä poikkeus sisältää vahvistusvirheilmoituksia. Siksi juuri esitetty esimerkki tulisi kirjoittaa seuraavasti:

try ( v::with("RespectValidationExample\\"); v::attribute("nimi", v::userNameRule()) ->attribute("kirjautuminen", v::alnum("-_")) - >attribute("email", v::email()) ->attribute("salasana", v::notEmpty()->stringType()->length(null, 64)) ->attribute("sovittu", v::trueVal()) ->assert((objekti) $data ) catch (NestedValidationException $ex) ( $viestit = $ex->getMessages(); )

Käyttämällä getMessages() saamme tasaisen joukon kaikista viesteistä, jotka validaattori keräsi vahvistusprosessin aikana. Pudottamalla taulukon saamme jotain tällaista:

array(5) ( => string(29) "Tietojen vahvistus epäonnistui kohteelle %s" => string(60) "kirjautumisessa saa olla vain kirjaimia (a-z), numeroita (0-9) ja "-_"" => merkkijono (25) "sähköpostin on oltava kelvollinen sähköposti" => string(26) "salasana ei saa olla tyhjä" => string(32) "Sovitun attribuutin on oltava läsnä" )

Voit muuttaa viestit omiksi. Ehkä ymmärsin jotenkin väärin tämän kirjaston, mutta tämä prosessi ei tuntunut minusta niin itsestään selvältä: sinun on käytettävä findMessages()-menetelmää käsitellyssä poikkeuksessa, jossa määrität viestejä ei attribuuteille, vaan säännöille.

$ex->findMessages([ "userNameRule" => "Käyttäjätunnuksen tulee koostua kahdesta sanasta.", "alnum" => "Emme pidä kirjautumistunnuksestasi.", "email" => "Et tietenkään pidä haluat antaa meille sähköpostiosoitteesi.", "notEmpty" => "No, missä salasanasi on?", "agreed" => "On sääli, että olet eri mieltä." ]);

En tiedä mikä on vialla, mutta on pari asiaa, joita en vieläkään ymmärrä. Tämän saamme määrittelemällä säännöt yllä olevalla tavalla:

array(5) ( => string(40) "Käyttäjätunnuksessa on oltava kaksi sanaa." => string(31) "Emme pidä kirjautumisestasi." => string(25) "sähköpostin on oltava kelvollinen sähköpostiosoite" = > string(5) "No, missä on salasanasi?" => string(9) "On sääli, että et ole samaa mieltä."

Kuten näet, sähköpostikentän viestiä ei sovellettu, vaan tavallinen viesti säilyi. Mutta viesti indeksissä 4 on päinvastainen! Ja tämä huolimatta siitä, että en käyttänyt säännön nimeä, vaan kentän nimeä. Jos taas olisin käyttänyt säännön nimeä (trueVal), viestini olisi kadonnut jonnekin. Tämän kirjaston kokeneiden käyttäjien kommentit ovat erittäin tervetulleita.

Siriuksen vahvistus

Ok, siirrytään seuraavaan kirjastoon ja katsotaan, kuinka se käsittelee samanlaisia ​​tehtäviä.

Sääntöjen määrittely

Jälleen kerran meidän on määritettävä sääntö käyttäjätunnukselle. Kirjoitamme sen jotenkin näin:

class UserNameRule laajentaa AbstractRule ( // Virheilmoitukset const MESSAGE = "Käyttäjänimessä on oltava kaksi sanaa."; const LABELED_MESSAGE = "(tunnisteen) on oltava kaksi sanaa."; julkinen funktio valide($value, $valueIdentifier = null ) ( return (bool) preg_match("/^+\s+$/u", $arvo ) )

Huomaa ero lähestymistavoissa verrattuna jo käsiteltyihin kirjastoihin. Määrittelemme kahdenlaisia ​​viestejä vakioissa sen sijaan, että käytämme ominaisuuksia, menetelmiä tai sääntöargumentteja.

Kuvataan nyt validointilogiikka:

$validator = uusi Validator; $validator ->add("nimi", "pakollinen | MyApp\Validation\Rule\UserNameRule") ->add("kirjautuminen", "pakollinen | alphanumyphen", null, "Kirjautuminen voi sisältää vain latinalaisia ​​kirjaimia, väliviivoja ja alaviivoja. ") ->add("email", "required | email", null, "Anna oikea sähköpostiosoite.") ->add("salasana", "pakollinen | maxlength(64)", null, "Sinun salasana, sir.") ->add("hyväksyn", "tarvitaan | yhtäläinen(tosi)", null, "Miksi et suostunut?");

Kuten näette, sääntösarja on hyvin yksinkertainen ja luettava. Kuvauksessa käytämme vaakapalkilla erotettuja nimiä. Tämä lähestymistapa on samanlainen kuin Laravelissa ja Kontroliossa käytetty.

Add()-menetelmän neljäs argumentti kuvaa vahvistusvirhesanoman, jota Sirius käyttää, jos vahvistus epäonnistuu. Miksi emme lisänneet viestiä uudelle säännöllemme? UserNameRule?

$validator->add("nimi", "pakollinen | MyApp\Validation\Rule\UserNameRule")

Tämä johtuu siitä, että viestit on jo kuvattu luokkavakioissa:

class UserNameRule extends AbstractRule ( // Error messages const MESSAGE = "Käyttäjänimessä on oltava kaksi sanaa."; ...

Toinen vaihtoehto on käyttää itse validaattorin addMessage()-menetelmää:

$validator->addMessage("sähköposti", "Anna kelvollinen sähköpostiosoite.");

Huomaa, että mukautetut säännöt tunnistetaan niiden luokan koko nimellä, kun taas Kontroliossa voit määrittää aliaksen/aliaksen.

käytä Aura\Filter\FilterFactorya; $säännöt = [ "kaksi_sanaa" => function() (palauta uusi Käyttäjänimisääntö; ) ]; $suodatin = (uusi FilterFactory($säännöt))->newSubjectFilter();

Tarkistuksen suorittamiseksi kutsumme validointimenetelmää validate() ja välitämme tiedot sille:

$data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla ole sähköposti täällä "password" => "" // Salasanaa ei ole määritetty ollenkaan // "sopiva" ei ole taulukossa, koska käyttäjä ei valinnut ruutua ]; $validator->validate($data);

Toisin kuin Respect, Sirius ei tee poikkeusta, vaan palaa yksinkertaisesti väärä. Vahvistusvirheilmoitukset voidaan saada getMessages()-validaattorimenetelmällä. Se palauttaa attribuuttien mukaan ryhmitellyt virheet, joten tarvitsemme kaksi foreach-silmukkaa käydäksemme läpi virheitä:

foreach ($validator->getMessages() $attribuuttina => $viestit) ( foreach ($viestit $viestinä) ( echo $message->getTemplate() . "\n"; ) )

Tässä $viesti on luokkaobjekti Sirius\Validation\ErrorMessage, jossa on getTemplate()-metodi, joka palauttaa juuri tarvitsemamme viestin.

Valitron Sääntöjen määrittäminen

Ensimmäinen ero: uuden säännön lisäämiseksi sinun ei tarvitse luoda erillistä luokkaa. Voit yksinkertaisesti käyttää sulkemista, joka palauttaa loogisen tuloksen.

Mukautettujen sääntöjen lisäämiseksi Valitronilla on staattinen menetelmä addRule(), jossa kaksi ensimmäistä argumenttia vaaditaan ja kolmas on valinnainen. Pidin tästä menetelmästä, koska tässä säännön tunniste, logiikka ja virheilmoitus on ilmoitettu yhdessä paikassa.

käytä Valitron\Validator; Validator::addRule("kaksi_sanaa", function($field, $value) ( ​​return (bool) preg_match("/^+\s+$/u", $value); ), "Käyttäjätunnuksen tulee koostua tarkalleen kaksi sanaa ");

Toinen ero on se, miten sääntöjä sovelletaan attribuutteihin. Kaikissa aiemmissa tapauksissa näimme, että attribuutti on ikään kuin ensisijainen asia.

Valitron valitsi toisen reitin ja asetti validointisäännöt etusijalle. Kuvaamalla sääntöjä näytät soveltavan attribuutteja näihin sääntöihin, etkä päinvastoin.

$validator = new Validator($data); $validator ->rule("kaksi_sanaa", "nimi")->label("") ->rule("pakollinen", [ "nimi", "kirjautuminen", "sähköposti", "salasana", "sovittu" ] ) ->rule("slug", "login") ->rule("sähköposti", "sähköposti") ->sääntö("hyväksytty", "sovittu");

Kuten esimerkistä voidaan nähdä, rulla()-metodissa kirjoitamme ensin säännön nimen ja vasta sitten ilmoitamme attribuutit, joiden on vastattava tätä sääntöä. Tarkempi esimerkki on pakollinen sääntö, joka osoittaa, kuinka attribuutit "kuuluvat" kyseiseen sääntöön.

Valitron (kuten muutkin tarkastelemamme ratkaisut) tarjoaa vakiovirheilmoituksia. Jos käytät niitä vain, näet, että jokainen viesti alkaa vastaavan määritteen nimellä.

Valitron korvaa attribuuttien nimet sanoman tekstissä, vaikka käytettäisiin epätyypillisiä virheilmoituksia. Tästä syystä käytimme label()-metodia tyhjän merkkijonon kanssa attribuutin nimen poistamiseen.

$validator->rule("kaksi_sanaa", "nimi")->label("") Palaute

Erityisesti validoinnin osalta Valitron-kirjaston API ei käytännössä eroa siitä, mitä olemme jo nähneet artikkelissa. Tarkistuksen suorittamiseksi kutsumme validointimenetelmää validate() :

$validator->validate();

Vahvistusvirheilmoitukset voidaan hakea getErrors()-menetelmällä:

$validator->errors();

Viestit ryhmitellään tässä attribuuttien mukaan samalla tavalla kuin Sirius Validationissa, paitsi että viestille ei ole erillistä luokkaa ja saamme tavallisen moniulotteisen taulukon.

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

Ja lopuksi, tämän päivän viimeinen kirjasto on oma kehitystyöni nimeltä Kontrolio.

Sääntöjen määrittely

Luomme jälleen viidennen kerran käyttäjätunnukselle vahvistussäännön. Kaikki on suhteellisen yksinkertaista ja standardia:

nimiavaruus MyProject\Validation\Rules; käytä Kontrolio\Rules\AbstractRule; luokka TwoWords laajentaa Kontrolio\Rules\AbstractRule ( julkinen funktio onValid($input = null) ( return (bool) preg_match("/^+\s+$/u", $syöte); ) )

Nyt luomme tehtaan ja rekisteröimme siihen säännön extend()-menetelmällä:

nimiavaruus MyProject; käytä Kontrolio\Factory; käytä MyProject\Validation\Rules\TwoWords; $factory = Kontrolio\Factory::getInstance()->extend();

Säännön rekisteröinnin jälkeen voimme käyttää sitä, myös nimellä - two_words. Luodaan validaattori:

$data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla ole sähköposti täällä "password" => "" // Salasanaa ei ole määritetty ollenkaan // "sopiva" ei ole taulukossa, koska käyttäjä ei valinnut ruutua ]; $rules = [ "nimi" => "kaksi_sanaa", "login" => "sometime|alphadash", "email" => "sähköposti", "salasana" => "pituus:1.64", "sovittu" = > " hyväksytty" ]; $messages = [ "name" => "Käyttäjätunnuksen tulee koostua kahdesta sanasta.", "login" => "Emme pidä kirjautumistunnuksestasi.", "email" => "Et ilmeisesti halua antaa us your email .", "password" => "No, missä on salasanasi?", "agreed" => "On sääli, että et ole samaa mieltä." ]; $validator = $tehdas->make($data, $säännöt, $viestit);

Kuvailimme säännöt käyttämällä samanlaista syntaksia kuin Laravelissa, vaikka olisimme voineet käyttää monisanaisempaa versiota:

$rules = [ "nimi" => new TwoWords, "login" => , "email" => new Sähköposti, "salasana" => new Length(1, 64), "agreed" => new Hyväksytty ];

Palaute

$validator->validate();

Validointi aloitetaan käyttämällä samaa validite()-menetelmää:

Nyt voimme saada virheilmoituksia jollakin getErrors()- tai getErrorsList()-menetelmistä. Ensimmäinen menetelmä mahdollistaa monimutkaisemman virhetulostuksen, kun taas toinen palauttaa tasaisen taulukon. Käyttämällä getErrors() voimme tulostaa viestejä, jotka ovat jotain tämän kaltaisia:

Ja getErrorsList():llä voit tehdä yksinkertaisemman luettelon viesteistä:

Bottom line

Tässä artikkelissa näytin esimerkkejä seuraavien kirjastojen käytöstä:

Aura.Suodatin

Siriuksen vahvistus

Kunnioita validointia

Valitron

ohjata

"Tosimaailman esimerkki" saattaa tuntua liian yksinkertaiselta. Minun on myönnettävä, koska artikkelista on jätetty pois joitakin kirjaston ominaisuuksia. Periaatteessa, jos olet kiinnostunut, voit tutkia niiden ominaisuuksia itse.

Jokaisessa kirjastossa on omat ominaisuutensa ja pimeät puolensa, joten mielestäni on makuasia ja haaste valita sellainen.

Kiitos kun luit. Tee oikea valinta.

Tunnisteet: Lisää tunnisteita

Hyvää iltaa kaikille (enemmän kuin yö - toimittajan huomautus). Tänään parannamme sitä hieman. Ensin opetellaan suorittamaan lomakkeiden validointi PHP:ssä ja tehdä joitakin tietoturvakäsittelyjä.

Joten katso alla olevaa koodia ja huomioi seuraavat muutokset ja seuraavat muutosten syyt. Korostin kaikki uudet linjat väreillä.

Lomakekenttien nimet on muutettu. Saatat kysyä – miksi ihmeessä me tarvitsemme tätä? Se on yksinkertaista, minä vastaan ​​sinulle. Sikäli kuin tiedän, jotkut roskapostibotit tutkivat lomakkeita etsiviä sivustoja ja täyttävät ne näiden kenttien nimien perusteella. Teoriassa, jos he eivät löydä ottelua, he menevät kotiin, mitä me haluamme. En tietenkään usko, että tämän suojan taso on erityisen suuri, mutta se ei haittaa meitä, ja jos roskapostit vähenevät yhdellä kirjaimella, se on hyvä =). Tarkistaa, onko sähköpostiosoite syötetty oikein. Rivi 17 käyttää elseif-operaattoria, joka tarkistetaan, jos meille palautetaan myönteinen vastaus, eli se sanoi, että sähköpostiosoite puuttui ollenkaan, eli sitä ei ole syötetty. Tässä käytetään preg_match-funktiota, jonka avulla voimme verrata syötettyä osoitetta säännöllinen lauseke . Ehkä kirjoitan myöhemmin lyhyesti säännöllisistä lausekkeista, mutta nyt se on syytä tietää luo mallin, jota vastaan ​​merkkijonomme tarkistetaan. Ja jos meidän tapauksessamme syötetty osoite ei vastaa lauseketta, näyttöön tulee jälleen virhe. Esimerkiksi tässä on pari muuta säännöllistä lauseketta:
|^[-а-яе\s\.,;:\?!]+$|i– Tämän säännöllisen lausekkeen avulla voit käyttää vain venäjän aakkosia ja joitain merkkejä, kuten välilyönti, piste, pilkku jne.
#http://[-a-z0-9_.]+[-a-z0-9_:@&?=+,.!/~*’%$]*\.(html?|php)#i– ja tämän lausekkeen avulla voit tarkistaa osoitteen oikeinkirjoituksen Internetissä.

Seuraavaksi käytämme else-operaattoria, johon on jo siirretty kaikki koodimme kirjeen lähettämiseen. Voit luoda vahvistussääntöjä itse missä tahansa määrin, lisää vain uusia, jos esimerkiksi sähköpostiosoitteen tarkistamista varten, niin olet tyytyväinen.

Yhteyshenkilö:

Sähköpostiosoite:

Viesti:

Näin voit vahvistaa PHP-lomakkeesi turvautumatta mihinkään ylimääräiseen. Luulen, että seuraavan kerran lomakkeita käsittelevässä viestissä harkitaan lomakkeiden validointia jQueryssa. Sillä välin odotan kommenttejasi ja toiveitasi. Hyvää yötä ja huomenta kaikille =).

Puhumme POST- tai GET-tietojen validoinnista, vaikka periaatteessa tätä voidaan soveltaa myös muilla tavoilla, kuten evästeillä, vastaanotettuihin tietoihin. Kun kehität mitä tahansa verkkosovellusta, sinun on kirjoitettava käyttöliittymä vuorovaikutusta varten käyttäjien kanssa ja luonnollisesti luotava erilaisia ​​lomakkeita, joiden avulla käyttäjät voivat lähettää tietoja palvelimelle. nämä voivat olla esimerkiksi kommentteja. Mielestäni kaikille on selvää ja selvää, että vastaanotetut tiedot on tarkistettava, jotta voidaan nähdä, vastaavatko ne tyyppiä, kokoa ja määritettyä aluetta. Ensinnäkin tämä on välttämätöntä järjestelmän, verkkosivuston tai tietokannan turvallisuuden vuoksi, koska... Väärin lähetetyt tiedot tai tarkoituksella huonosti muotoiltu pyyntö voivat avata pääsyn hyökkääjälle.

Toiseksi, vahvistamattomat tiedot, jos ne ovat virheellisiä, voivat aiheuttaa skriptin, järjestelmän tai koko palvelimen epävakaan toiminnan. Siksi kaikki tiedot on tarkistettava ja tarkistettava uudelleen, ehkä joku sanoo, että liialliseen vainoharhaisuuteen ei ole tarvetta, mutta uskon, että tässä asiassa se ei yksinkertaisesti voi olla liiallista.

Älä luota käyttäjiltä saatuihin tietoihin millään tekosyyllä tai missään olosuhteissa. Tapahtuu, että olemme yksinkertaisesti liian laiskoja kirjoittamaan koodia, joka tarkistaa vastaanotetut tiedot vielä kerran, tai toivomme sitä olemassa olevia menetelmiä tarkastus riittää, minkä seurauksena teemme myönnytyksiä itsellemme.

Pieni poikkeama aiheeseen:
Projektien parissa työskentely, verkkosivujen, skriptien ja muiden järjestelmien kehittäminen ja ohjelmointi vie lähes kaiken vapaa-ajan (työajan lisäksi), eli teen tätä työtä mahdollisimman paljon vuorokaudessa. Ajoittain on tarvetta testata jotain, huvin vuoksi tai vain uteliaisuuden vuoksi. Tämän seurauksena sivustoista, jotka on tehty kiireessä, käyttämällä kotitekoisia moottoreita tai vanhojen versioiden CMS-järjestelmiä, tulee samanlaisia ​​​​testauslaboratoriorottia. Tietenkin kaikki edellä mainitut kärsivät väärin kirjoitetusta koodista, tiedonhallinnan puutteesta ja ovat yksinkertaisesti täynnä erilaisia ​​​​virheitä. Itse asiassa useimmissa tapauksissa onnistun löytämään tällaisilla sivustoilla tunnin aikana useita vakavia haavoittuvuuksia, ja suurin osa niistä johtuu saapuvien tietojen riittämättömästä validoinnista. IN viime aikoina Tämä löytyy usein komentosarjoista, jotka käsittelevät JavaScriptin + Ajaxin POST-tietoja.

Ilmeisesti ohjelmoijat, jotka kirjoittivat nämä komentosarjat Ajaxilla, uskovat, että koska kaikki pyynnöt tapahtuvat taustalla, käyttäjän tietämättä tai yksinkertaisesti lataamatta sivua uudelleen, tietoja ei tarvitse erityisesti tarkistaa.

Yleensä melko monet näistä skripteistä osoittautuvat niin täynnä reikiä, että he onnistuvat ilman suuria ponnistuksia tekemään suuremman reiän ja tulvimaan kuorensa. tietysti vain kokeilutarkoituksessa eikä sen enempää (tällaisten sivustojen hallinnolle ilmoitetaan aina olemassa olevista haavoittuvuuksista).

Uskon, että validoinnin merkitys on kaikille selvä. Pitkän aikaa kirjoitin joka kerta saman koodinpätkän ja käytin sitten omia tietojen vahvistustoimintojani, joista monet olivat hyvin primitiivisiä ja yleensä hajallaan. eri osia(liitetyt) tiedostot. Pian aloin tutustua PHP-kehyksiin Zend, CI, Kohana, joista jokainen toteutti oman luokkansa projekteihini lainaamieni tietojen validoimiseksi. Lopulta päätin räätälöidä yhden CI-luokista tarpeitani vastaavaksi, mutta kävi ilmi, että yhden ohjelmointiblogin kirjoittaja oli jo huolehtinut tästä. Seuraavaksi jaan hänen teoksensa, nimittäin muokatun CodeIgniter-kirjaston.

Katsotaanpa seuraavaa koodia:

Katso koodi PHP

request_once "validator.class.php" ;

$validator = new Validator() ; $validator -> set_rules ("nimi" , "Nimesi" , array ("pakollinen" => , "alpha" => ) ) ;$validator -> set_rules ("sähköposti" , "Sähköpostisi" , array ("pakollinen" => "Kenttä %s vaaditaan" , "valid_email" => ) ) ; if ($validator -> run () ) ( echo "Tarkistus onnistui" ; ) else ( echo $validator -> get_string_errors () ; ).
Kuten esimerkistä näkyy, ensimmäiselle riville sisällytetään luokkatiedosto validator.calss.php meidän käsikirjoitukseen. Seuraavaksi luomme luokan esiintymän ja tallennamme objektin muuttujaan

$validaattori

Sitten menetelmällä$validator->set_rules($field, $label, $rules)

aseta kentät vahvistusta varten. Tämä menetelmä vaatii 3 parametria:

$kenttä- vahvistuskentän nimi (tunnisteen name-attribuutin arvo)

$label - vahvistuskentän nimi, lisätään virheilmoituksiin$säännöt - validointisääntöjen joukko, jossa vahvistussääntöä käytetään avaimena ja tämän säännön virheilmoitusta käytetään arvona Kun kaikki validointikentät on asetettu, käynnistämme validaattorin menetelmällä $validator->run().

. Jos validointi onnistui, tämä menetelmä palauttaa arvon

TOTTA, muuten, jos virheitä ilmenee, se palaa

EPÄTOSI Virheilmoitusten vastaanottamiseen on kolme tapaa:

get_string_errors()- palauttaa kaikki virheilmoitukset merkkijonona

get_array_errors() — palauttaa kaikki viestit taulukkona, jossa kentän nimeä käytetään avaimena ja tämän kentän virheen kuvausta arvona. muoto_virhe($kenttä)- palauttaa virheilmoituksen $field-parametrina lähetetystä kentästä

Oletusarvoisesti virheilmoitukset kääritään tunnisteeseen . Määritä malli käyttämällä menetelmää set_error_delimiters($etuliite, $liite) . Esimerkiksi näin:

Virheilmoitukset näkyvät nyt muodossa

Katso koodi PHP

div

luokan kanssa "virhe" Kuten näet, kaikki on hyvin yksinkertaista.

Katso koodi PHP

$rules = array ( array ( "field" => "name" , "label" => "Nimesi" , "rules" => array ( "pakollinen" => "Kenttä %s vaaditaan" , "alpha" = > "Kenttä %s saa sisältää vain kirjaimia" ) , array ( "field" => "email" , "label" => "Sähköpostisi" , "rules" => array ( "pakollinen" => "Kenttä % s on pakollinen" , "valid_email" => "Kentän %s tulee sisältää kelvollinen sähköpostiosoite" ) ) ) ;

$validator -> set_rules ($säännöt ) ;

Kuten näette, kirjoitin muistiin samat validointisäännöt kuin ensimmäisessä esimerkissä, vain moniulotteisen assosiatiivisen taulukon muodossa. Voit käyttää mitä tahansa menetelmää, joka sopii sinulle parhaiten tietyssä tilanteessa.

Joten mitä vahvistussääntöjä tämä luokka tukee? Toin tälle tunnille yleisimmät validointisäännöt, joita kaikki kohtaavat. Tässä täydellinen lista

nämä säännöt:	tarvitaan
Palauttaa FALSE, jos kenttä on tyhjä	kokonaisluku
Palauttaa arvon FALSE, jos arvo ei ole kokonaisluku	kellua
Palauttaa arvon FALSE, jos arvo ei ole numeerinen arvo	valid_url
Palauttaa arvon FALSE, jos arvo ei ole kelvollinen URL-osoite	valid_email
Palauttaa FALSE, jos arvo ei ole kelvollinen sähköpostiosoite	valid_ip
Palauttaa FALSE, jos IP-osoite ei ole kelvollinen	otteluita
Palauttaa FALSE, jos elementti ei vastaa toisen kenttäelementin arvoa	alfa
Palauttaa FALSE, jos elementti sisältää enemmän kuin vain kirjaimia	valid_captcha
Palauttaa arvon FALSE, jos istuntokentän arvo ei ole sama kuin lomakekentän arvo	valid_date

Palauttaa FALSE, jos elementti sisältää virheellisen päivämäärän

Useimmat näistä säännöistä käyttävät suodattimia, jotka tulivat saataville PHP 5:ssä.

Halutessasi voit aina laajentaa validoinnin sääntöjoukkoa lisäämällä tarvittavat funktiot Validator-luokkaan.

Katso koodi PHP

Saadaksesi käsitellyt POST-data-arvot, käytä seuraavaa menetelmää:

Edellisessä artikkelissa lupasin kirjoittaa vertailun omasta kirjastostani muihin saatavilla oleviin ratkaisuihin, joten tänään tarkastelemme validointia käyttämällä Aura.Filter-, Respect Validation-, Sirius Validation- ja Valitron-sovellusta.

Tyypillisesti tätä menetelmää kutsutaan tyhjentämään lomake, kun lomake on käsitelty onnistuneesti.

nimi. Täytyy sisältää täsmälleen kaksi sanaa, joista ensimmäinen on käyttäjän etunimi ja toinen on sukunimi.

kirjaudu sisään.

Kuvittelemme, että meillä on kehitteillä tietty julkinen palvelu, joka edellyttää käyttäjien rekisteröitymistä saadakseen täyden pääsyn kaikkiin toimintoihin. Ilmoittautumislomake sisältää siis seuraavat kentät:

Täytyy sisältää kelvollinen osoite

sähköposti

salasana. On oltava asetettu ja saa olla enintään 64 merkkiä pitkä.

sovittu.

Tyypillinen valintaruutu, joka käyttäjän on tarkistettava vahvistaakseen hyväksyvänsä käyttöehdot.

Meillä on siis viisi kenttää, jotka käyttäjän on täytettävä voidakseen rekisteröityä kuvitteelliseen palveluumme. Oletetaan, että saimme syötteenä täysin virheellisiä tietoja:

$data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla olla sähköposti "salasana" => Aura.Filter

Validointi Aura.Filterillä alkaa suodatintehtaasta. Meidän on luotava niin kutsuttu "aihesuodatin", koska vahvistamme taulukon, emme yksittäistä arvoa.

Määrittelemme säännöt käyttämällä Aura\Filter\FilterFactory; $suodatin = (uusi FilterFactory)->newSubjectFilter(); $filter->validate("nimi") ->isNotBlank() ->is("kaksi_sanaa") ->setMessage("Nimen tulee olla kaksi sanaa."); $filter->validate("login") ->isBlankOr("alnum") ->setMessage("Jos määrität kirjautumistunnuksen, sen tulee sisältää vain latinalaisia ​​merkkejä."); $filter->validate("email") ->isNotBlank() ->is("sähköposti") ->setMessage("Anna kelvollinen sähköpostiosoite."); $filter->validate("salasana") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Kirjoita salasanasi."); $filter->validate("sovittu") ->is("takaisinsoitto", function($subject, $field) ( return $subject->($field) === true; ))->setMessage("Tarvitset hyväksyä käyttöehdot.");

Kuten näet, sääntöjen kuvaus on melko yksinkertainen. Aura.Filter tarjoaa kokonaisen joukon hyödyllisiä sääntöjä heti, ja joitain niistä käytettiin yllä olevassa esimerkissä:

isNotBlank -menetelmä.

sähköposti.

Olet todennäköisesti huomannut, että en määrittänyt two_words -sääntöä. Luonnollisesti Aura.Filterissä ei ole tällaista sääntöä, joten meidän on luotava sellainen. Kuten dokumentaatiossa sanotaan, tämä tehdään käyttämällä erillistä luokkaa säännölle:

/** * Sääntö, joka vahvistaa käyttäjänimen.

* Käyttäjätunnus koostuu kahdesta sanasta: etu- ja sukunimi, erotettuna yhdellä välilyönnillä.

*/ class UserNameRule ( /** * Vahvistaa käyttäjänimen. * * @param object|array $subject * @param string $field * @param int $max * * @return bool */ julkinen funktio __invoke($subject, $field , $max = null) ( $arvo = $aihe->($kenttä); if (! is_scalar($value)) ( return false; ) return (bool) preg_match("/^+\s+$/u", $arvo);

Toinen vaihe on kertoa suodatintehtaalle uudesta säännöstämme. Se tehdään välittämällä ensimmäinen argumentti sääntöjoukona suodatintehtaalle:

Seuraava askel on ilmoittaa Aura.Filterille, että olemme luoneet uuden säännön ja haluamme käyttää sitä. Tämä tehdään välittämällä joukko sääntöjä tehtaan ensimmäiselle argumentille:

käytä Aura\Filter\FilterFactorya; $säännöt = [ "kaksi_sanaa" => function() (palauta uusi Käyttäjänimisääntö; ) ]; $suodatin = (uusi FilterFactory($säännöt))->newSubjectFilter();

Nyt kaksi_sana-sääntöämme voidaan käyttää samalla tavalla kuin mitä tahansa muuta vakiosääntöä.

Palaute

Kuten muistat, vahvistamamme saapuvat tiedot ovat täysin virheellisiä, koska jokainen kenttä sisältää virheellisen arvon tai ei sisällä sitä ollenkaan. Siksi oletetaan, että validoinnin tuloksena saamme virheitä ja niitä koskevia vastaavia viestejä.

Vahvistamme Aura.Filterillä seuraavasti: $valid = $suodatin->apply($data); if (! $valid) ( $epäonnistuminen = $suodatin->getFailures(); $viestit = $epäonnistuminen->getMessages(); ) IN

$viestiä

taulukkoa kirjoitetaan, joten viestien näyttämiseen tarvitsemme kaksi sisäkkäistä foreachia:

Kunnioita validointia

käytä Respect\Validation\Validator muodossa v; $data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla ole sähköposti täällä "password" => "" // Salasanaa ei ole määritetty ollenkaan // "sopiva" ei ole taulukossa, koska käyttäjä ei valinnut ruutua ];

Sääntöjen määrittely

Kuten Aura.Filterissä, tarvitsemme oman vahvistussäännön käyttäjätunnukselle, joten aloitetaan siitä:

nimiavaruus MyNamespace; käytä Respect\Validation\Rules\AbstractRule; luokka UserNameRule laajentaa AbstractRule:n ( julkinen funktio valide($input) ( return (bool) preg_match("/^+\s+$/u", $input); ) )

Ulkoisten sääntöjen API on lähes identtinen Aura.Filterin kanssa, vain valide()-menetelmää käytetään __invoke()-taikuuden sijaan. Minusta tämä API näytti yksinkertaisemmalta ja ymmärrettävämmältä. No, se on lähempänä Kontroliota :).

En löytänyt dokumentaatiosta mainintaa tästä, mutta itse säännön lisäksi sinun on luotava sille oma poikkeustyyppi. Poikkeusluokan nimen tulee koostua sääntöluokan nimestä ja jälkiliitteestä

Poikkeus

käytä Respect\Validation\Exceptions\NestedValidationException; luokka UserNameRuleException laajentaa NestedValidationExceptionin ( // )

No, vihdoin voimme vahvistaa tietomme. Ensin välitämme uuden sääntömme validaattorille, jotta hän tietää siitä ja voimme käyttää sitä tulevaisuudessa. Respect Validationissa tämä tehdään kutsumalla with()-metodia, joka välittää nimitilan, jossa epästandardit säännöt sijaitsevat. v::with("OmaNimitila\\"); Nyt kaikki epästandardit säännöt sijaitsevat nimiavaruudessa

OmaNimiavaruus

, validaattori "tunnistaa". Seuraava vaihe on kuvata tarvittavat säännöt ja suorittaa validointi. v::attribute("nimi", v::userNameRule()) ->attribute("kirjautuminen", v::alnum("-_")) ->attribute("email", v::email()) ->attribuutti("salasana", v::notEmpty()->stringType()->length(null, 64)) ->attribute("sovittu", v::trueVal()) ->assert((objekti) $data); Huomaa, kuinka käytämme sääntöämme attribuutissa

nimi . Tässä sääntöluokan nimi on muutettu validointimenetelmän nimeksi. Loput säännöt ovat yleensä intuitiivisia. On syytä mainita erikseen, miksi tarjoamme taulukon

käytä Aura\Filter\FilterFactorya; $säännöt = [ "kaksi_sanaa" => function() (palauta uusi Käyttäjänimisääntö; ) ]; $suodatin = (uusi FilterFactory($säännöt))->newSubjectFilter();

Toisin kuin Aura.Filter, Respect-validaattori antaa poikkeuksen, kun vahvistus epäonnistuu. Ja tämä poikkeus sisältää vahvistusvirheilmoituksia. Siksi juuri esitetty esimerkki tulisi kirjoittaa seuraavasti:

try ( v::with("RespectValidationExample\\"); v::attribute("nimi", v::userNameRule()) ->attribute("kirjautuminen", v::alnum("-_")) - >attribute("email", v::email()) ->attribute("salasana", v::notEmpty()->stringType()->length(null, 64)) ->attribute("sovittu", v::trueVal()) ->assert((objekti) $data ) catch (NestedValidationException $ex) ( $viestit = $ex->getMessages(); )

Käyttämällä getMessages() saamme tasaisen joukon kaikista viesteistä, jotka validaattori keräsi vahvistusprosessin aikana. Pudottamalla taulukon saamme jotain tällaista:

array(5) ( => string(29) "Tietojen vahvistus epäonnistui kohteelle %s" => string(60) "kirjautumisessa saa olla vain kirjaimia (a-z), numeroita (0-9) ja "-_"" => merkkijono (25) "sähköpostin on oltava kelvollinen sähköposti" => string(26) "salasana ei saa olla tyhjä" => string(32) "Sovitun attribuutin on oltava läsnä" )

Voit muuttaa viestit omiksi. Ehkä ymmärsin jotenkin väärin tämän kirjaston, mutta tämä prosessi ei tuntunut minusta niin itsestään selvältä: sinun on käytettävä findMessages()-menetelmää käsitellyssä poikkeuksessa, jossa määrität viestejä ei attribuuteille, vaan säännöille.

$ex->findMessages([ "userNameRule" => "Käyttäjätunnuksen tulee koostua kahdesta sanasta.", "alnum" => "Emme pidä kirjautumistunnuksestasi.", "email" => "Et tietenkään pidä haluat antaa meille sähköpostiosoitteesi.", "notEmpty" => "No, missä salasanasi on?", "agreed" => "On sääli, että olet eri mieltä." ]);

En tiedä mikä on vialla, mutta on pari asiaa, joita en vieläkään ymmärrä. Tämän saamme määrittelemällä säännöt yllä olevalla tavalla:

array(5) ( => string(40) "Käyttäjätunnuksessa on oltava kaksi sanaa." => string(31) "Emme pidä kirjautumisestasi." => string(25) "sähköpostin on oltava kelvollinen sähköpostiosoite" = > string(5) "No, missä on salasanasi?" => string(9) "On sääli, että et ole samaa mieltä."

Kuten näet, sähköpostikentän viestiä ei sovellettu, vaan tavallinen viesti säilyi. Mutta viesti indeksissä 4 on päinvastainen! Ja tämä huolimatta siitä, että en käyttänyt säännön nimeä, vaan kentän nimeä. Jos taas olisin käyttänyt säännön nimeä (trueVal), viestini olisi kadonnut jonnekin. Tämän kirjaston kokeneiden käyttäjien kommentit ovat erittäin tervetulleita.

Siriuksen vahvistus

Ok, siirrytään seuraavaan kirjastoon ja katsotaan, kuinka se käsittelee samanlaisia ​​tehtäviä.

Sääntöjen määrittely

Jälleen kerran meidän on määritettävä sääntö käyttäjätunnukselle. Kirjoitamme sen jotenkin näin:

class UserNameRule laajentaa AbstractRule ( // Virheilmoitukset const MESSAGE = "Käyttäjänimessä on oltava kaksi sanaa."; const LABELED_MESSAGE = "(tunnisteen) on oltava kaksi sanaa."; julkinen funktio valide($value, $valueIdentifier = null ) ( return (bool) preg_match("/^+\s+$/u", $arvo ) )

Huomaa ero lähestymistavoissa verrattuna jo käsiteltyihin kirjastoihin. Määrittelemme kahdenlaisia ​​viestejä vakioissa sen sijaan, että käytämme ominaisuuksia, menetelmiä tai sääntöargumentteja.

Kuvataan nyt validointilogiikka:

$validator = uusi Validator; $validator ->add("nimi", "pakollinen | MyApp\Validation\Rule\UserNameRule") ->add("kirjautuminen", "pakollinen | alphanumyphen", null, "Kirjautuminen voi sisältää vain latinalaisia ​​kirjaimia, väliviivoja ja alaviivoja. ") ->add("email", "required | email", null, "Anna oikea sähköpostiosoite.") ->add("salasana", "pakollinen | maxlength(64)", null, "Sinun salasana, sir.") ->add("hyväksyn", "tarvitaan | yhtäläinen(tosi)", null, "Miksi et suostunut?");

Kuten näette, sääntösarja on hyvin yksinkertainen ja luettava. Kuvauksessa käytämme vaakapalkilla erotettuja nimiä. Tämä lähestymistapa on samanlainen kuin Laravelissa ja Kontroliossa käytetty.

Add()-menetelmän neljäs argumentti kuvaa vahvistusvirhesanoman, jota Sirius käyttää, jos vahvistus epäonnistuu. Miksi emme lisänneet viestiä uudelle säännöllemme? UserNameRule?

$validator->add("nimi", "pakollinen | MyApp\Validation\Rule\UserNameRule")

Tämä johtuu siitä, että viestit on jo kuvattu luokkavakioissa:

class UserNameRule extends AbstractRule ( // Error messages const MESSAGE = "Käyttäjänimessä on oltava kaksi sanaa."; ...

Toinen vaihtoehto on käyttää itse validaattorin addMessage()-menetelmää:

$validator->addMessage("sähköposti", "Anna kelvollinen sähköpostiosoite.");

Huomaa, että mukautetut säännöt tunnistetaan niiden luokan koko nimellä, kun taas Kontroliossa voit määrittää aliaksen/aliaksen.

käytä Aura\Filter\FilterFactorya; $säännöt = [ "kaksi_sanaa" => function() (palauta uusi Käyttäjänimisääntö; ) ]; $suodatin = (uusi FilterFactory($säännöt))->newSubjectFilter();

Tarkistuksen suorittamiseksi kutsumme validointimenetelmää validate() ja välitämme tiedot sille:

$data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla ole sähköposti täällä "password" => "" // Salasanaa ei ole määritetty ollenkaan // "sopiva" ei ole taulukossa, koska käyttäjä ei valinnut ruutua ]; $validator->validate($data);

Toisin kuin Respect, Sirius ei tee poikkeusta, vaan palaa yksinkertaisesti väärä. Vahvistusvirheilmoitukset voidaan saada getMessages()-validaattorimenetelmällä. Se palauttaa attribuuttien mukaan ryhmitellyt virheet, joten tarvitsemme kaksi foreach-silmukkaa käydäksemme läpi virheitä:

foreach ($validator->getMessages() $attribuuttina => $viestit) ( foreach ($viestit $viestinä) ( echo $message->getTemplate() . "\n"; ) )

Tässä $viesti on luokkaobjekti Sirius\Validation\ErrorMessage, jossa on getTemplate()-metodi, joka palauttaa juuri tarvitsemamme viestin.

Valitron Sääntöjen määrittäminen

Ensimmäinen ero: uuden säännön lisäämiseksi sinun ei tarvitse luoda erillistä luokkaa. Voit yksinkertaisesti käyttää sulkemista, joka palauttaa loogisen tuloksen.

Mukautettujen sääntöjen lisäämiseksi Valitronilla on staattinen menetelmä addRule(), jossa kaksi ensimmäistä argumenttia vaaditaan ja kolmas on valinnainen. Pidin tästä menetelmästä, koska tässä säännön tunniste, logiikka ja virheilmoitus on ilmoitettu yhdessä paikassa.

käytä Valitron\Validator; Validator::addRule("kaksi_sanaa", function($field, $value) ( ​​return (bool) preg_match("/^+\s+$/u", $value); ), "Käyttäjätunnuksen tulee koostua tarkalleen kaksi sanaa ");

Toinen ero on se, miten sääntöjä sovelletaan attribuutteihin. Kaikissa aiemmissa tapauksissa näimme, että attribuutti on ikään kuin ensisijainen asia.

Valitron valitsi toisen reitin ja asetti validointisäännöt etusijalle. Kuvaamalla sääntöjä näytät soveltavan attribuutteja näihin sääntöihin, etkä päinvastoin.

$validator = new Validator($data); $validator ->rule("kaksi_sanaa", "nimi")->label("") ->rule("pakollinen", [ "nimi", "kirjautuminen", "sähköposti", "salasana", "sovittu" ] ) ->rule("slug", "login") ->rule("sähköposti", "sähköposti") ->sääntö("hyväksytty", "sovittu");

Kuten esimerkistä voidaan nähdä, rulla()-metodissa kirjoitamme ensin säännön nimen ja vasta sitten ilmoitamme attribuutit, joiden on vastattava tätä sääntöä. Tarkempi esimerkki on pakollinen sääntö, joka osoittaa, kuinka attribuutit "kuuluvat" kyseiseen sääntöön.

Valitron (kuten muutkin tarkastelemamme ratkaisut) tarjoaa vakiovirheilmoituksia. Jos käytät niitä vain, näet, että jokainen viesti alkaa vastaavan määritteen nimellä.

Valitron korvaa attribuuttien nimet sanoman tekstissä, vaikka käytettäisiin epätyypillisiä virheilmoituksia. Tästä syystä käytimme label()-metodia tyhjän merkkijonon kanssa attribuutin nimen poistamiseen.

$validator->rule("kaksi_sanaa", "nimi")->label("") Palaute

Erityisesti validoinnin osalta Valitron-kirjaston API ei käytännössä eroa siitä, mitä olemme jo nähneet artikkelissa. Tarkistuksen suorittamiseksi kutsumme validointimenetelmää validate() :

$validator->validate();

Vahvistusvirheilmoitukset voidaan hakea getErrors()-menetelmällä:

$validator->errors();

Viestit ryhmitellään tässä attribuuttien mukaan samalla tavalla kuin Sirius Validationissa, paitsi että viestille ei ole erillistä luokkaa ja saamme tavallisen moniulotteisen taulukon.

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

Ja lopuksi, tämän päivän viimeinen kirjasto on oma kehitystyöni nimeltä Kontrolio.

Sääntöjen määrittely

Luomme jälleen viidennen kerran käyttäjätunnukselle vahvistussäännön. Kaikki on suhteellisen yksinkertaista ja standardia:

nimiavaruus MyProject\Validation\Rules; käytä Kontrolio\Rules\AbstractRule; luokka TwoWords laajentaa Kontrolio\Rules\AbstractRule ( julkinen funktio onValid($input = null) ( return (bool) preg_match("/^+\s+$/u", $syöte); ) )

Nyt luomme tehtaan ja rekisteröimme siihen säännön extend()-menetelmällä:

nimiavaruus MyProject; käytä Kontrolio\Factory; käytä MyProject\Validation\Rules\TwoWords; $factory = Kontrolio\Factory::getInstance()->extend();

Säännön rekisteröinnin jälkeen voimme käyttää sitä, myös nimellä - two_words. Luodaan validaattori:

$data = [ "nimi" => "Albert", // Täytyy olla kaksi sanaa "login" => "@lbert", // "Kielletty" merkki @ "email" => "jotain vialla", / / ​​Siellä pitäisi olla ole sähköposti täällä "password" => "" // Salasanaa ei ole määritetty ollenkaan // "sopiva" ei ole taulukossa, koska käyttäjä ei valinnut ruutua ]; $rules = [ "nimi" => "kaksi_sanaa", "login" => "sometime|alphadash", "email" => "sähköposti", "salasana" => "pituus:1.64", "sovittu" = > " hyväksytty" ]; $messages = [ "name" => "Käyttäjätunnuksen tulee koostua kahdesta sanasta.", "login" => "Emme pidä kirjautumistunnuksestasi.", "email" => "Et ilmeisesti halua antaa us your email .", "password" => "No, missä on salasanasi?", "agreed" => "On sääli, että et ole samaa mieltä." ]; $validator = $tehdas->make($data, $säännöt, $viestit);

Kuvailimme säännöt käyttämällä samanlaista syntaksia kuin Laravelissa, vaikka olisimme voineet käyttää monisanaisempaa versiota:

$rules = [ "nimi" => new TwoWords, "login" => , "email" => new Sähköposti, "salasana" => new Length(1, 64), "agreed" => new Hyväksytty ];

Palaute

$validator->validate();

Validointi aloitetaan käyttämällä samaa validite()-menetelmää:

Nyt voimme saada virheilmoituksia jollakin getErrors()- tai getErrorsList()-menetelmistä. Ensimmäinen menetelmä mahdollistaa monimutkaisemman virhetulostuksen, kun taas toinen palauttaa tasaisen taulukon. Käyttämällä getErrors() voimme tulostaa viestejä, jotka ovat jotain tämän kaltaisia:

Ja getErrorsList():llä voit tehdä yksinkertaisemman luettelon viesteistä:

Bottom line

Tässä artikkelissa näytin esimerkkejä seuraavien kirjastojen käytöstä:

Aura.Suodatin

Siriuksen vahvistus

Kunnioita validointia

Valitron

ohjata

"Tosimaailman esimerkki" saattaa tuntua liian yksinkertaiselta. Minun on myönnettävä, koska artikkelista on jätetty pois joitakin kirjaston ominaisuuksia. Periaatteessa, jos olet kiinnostunut, voit tutkia niiden ominaisuuksia itse.

Jokaisessa kirjastossa on omat ominaisuutensa ja pimeät puolensa, joten mielestäni on makuasia ja haaste valita sellainen.

Täytyy sisältää kelvollinen sähköpostiosoite.

• takaisinsoitto.
• Tämäntyyppinen sääntö on samanlainen kuin Kontrolion sulkemiset. Sen avulla voit määrittää säännön sulkemisen muodossa. Tähän sulkemiseen Aura.Filter välittää "aiheen", lomakkeen tietojoukon ja kentän, tässä tapauksessa sovitun .
• Tunnisteet:

tietojen validointi