Witam

Nie wiedziałem czy wrzucać to do oceny, bo w sumie bardziej chodzi o to aby ktoś powierzchownie rzucił okiem, czy ide w dobrym kierunku. To moja pierwsza klasa - bazowa, bo chciałbym na niej m.in oprzec pozostałe klasy.

starałem sie uprościć ją do minimum, link do Github'a

jak widać dodanie nowej wartości do walidacji odbywa się w ten sposób:

[PHP] pobierz, plaintext 
$validation = new Validation();
 
$validation -> addKey('imie') -> addValue($_POST['imie']) -> addRules('req,min=3,max=10');
$validation -> addKey('login') -> addValue($_POST['login']) -> addRules('req,min=10');	
$validation -> addKey('haslo') -> addValue($_POST['haslo']) -> addRules('req,login,min=3,max=10,url,striptags,html,int,'); //itd itp
...
$validation -> startValidation(); 
[PHP] pobierz, plaintext 

sprawdzenie czy wszystkie pola przeszły poprawną walidacje wywołuje sie poprzez warunek if(!$validation->errors)
odwołanie się do tablicy błędu, np : $validation->errors['imie'] <- bledy beda wyswietlane po kolei począwszy od pierwszej zadeklarowanej wartości do sprawdzenia

błędów nie ma, wszystko działa, ale jak juz wspomniałem, to moja pierwsza samodzielnie napisana klasa, tak więc chciałbym was prosić o to, abyście mogli podpowiedzieć mi czy robie jakieś błędy lub czego mógłbym jeszcze użyć do niezawodności tej klasy

Hmm,

Czy nie lepiej wygląda to jak dla zestawu pól ("kay") dodajesz walidatory? Każdy walidator ma osobną klasę, dziedziczy po klasie abstrakcyjnej i ma metody do ustawienia wartości i do walidacji. Klasa główna na podstawie konfiguracji "kay" => "walidatory (z opcjami)" i otrzymanych danych sprawdza każde pole z konfiguracji i odpala odpowiednie walidatory?

I w zależności czy konfiguracja główna zezwala na błędy czy nie (break on failure) zwracasz wynik.
Można to nawet dalej rozwinąć tworząc grupy walidacji itd.

BTW to chyba do Oceny

Jak juz piszesz po angielsku to nie rob tak fatalnych literowek jak KAY, szczegolnie ze chwile pozniej jako parametr piszesz KEY

Myslałem o takim rozwiązaniu na samym poczatku. Przez konstruktor klasy Validation wskazywałbym tablicę (superglobalną $_POST / $_GET, albo bym sam wypisywał tablicę dla interesujacych mnie wartośći do sprawdzenia).


tego za bardzo nie rozumiem... Nie byłoby to za dużo (może nawet zbędnej) roboty ? w sumie to tą klase mozna byłoby w ten sposób przerobić, czyli byłaby to poprostu zamiana "case'ów" na klasy. Ale czy to faktycznie byłoby lepsze ? Rozumiem, ze zyskałbym poprostu łatwiejszą modyfikowalność obsługi błędów ?

@nospor
mam z tym czasem problem, a akurat te słówko bardzo łatwo mi sie myli i nie raz bez namysłku przekracam tą literke. Z pewnością poprawie : )
edit: POPRAWIONE : )

W zaproponowanym przeze mnie przykładzie masz większe możliwości:
- przede wszystkim, klasa główna zawiera tylko logikę i w miarę zwiększania ilości walidatorów nie zwiększasz ilości linii w pliku, co wpływa na czytelność,
- łatwiej jest znaleźć miejsce modyfikacji algorytmu konkretnego walidatora
- wygodniej tworzy się metody pomocnicze
- prostsza identyfikacja błędów (id walidatora, albo nazwa klasy) i ich "ludzka" definicja
itd.

Przy 50 i więcej walidatorów w jednej klasie, dalsza rozbudowa będzie męczarnią, a z kolei pomysł powyżej przy użyciu PSR pozwala na łatwe ładowanie tylko potrzebnych walidatorów

dobra, zakutalizowalem klase : )

link : GITGUB

Ogólnie prosze o rzucenie okiem. to moja pierwszy skrypt w oop. Działa pieknie i jest - przynajmniej dla mnie, mocno wygodny : ) Wydaje mi sie ze jest ok, ale wasze oczy moze wyłapią błedy ktore powinienem omijać

w czym lezy wygoda ? Skrypt bardzo latwo mozna rozszerzać o nowe walidatory (może zrobic to nawet laik) oraz sam proces wywołania validacji również jest łatwy i przyjazny:

[PHP] pobierz, plaintext 
//pzyklad
$val = new Validation();
$val -> addValue([
                           "imie" => $_POST['imie'],
                           "login" => $_POST['login']
                         ]);
 
