Tak piszę sobie powoli mój framework i ostatnio zobaczyłem w Zendzie fajne rozwiązanie validatora . Trochę składnia zenda do mnie nie przemawia wiec napisałem coś swojego.

Dla nieobczajonych. Klasa sprawdza poprawność elementów w tablicy na podstawie określonych wymogów.

Przyklad uzycia

[PHP] pobierz, plaintext 
<?php
include 'validator.php';
 
$validators = Array(
	'*' => Array(
	'required' => true
	),
	'title' => Array(
	'minlength' => 5,
	'maxlength' => 80,
	),
	'subtitle' => Array(
	'minlength' => 5,
	'required' => false,
	)
);
 
$dane = Array('title' => 'jakis tytul');
 
$input = new MoheboInput($dane);
$input -> setValidators($validators);
echo 'title => '.(integer) $input -> isValid('title').'<br/>';
echo 'subtitle => '.(integer) $input -> isValid('subtitle').'<br/>';
?>
[PHP] pobierz, plaintext 

* odnosi się do wszystkich zmiennych przy czym wlaściwości elementu sa zawsze nadrzędne(tj. gwiazdka ma zawsze mniejszy priorytet, nawet jesli podamy ją jako ostatni element tablicy).

Dostępne wymagania
minlength - minimalna długość
maxlength - maksymalna dlugosc
required - czy element nie moze byc pusty(czy jest wymagany)
between - wartosc musi sie miescic w podanym zakresie
in - wartosc musi byc identyczna z jedna sposrod podanych
type - typ zmiennej (tj. string, boolean, double, integer) lub obiekt klasy własnej.

Jeśli deklarujemy wlasny typ to jako type przekazujemy obiekt naszej klasy pamietajac ze musi ona zawietac metodę isValid(), oraz zmienna $errors oraz zmienna $value

Wiecej w przykladzie dostepnm w paczce.

Pobierz

Czekam na komentarze oraz pomysły na rozwinięcie listy wymagań oraz ogólnie opcji validatora.

Bardzo fajne narzędzie, jak wiesz sam coś takiego piszę więc wiem Ogólnie napiszę co wydaje mi się że mógł byś dodać

1) Porządek w kodzie
2) W typie mogły by być wartości standardowe typu telefon, www, e-mail czy nawet ten pesel
3) Jeśli sprawdzę wszystkie pola, a później której osobno to sprawdza od nowa. Mógłbyś gdzieś zapisywać czy pole jest poprawnie wypełnione czy nie aby nie sprawdzać po 2 razy.
4) Komunikaty błędów mogłeś zrobić nie jako wiadomości a jako identyfikatory danego błędu. Można później łatwiej na nich operować

To takie drobne uwagi spowodowane tym że sam pisze teraz taką bibliotekę, więc napisałem to co u siebie zrobiłem w inny sposób Ale ogólnie klasa spoko i taki sposób walidacji naprawdę ułatwia

ps. Twoja klasa ma równo 100 linii mniej Ale ja u siebie każdą opcje dawałem jako osobną metodę, więc to dla tego

@Moli: dzięki za komentarz. Co do opcji

1. Porzadek zrobiony, kod odchudziłem o okolo 40 linijek i jeszcze widzę możliwość optymalizacji(ale to w wolnym czasie)
2. Dodałem obsługę pola e-mail. Pesel jest typowo polskim wymysłem a z numerem telefonu jest tak, że nikt się nie trzyma standardowego zapisu +48.numer,
3. Cachowanie winików dodane
4. Tak jest mi wygodniej . Może zastosuje system stałych i komunikatów deklarowanych w jeden z zmiennych klasowych w postaci tablicy. Jeszcze nad tym pomyślę.

Dodatkowo dodalem parametr regexp umożliwiający określenie wyrażenia regularnego(w example.php jest pokazane użycie)

Nowa paczka: Pobierz
Licencja : AGPL3

Pozdrawiam

Ja u siebie trochę inaczej to rozwiązałem, ale:
1) Pliki są w kodowaniu UTF-8, dlatego też zamiast np. strlen" title="Zobacz w manualu PHP" target="_manual używaj mb_strlen" title="Zobacz w manualu PHP" target="_manual

[PHP] pobierz, plaintext 
<?
$str = 'Witaj świecie';
 
echo strlen($str); //14
echo mb_strlen($str); //13 - bo tyle jest znaków
?>
[PHP] pobierz, plaintext 

(pozwole sobie przyspamować http://blog.crozin.com/2008/08/11/operacje...odowanie-utf-8/ )
2) Sprzydałoby się trochę więcej danych w przypadku błędu, dla przykładu:

[PHP] pobierz, plaintext 
<?
//pseudo-kod
$v->maxLength('ala ma kota', 8);
?>
[PHP] pobierz, plaintext 

