Kontrola danych wejsciowych Opcje

[kicaj]

Jak optymalnie i bardziej uniwersalnie sprawdzac dane w kontrolerach (data input)?
Pisanie kontrolerow na zasadzie:

[PHP] pobierz, plaintext 
<?php
class NameController extends Controllers
{
	function indexAction( $aParams )
	{
		 if( isset( $aParams['id'] ) 
		 {
			  if( is_numeric( $aParams['id'] ) // ...
		 }
		 else
		 {
			   echo 'nie podano id!';
 
//...i tak w kazdej metodzie, sprawdzane rozne warunki z danych wejsciowych
?>
[PHP] pobierz, plaintext 

Sprawdzanie tego w kazdym kontrolerze i w jego kazdej metodzie mija sie z celem, jak to rozwiazac inaczej?

[Sedziwoj]

Przez kontrole typów argumentów <lol> sorry nie ma tego w PHP dla typów podstawowych, bo mija się to z ideologią twórców ;]
Ja zawsze robiłem

[PHP] pobierz, plaintext 
<?php
if( !is_numeric( $intPar ){
   throw new ParamException( 'Paramet musi być liczbą!' );
}
?>
[PHP] pobierz, plaintext 

czy raczej is_int(), taka kontrola czy wszystko jest ok. Na wydajność nie patrzyłem, wolę aby działało poprawnie, a wydajność można zyskać optymalizując coś co ma większy kosz czasowy.

[kicaj]

Wiem, sa rozne rodzaje funkcji.
Problem polega na tym ze jest to powtarzanie kodu co jest nie zgodne z programowaniem OOP i zasada DRY

Czesto tych instrukcji if jest duzo, co lubie, bo dokladnie user dostaje komunikat czego brakuje/co zle zrobil itp.

[splatch]

Kontrola danych wejściowych w miarę możliwości powinna być poza ciałem akcji. Jakkolwiek nie zależy zapominać że to konkretna akcja determinuje nam warunki walidacji.
Warunki typu czy to liczba, czy to jest wymagane i tak dalej można wyodrębnić do klas, które załatwią nam walidację. Jak zwykle w takim przypadku zaczynamy od interfejsu:

[PHP] pobierz, plaintext 
<?php
interface Validation {
	/**
	  * @param $ctx Kontekst z informacjami na temat walidacji
	  **/
	public function validate(ValidationContext $ctx);
}
?>
[PHP] pobierz, plaintext 

Dobrze, teraz jak może wyglądać definicja kontekstu walidacji:

[PHP] pobierz, plaintext 
<?php
interface ValidationContext {
 
	// tu mamy ważny błąd
	public function addError($key, ValidationMessage $msg);
 
	// a tu powiedzmy, ostrzeżenie
	public function addNotice($key, ValidationMessage $msg);
 
	public function addValidator(Validator $v);
 
	// czy wszystko "ok"
	public function isPassed();
 
	// mapa wiadomości gdzie kluczem jest nazwa pola a wartością kolekcja wiadomości
	public function getMessages();
 
		// tutaj dane z requestu
	public function getArgument($key);
}
?>
[PHP] pobierz, plaintext 

Dobra, dorzućmy do tego jeszcze wiadomość:

[PHP] pobierz, plaintext 
<?php
interface ValidationMessage {
 
	// tutaj wiadomość, oczekujemy tylko tego - jak ona jest ustawiana
	// to już kwestia wtórna
	public function getMessage();
}
?>
[PHP] pobierz, plaintext 

Może wydawać się dziwne to, że robię interfejs do takiego banału, aczkolwiek mam jeden cel:

[PHP] pobierz, plaintext 
<?php
abstract class AbstracMessage {
 
	// nie można się dobrać do wiadomości nawet z potomków
	private $message;
 
	public function __construct($message, array $args = array()) {
		$this->message = $this->transform($this->getMessageString($message), $args);
	}
 
	protected abstract function getMessageString($message);
 
	private function transform($string, array $args) {
		 // tu może być coś innego
		 return strtr($string, array_keys($args), array_values($args));
	}
 
	// to nam wymusza odwołanie do konstruktora
	public final function getMessage() {
		return $this->message;
	}
}
 
// ta wiadomość po prostu zwraca tekst, który był
class RawMessage extends AbstractMessage {
	protected function getMessageString($message) {
		return $message;
	}
}
 
// a ta wiadomość tłumaczy ładnie komunikaty
class I18nMessage extends AbstractMessage {
 
	private $resource;
 
	public function __construct(I18nValidationContext $ctx, $message, array $args = array()) {
		$this->resource = $ctx->getI18Resource();
		parent::__construct($message, $args);
	}
 
	protected function getMessageString($message) {
		return $this->resource->getString($message);
	}
}
 
// to powtórka z rozrywki - mamy interfejs i dorabiamy implementacje
interface MessageResource {
	public function getString($key);
	public function getStringArray($key);
}
 
// implementacja do zrobienia
interface I18nValidationContext extends ValidationContext {
	public function getResource();
}
 
?>
[PHP] pobierz, plaintext 

Dobra, wiadomości wiadomościami, ale przecież nie jest to najistotniejsze, najbardziej przecież nas interesuje powiązanie tego wszystkiego - czyli jak akcja "się waliduje". Zasadniczo znowu byłbym za interfejsem:

[PHP] pobierz, plaintext 
<?php
interface Action {
	public function execute();
}
 
interface SecureAction {
	public function getCredentials();
}
 
interface ValidationRequiredAction {
	public function validate(ValidationContext $ctx);
}
?>
[PHP] pobierz, plaintext 

Mając takie definicje front controller, który ma podniesiony ValidationContext może rozróżnić co zrobić - czyli najpierw sprawdza czy akcja wymaga autoryzacji - jeśli tak sprawdza uprawnienia, następnie weryfikuje czy dane, które przychodzą są ok.

Teraz rzecz zasadnicza - czyli co z konfiguracją. Jak widać same walidatory to pestka - ale jak zrobić to ładnie. No więc - może przykładowa implementacja:

[PHP] pobierz, plaintext 
<?php
 
class DefaultValidationContext implements ValidationContext {
 
	private $errors = 0;
 
	// tu mamy ważny błąd
	public function addError($key, ValidationMessage $msg) {
		$this->addMessage(new StackEntry('error', $key, $msg));
		++$this->errors;
	}
 
	// a tu powiedzmy, ostrzeżenie
	public function addNotice($key, ValidationMessage $msg) {
		$this->addMessage(new StackEntry('notice', $key, $msg));
	}
 
	protected final function addMessage(StackEntry $msg) {
		if (!isset($this->message[$msg->getKey()])) {
			$this->message[$msg->getKey()] = array();
		}
		$reference = &$this->message[$msg->getKey()];
		// teraz w widoku/akcji mamy do dyspozycji info o "powadze" błędu
		// oraz powiązaną z nim wiadomość
		$reference[sizeof($reference)]['severity'] = $msg->getSeverity();
		$reference[sizeof($reference)]['msg'] = $msg->getValidationMessage();
	}
 
	// czy wszystko "ok"
	public function isPassed() {
		$i = 0;
		$validatorsCount = sizeof($this->validators);
		do {
			// jeśli coś się tu stanie to zwiększy nam się rozmiar tablicy $errors
			$this->validators[$i]->validate($this);
		} while ($this->errors == 0 && ++$i < $validatorsCount);
 
		// przeszliśmy wszystkie walidatory i nie ma błędów
		return ++$i == $validatorsCount && $this->erros == 0;
	}
 
	// mapa wiadomości gdzie kluczem jest nazwa pola a wartością kolekcja wiadomości
	public function getMessages() {
		return $this->message;
	}
 
	public function addValidator(Validator $v) {
		$this->validators[] = $v;
	}
 
}
 
 
?>
[PHP] pobierz, plaintext 

No i na końcu akcja

[PHP] pobierz, plaintext 
<?php
class MyAction implements SecureAction, ValidationRequiredAction {
 
	// dorzucamy co trzeba do kontekstu - resztę załatwia za nas FrontController
	public function validate(ValidationContext $ctx) {
		$ctx->addValidator(new NotEmptyValidator('user_id'));
		$ctx->addValidator(new NumberFormatValidator('user_id'));
	}
 
}
?>
[PHP] pobierz, plaintext 

Aa i jeszcze walidatory:

[PHP] pobierz, plaintext 
<?php
class NotEmptyValidator implements Validator {
 
	private $field;
 
	public function __construct($field) {
		$this->field = $field;
	}
 
	public function validate(ValidationContext $ctx) {
		if (empty($ctx->getArgument($field)) {
			$ctx->addError(new RawMessage('Wartość {0} jest pusta', array($field)));
		}
	}
}
?>
[PHP] pobierz, plaintext 

Kilka uwag odnośnie kodu, który jest wyżej .. przede wszystkim walidatory dodają wiadomości - równie dobrze mogą bronić się wyjątkami, aczkolwiek mamy wówczas problem ze sformułowaniem komunikatu dla użytkownika. Można zatem rozważyć dwie opcje - wydelegować formatowanie wiadomości z AbstractMessage do ValidationContext - wówczas zmieniły by się nam sygnatury metod addError, addNotice. Druga opcja to przesunąć formatowanie wiadomości do akcji.
Dlaczego dodałem coś takiego jak notice w walidacji? Są to informacje, które nie wywalają całego procesu, a które można wyświetlić przy ponownym wyświetlaniu błędu - powiedzmy ktoś nie podał wartości w wymaganym polu a w innym gdzie był powinien trafić float dostaliśmy int - dodajemy notice o konwersji.

Aaa i jeszcze walka z tworzeniem walidatorów:

[PHP] pobierz, plaintext 
<?php
class XmlValidationForm implements Action {
 
	public final function validate(ValidationContext $ctx) {
		$path = $this->getContextPath();
		$binder new XmlValidatorBinder($path, $ctx);
	}
 
	public function getContextPath() {
		return get_class($this) .'-validation.xml';
	}
 
}
 
class MyAction extends XmlValidationForm implements SecureAction, ValidationRequiredAction {
 
	// tu już nic nie musimy dodawać - na podstawie nazwy klasy zostanie wczytana
	// konfiguracja walidatorów
 
}
?>
[PHP] pobierz, plaintext 

No i kolejna ciekawa wariacja nad którą można pomyśleć:

[PHP] pobierz, plaintext 
<?php
$orValidator = new OrValidationCondition($validator1, $validator2);
$ctx->addValidator($orValidator);
?>
[PHP] pobierz, plaintext 

Kod który przedstawiłem nie jest ani kompletny ani nadzwyczajnie spójny. Może stanowić podstawę do rozpoczęcia prac, aczkolwiek pozostaje jeszcze kilka problemów, które wymagają niezłej gimnastyki.

[Sedziwoj]

No tak jak zwykle czegoś nie doczytałem ;]
Bo ja nie o tej kontroli pisałem, tylko już "wewnętrznej"...

@splatch Znów spore ilości kodu umieszczasz

[splatch]

@splatch Znów spore ilości kodu umieszczasz

@Sedziwoj odpowiedzi na forum to obecnie mój jedyny sposób na utrzymanie kontaktu z PHP, stąd tak duże ilości kodu.

Myślę też, że takie przykłady z wykorzystaniem interfejsów, abstrakcji i tak dalej są jak najbardziej na miejscu i pomagają odwiedzającym bardziej niż mega rozwlekłe opisy i dywagacje. Po prostu można zobaczyć "Object Oriented Programing in Action".

[Sedziwoj]

Wież tylko że dywagacje i rozwlekłe opisy się rozumie czytając, ty jednak przy kodzie trzeba chwilę pomyśleć zanim się zrozumie założenia twórcy. Choć ciągle mi się przypomina "witaj świecie" w wzorcach projektowych, czyli aby gdzieś przypadkiem forma nie przerosła treść. Tak jak dziś od dłuższego czasu napisałem coś w pełni proceduralne, ale nie widzę sensu aby dla 3 linijek jednokrotnego wykorzystania (coś do obliczeń dla koleżanki) pisać więcej.
Ale zawsze patrzenie co inni tworzą jest przydatne, tego nie krytykuję

Tak z grubsza przed snem przejrzałem, na pewno są nieścisłości w tym kodzie, ale ogólną koncepcję chyba załapałem. Po prostu rozdzielenie funkcjonalności i umożliwienie stosowania różnych wariantów.
A jeszcze co do łączenia walidatorów warunkami, to ja chyba był bym za zdefiniowaniem, które połączyć i jako trzeci argument jaki warunek pomiędzy nimi. Do tego wartości 'notice' (w StackEntry()) zastąpił bym stałą, podobnie ten trzeci argument, warunek złączenia, walidatorów też jako stałą w obiekcie (czy interfejsie, już tego nie będę rozstrzygał :])

No dobra mykam spać.

Edit takie tam przecinki, kropi i tak pewnie kiepskie jest to co napisałem

Ten post edytował Sedziwoj 5.12.2007, 00:51:17

[splatch]

Tak, zasadniczo skłaniając się w stronę opisu.

Validator element zajmujący się walidacją, dostaje kontekst i z niego musi wyciągnąć to, czego potrzebuje i przeprowadzić walidację. Kwestia konfiguracji walidatora - albo przez akcesory albo przez konstruktory.

ValidationContext zawiera informacje na temat całego procesu. Ma również zgromadzone dane wejściowe i udostępnia je walidatorom.

FrontController element, który nie jest tu widoczny, a który zasadniczo odpowiada za odpalenie akcji i zweryfikowanie czy wszystko "ok", innymi słowy robi $action->validate($this->validationContext), $this->validationContext->isPassed() - gdy dostajemy false podejmuje odpowiednie działania - jakie to zależy już od implementacji.

ValidationRequiredAction typ, który sugeruje FrontControllerowi, że dana akcja chciałaby otrzymywać dane, które były zweryfikowane. Jest to tylko interfejs, pod spodem możemy w różny sposób dodawać do kontekstu swoje walidatory. Mogą być one odczytane z XML, mogą być wpisane z palca. Co kto woli.

I18nValidationContext kontekst dostarczający "tłumaczenia".

I18nMessage wiadomość, która zostanie przetłumaczona, przekazujemy do konstruktora klucz, na podstawie którego z kontekstu zostanie pobrana odpowiednia wiadomość.

OrValidationCondition walidator prezentujący prosty warunek logiczny, to lub to. Jesteśmy wolni od problemów związanych z tym, że przychodzi nam raz to raz to.

[Cysiaczek]

@splatch - w jaki sposób ładujesz (fizycznie) taką ilość interfejsów? Przeanalizowałem Twoje ostatnie posty i tak sobie pomyślałem, że starałem się unikać interfejsów na rzecz abstrakcji również z tego powodu, że autoloader w końcu by wymiękł ;p

Pozdrawiam.

[Sedziwoj]

@Cysiaczek
Nie przesadzaj dla autoloader'a to nie jest kłopot, gorzej tylko z nazewnictwem ;]

[splatch]

@splatch - w jaki sposób ładujesz (fizycznie) taką ilość interfejsów? Przeanalizowałem Twoje ostatnie posty i tak sobie pomyślałem, że starałem się unikać interfejsów na rzecz abstrakcji również z tego powodu, że autoloader w końcu by wymiękł ;p

Kod piszę na poczekaniu, na potrzeby poszczególnych postów. Wydaje mi się, że interfejsy w tym przypadku nie są problematyczne, są małe i lekkie, część z nich zawiera tylko po parę metod.
Co do optymalizacji autoloadera - w Mojavi 3 metoda była prosta - stworzenie pliku z definicjami wszystkich wymaganych interfejsów etc. Wczytywany był 1 plik a nie kilka.

[kicaj]

Dobra dobra, bo troche odbiegacie od tematu...

To co splatch wklepal jest troche za bardzo przesadzaone, pytanie brzmialo jak z zasada DRY robic kontrole danych wejsciowych, tzn. jak nie powtarzac sie sprawdzajac dane z parametrow metody, takich jak id, liczba, string, itp

[splatch]

To co splatch wklepal jest troche za bardzo przesadzaone, pytanie brzmialo jak z zasada DRY robic kontrole danych wejsciowych, tzn. jak nie powtarzac sie sprawdzajac dane z parametrow metody, takich jak id, liczba, string, itp

Jeśli przykład kodu, który jest wyżej koliduje z DRY to proszę pokaż mi gdzie. Być może źle rozumiem to pojęcie i gdzieś popełniłem błąd. Ewentualnie powiedz co w moim przykładzie odbiega od Twoich oczekiwań.

[kicaj]

No stworzylem sobie cos na ten wzor, ale duzo duzo mniej kodu, tzn. z czasem bedzie to sie rozrastalo

Beda problemy, beda pytania