$val -> addKey('imie') -> addRules('req,min=3,max=20,login');
$val -> addKey('login') -> addRules('url');
//itd itp
 
$val -> startValidation();
 
 
//wyswietlanie wartosci 
$val->getValue('imie')
 
//wyswietlanie bledow
$val->getErrors('email')
 
[PHP] pobierz, plaintext 

DODANIE NOWEGO WALIDATORA

[PHP] pobierz, plaintext 
//KROK1
 
//lista walidatorow w klasie abstrakcyjnej Validation_engine.
//nalezy dopisac nowy element tablicy, gdzie klucz to nasza wygodna nazwa walidatora, a wartosc to nazwa metody walidującej
 
protected static $rules_list = array(	
"REQUIRED, REQ" => "_required",
"MINIMUM, MIN" => "_minimum",
"MAXIMUM, MAX" => "_maximum",
"STRIPTAGS, STRIP" => "_striptags",
"HTML" => "_htmlspecialchars",	
"IS_INT, INT" => "_is_int",
"LOGIN" => "_login",
"URL" => "_url"
);
 
//KROK2
 
dodanie do klasy z walidatorami (class Validation) nowej metody, np: 
class Validation extends Validation_engine
{
    protected function _required()
   {
   if(empty($this->value)) { $this->errors[$this->key] = 'te pole musi być uzupełnione'; }
   }
}
 
//KONIEC : )
[PHP] pobierz, plaintext 

Hmm, ok.

Zastanów się co robisz, Validator (sprawdzanie poprawności wprowadzonych danych) czy też Filter (przefiltrowanie wprowadzonych danych i w miarę możliwości zwrócenie poprawnego formatu).

Ponadto, pomysł z dodawaniem metody i jednoczesnym aktualizowaniu tablicy statycznej nie trafiony. Przecież możesz sobie ustalić że metody walidacji to takie które zaczynają się od _valid__nazwa i przy pomocy call i callStatic wybierać odpowiednie metody (ewentualnie method_exists podczas walidacji zbiorowej).

Pomyśl jeszcze nad tym, że czasami chcemy sprawdzić poprawność 1 elementu i tworzenie takiej formułki jest zbędne.
zamiast ustawiać wartości pól i później ich walidatory ja bym odwrócił proces, najpierw ustawiamy grupę elementów walidacji, i od razu ich walidatory a na koniec wartości tych pól w jakiejś tablicy, i wtedy wywołanie już samej metody która wykonuje proces walidacji. Wtedy zniknie ci problem z AddValues/__construct.


ECHO w klasie? A nie ładniej by było, gdyby te błędy były zbierane do obiektu/zmiennej w tej klasie? Wtedy dajesz metodę do pobrania wszystkich komunikatów i wyświetlasz je w odpowiednim formacie, nie narzuconym z góry. To samo z wartościami.

Dlaczego postanowiłeś postawić na tablicę z nazwami walidatorów, które umieściłeś w Engine, natomiast sama deklaracja metod jest w klasie dziedziczącej?

Tutaj masz racje. filtry typu striptags/htmlspecialchar nie powinny tutaj istnieć. Jednak ten skrypt bedzie stosowany tylko dla moich potrzeb i nie robie tego "komercyjnie". Sens tych 2 metod jest znikomy - a nawet żadny, ale dodałem je - przyjnajmiej tymczasowo, dla zwykłego picu : ) Powinienem o tym był wspomnieć...



co do call to chcialem własnie uniknąć wywoływania walidatorów w style " ->required() ->max(12) -> is_int() itd. Osobiscie bardziiej przypada mi do gustu wywoływanie jedenej metody i w niej podawania walidatorów. Tablice statyczna powstała po to aby móc wszystko ustawwić na poczatku dokumentu w klasie abstrakcyjnej. Wcześniejsza wersja opierała się na case'ach i to faktycznie było nietrafione rozwiązanie - co nie oznacza, ze obecna metoda jest elegancka. Tak to jednak sobie wymyśliłem


Tutaj też masz racje. Obsługe błędów musze jeszcze dopracowac. A pomysł jak najbardziej fajny : )




powód taki sam jaki podałem wczesniej. Chciałem aby cały mechanizm obsługi był tylko w jedenej klasie abstrakcyjnej, tak abym w klasie dziedziczącej mógł skupić sie tylko na metodach walidujących : )

Pisząc ten skrypt na nowo, kierowąłem się głównie tym co sam mi napisałeś w tym temacie:



dokladnie wlasnie zrobiłem to w ten deseń : )
- logika tylko w jednej klasie
- oddzielilem walidatory do osobnej klasy i moge łatwo je edytowac oraz rozwiac w razie potrzeby
- metody pomocnicze rowniez mozna latwo dopisać
- tutaj tez sie kierowałem Twoja wczesniejszą wypowiedzią. Oddzieliłem pobranie tablic z danymi wejsciowymi (POST/GET) od ustawienia walidatorów dla tej tablicy.