Zdanie ala ma kota ma więcej niż te 8 znaków, ale samo Too long może być czasem trochę niewygodne (np. gdy chcemy zautomatyzować wyświetlanie błędów użytkownikowi). Tutaj mógłbyś zwrocić: False (czyli, że błąd) + Spodziewaną długość (8) + Długość jaką miał ciąg (13) + ew. sam ciąg - aby wygodnie wyświetlić szczegółowy komunikat
3) Apropo sposobu zgłaszania błedów - sprzydała by się możliwość ustawiania "indywidualnych" błedów - posłużę się tutaj moim przykładem :

[PHP] pobierz, plaintext 
<?php
 
$_POST = array(
  'rules'		  => '0',
  'username'	   => 'Crozin',
  'password'	   => 'myPassword',
  'repeatPassword' => 'myPasssword',
  'email'		  => 'sb@sth.com',
  'repeatEmail'	=> 'sb@sth.com'
);
 
$this->validate->customMessages(array(
  'rules' => array(Kernel_Validate_Equal::NOT_EQUAL => 'Musisz zaakceptować regulamin, aby się zarejestrować')
));
$validate = $this->validate->chain($_POST, array(
  'login'		  => 'length[4,30]|word', 
  'password'	   => 'length[6,255]',
  'repeatPassword' => 'sameAs[password]',
  'email'		  => 'email',
  'repeatEmail'	=> 'sameAs[email]',
  'rules'		  => 'equal[1]'	  
), array(...));
 
?>
[PHP] pobierz, plaintext 

I kilka słów wyjaśnienia.
Kernel_Validate::customMessage() (btw: właśnie się zooriętowałem, że mam customMassages w orginalnym kodzie ) jako pierwszy i jedyny argument przyjmuje tablice, w której każdy klucz odpowiada zmiennej z $_POST (w tym przypadku) a wartość danego klucza to kolejna tablica, w której jako klucz podawane są stałe, np: Kernel_Validate_Equal::NOT_EQUAL - co oznacza, że jeżeli walidator Equal wyrzuci bład NOT_EQUAL to zamiast domyślnej wiadomości Pole [nazwaPola] musi mieć wartość [wartość]. zostanie zwrócone Musisz zaakceptować regulamin, aby się zarejestrować.

Sam walidator działa w miarę podobnie do Twojego, z tym, że reguły walidacji możemy podać jako tablice (jak u Ciebie), albo jako string z "pseudo-kodem", a same walidatory (Equal, sameAs, Email itp.) to klasy implementujące interfejs i dziedziczące po abstrakcyjnej klasie


PS. Nie wiem dlaczego, ale Twój sposób formatowania kodu jest dla mnie strasznie nieczytelny

1) dzięki wielkie za link, przyda się . Widziałem kiedyś w manualu funkcje mb_ ale jakoś nigdy nie wnikałem co czego one służą

2,3) Ostatnio zauwazyłem identyczny rodzaj określania komunikatów błędów w Zendzie i przyznam, że rozwiązanie jest dosyć ciekawe i bardzo prawdopodobne, że wprowadzę je u siebie(jednak muszę to zintegrować z moja klasę do obsługi języków stąd te pseudokomunikaty typu "Too long")

Dzięki za pomysł z sameAs i equal . Pomyślę jak to fajnie złożyć. Pseudojęzyków nie będę wprowadzał. Imho zbędny bajer.

PS: nieczytelność kodu to rzecz względna . Widzę u Ciebie np. tabulacje przed "=>" w deklaracjach tablic i lekko inny system wcięć. Dodatkowo nie stosujesz spacji między " -> " itd itd.

Pozdrawiam

Nic prostszego (pisząc pierwszego posta sam zamieniałem "zmienne językowe" na zwykły tekst)

Tutaj właśnie ważne jest to, aby w przypadku wystąpienia błędu nie zwracać tylko False
Stała Kernel_Validate_Equal::NOT_EQUAL to string notEqual i w przypadku błeu zwracana jest tablicaI klucz tablic to nazwa pola, zero - nazwa walidatora, jeden - wartość zmiennej, dwa - argumenty przekazane walidatorowi (np.: że ma być równe (equal) 1)

Mając te dane wystarczy:

[PHP] pobierz, plaintext 
<?
 
$lang = array(
  'errors' => array(
	'notEqual' => 'Pole "%s" musi mieć wartość %s.',
	'notAlnum' => 'Pole "%s" może składać się tylko ze znaków alfanumerycznych.'
  )
);
 
$validate = array(...); //pow. tablica - a jesli walidacja jest pomyślna to zwraca true
$errors = array();
 
 
if(is_array($validate)){
  foreach($errros as $f => $e){
	$errors[] = sprintf($lang['errors'][$e[0]], $f);
  }
}
 
print_r($errors);
 
?>
[PHP] pobierz, plaintext 

To już pisane z palca, ale chyba powinno być dobrze (musisz sobie oczywiście to nieco mocniej rozbudować)

Dokładnie tak to u mnie działa . Tylko mam zewnętrzną klasę do tego. Ale ogólnie robi to samo. Ważne tylko żebym gotowych komunikatów nie wyciagał a właśnie tablice z komunikatami i odpowiednimi parametrami wtedy mi to się ładnie potłumaczy na inne języki.

Pozdrawiam.