Ja Ci nie karzę pozwalać użytkownikowi na wywołanie metody dziecka bez kontroli rodzica. Zwróć uwagę na to ze metody protected nie wywołasz z zewnątrz a rozwiązanie jest szybsze jeżeli automatycznie na podstawie nazwy walidatora wywołujesz metodę, nie musisz pamiętać i "zjadać paznokci", bo zapomniałeś że trzeba to jeszcze dopisać do tablicy. Przykład: walidator notEmpty, metoda protected _valid__notEmpty() {};



To spójrz teraz na to tak:
Jestem rodzicem i mogę mieć dzieci, nie wiem jednak co to będą za dzieci, a raczej co te dzieci będą miały, do momentu ich powstania. Do własnych operacji używam tego co posiadają dzieci, więc powinienem wymusić na dzieciach aby posiadały to czego ja potrzebuję.

Prościej: jeżeli deklarujesz tablicę z nazwami walidatorów w klasie rodzica, to nie możesz wymagać ich obecności u dzieci, może dojść do sytuacji gdzie masz grupę walidatorów w kilku klasach, dziedziczących po klasie Engine, machnąłeś się gdzieś i chcesz walidatora z innej klasy, której nie używasz, a definicja walidatora jest w Engine, więc będzie go szukać w określonej metodzie. Wywali błąd bo nie znajdzie walidatora, i prawidłowo.

Jeżeli chcesz wymusić aby "dzieci" posiadały określone metody to robi się to inaczej.
W obecnym rozwiązaniu nie masz pewności czy metoda istnieje w klasie dziedziczącej, najlepszym wyjściem byłoby deklarowanie tej tablicy w klasie dziedziczącej, albo stworzenie metody która zwracałaby wszystkie dostępne walidatory z tej klasy.

Mogłem gdzieś pomieszać, przepraszam.


@edit.

Jeszcze jedno:


Jest taka zasada, jedna klasa, jedna funkcjonalność. Jeżeli masz wzorzec MVC, to widać to idealnie. Osobno jest kontrola odbieranych danych, osobno ich obróbka, osobno ich wyświetlenie. Tak samo powinieneś stosować się do tej zasady i jeżeli masz klasę do walidacji, to powinna ona tylko sprawdzać poprawność danych czyli zwracać true jak jest OK lub false jak nie jest OK, i ewentualnie błędy. Jeżeli masz klasę filtrowania danych to tak samo, albo zwracasz dane w odpowiednim formacie, albo zwracasz false/błąd/cokolwiek żeby wiedzieć że danych nie da się przetworzyć do odpowiedniego formatu.

ok bede poprawiać. Chciałbym aby ta klasa była napisana raz a porządnie, abym mógł z niej korzystać w każdym moim projekcie.

dla mnie najistotniejszym elementem jest samo wywołanie validacji. chciałbym aby było to jak najprostrze i intuicyjne do wykonania.

co w takim razie proponujesz ?

chodzi mi o samo to jak mam najlepiej jest wywołać walidajcje, np:

$val-> addValue(['imie' => $_POST['imie']]) -> addRules('req,min=3,max=20,login');

albo

$val-> addValue(['imie' => $_POST['imie']]) -> _required() -> max(6);

albo

$val-> addValue([
'imie' => $_POST['imie'],
'login' => $_POST['login']
])
-> _required() -> max(6);

$val-> addKey(phone') addValue($_POST['imie']) -> _isInt();

albo

$val-> addKey('imie') addValue($_POST['imie']) -> _required() -> max(6);

itd itp

Kombinacji moze być wiele, dostosować klase tez nie jest trudno, chodzi mi tylko o to jaki z tych wywołań będzie najbardziej praktyczny i wygodny. Ogólnie od samego początku widzi mi się aby każda wartość do sprawdzenia była zapisana tylko w jednej linijce - nawet jesli kazda wartosc do sprawdzenia w nowej linijce bedzie musia miec np powielony walidator required. Nie chce robić bardaku w kodzie a takie rozwiązanie uważam, że jest bardzo wygodne. Od razu widać co się dzieje.


EDIT:

przemyślałem to i uważam, ze:

$val -> new Validation();
$val -> addKey('imie') -> addValue($_POST['imie']) -> required() -> max(5) -> min(10);
$val -> addKey('login') -> addValue($_POST['login']) -> required() -> max(5) -> min(10);
itd
if(empty($val->errors)) {echo 'ok';}

bedzie najlepszym rozwiązaniem


EDIT:2

przerobiłem. Szybko mi to poszlo : )

https://gist.github.com/gitbejbe/6762020

oczywiście pięknie działa