[Phalcon] Gdzie przeprowadzać walidację?, Klasy formularzy - użyteczne czy zbędne? Opcje

[WebCM]

Zobaczmy przykładowy kontroler:

[PHP] pobierz, plaintext 
class UsersController extends Phalcon\Mvc\Controller
{
	public function addAction()
	{
		$user = new User;
		$form = new UserForm($user);
 
		if($this->request->isPost())
		{
			//Metoda także dokonuje $user->assign($_POST)
			$form->bind($_POST, $user);
 
			//Walidacja nr 1 - formularz
			if($form->isValid())
			{
				//Walidacja nr 2 - model
				if($user->save())
				{
					$this->view->disable();
					$this->response->redirect('users');
				}
				else
				{
					//Walidacja nr 2 - odczyt błędów
					foreach($user->getMessages() as $msg)
					{
						$this->flash->error($msg);
					}
				}
			}
			else
			{
				//Walidacja nr 1 - błędy formularza
				foreach($form->getMessages() as $msg)
				{
					$this->flash->error($msg);
				}
			}
		}
		$this->view->form = $form;
		$this->view->user = $user;
	}
}
[PHP] pobierz, plaintext 

Przykładowa klasa formularza - nieobowiązkowa

[PHP] pobierz, plaintext 
<?php
 
use Phalcon\Forms\Form;
use Phalcon\Forms\Element\Text;
use Phalcon\Forms\Element\Password;
use Phalcon\Forms\Element\Select;
use Phalcon\Validation\Validator\Confirmation;
use Phalcon\Validation\Validator\StringLength;
 
class UserForm extends Form
{
	public function initialize()
	{
		//Niedogodność w Phalconie
		//Chociaż dodamy mu 100 walidatorów
		//Sam nie doda atrybutów, tylko trzeba wszystko ręcznie
		$login = new Text('login', array(
			'maxlength' => 25,
			'required' => 'required', //nie da się dodać pustych atrybutów
			'pattern' => '.....',
			'placeholder' => 'Wpisz login'
			'autofocus' => 'autofocus' //już lepiej pisać czysty HTML w widoku
		));
		$login->addValidator(new StringLength(array(
			'min' => 200,
			'max' => 25,
			'messageMinimum' => 'Login musi miec min 2 znaki!',
			'messageMaximum' => 'Login jest za dlugi - max 25!'
		)));
 
		//Tutaj też ciekawy fragment
		$pass = new Password('pass');
		$pass->addValidators(array(
			new StringLength(array(
				'min' => 5,
				'messageMinimum' => 'Password too short'
			)),
			new Confirmation(array(
				'with' => 'confirm',
				'message' => 'Password confirmation not the same.'
			))
		));
 
		//Wielką zaletą jest tworzenie pól select
		//Nie musimy męczyć się z ifami w widoku
		//Podajemy mu, skąd pobrać dane lub przekazujemy tablicę
		//Jednak nie musimy tego robić w klasie - można też w widoku
		$select = new Select('sasiad', User::find(), array(
			'using' => ['ID', 'name']
			'useEmpty' => true,
			'emptyText' => 'Nie ma sąsiada'
		));
 
		//Add fields to the form
		$this->add($login);
		$this->add($pass);
		$this->add($select);
	}
}
[PHP] pobierz, plaintext 

Za dużo kodu w kontrolerze? Za bardzo skomplikowany? Tak. Musimy osobno sprawdzać poprawność danych w formularzu i modelu. Prowadzi to do sytuacji, że wiele pól sprawdzamy 2 razy - najpierw w formularzu, a potem w modelu. Nie możemy pominąć walidacji w modelu - przecież błędne dane mogą doprowadzić do destabilizacji systemu! Zazwyczaj jeśli pole ma mieć określony format, musi taki mieć niezależnie, czy dane wejściowe pochodzą z formularza, czy z innego źródła.

Gdzie przeprowadzać walidację? Czy wszystko sprawdzać w modelu?

Tak byłoby najwygodniej i bez powtórzeń.

Mamy formularz rejestracji. Trzeba powtórzyć hasło. Gdzie sprawdzimy, czy oba hasła zgadzają się? Jeśli przekażemy całą tablicę $_POST do modelu, możemy tam odczytać pole "confirm". Niektórzy powiedzą, że tak nie wolno, bo wychodzimy poza kompetencje modelu, a ten przypadek powinien sprawdzić kontroler. Co o tym myślicie?

Gdzie przeprowadzać kontrolę poprawności danych?

Kolejne zagadnienie to... formularze.

Czysta klasa Form w Phalconie jest bez sensu. Żadnych korzyści. Więcej problemów. Pola możemy sprawdzić w akcji kontrolera, cały kod HTML napisać ręcznie (metoda render() jedynie wypluje kod pojedynczej kontrolki), funkcję pomocniczą {{select()}} wywołać w widoku, kilka plików mniej. Jedyna zaleta to możliwość większej automatyki po rozszerzeniu klasy Form inną klasą bazową lub stworzenie uniwersalnego szablonu formularza (niektóre i tak będą wymagać osobnego kształtu):

[HTML] pobierz, plaintext 
{{content()}}
 
<form method="post">
	<h1>{{title|e}}</h1>
	<table>
		{% for field in form %}
		<tr>
			<td>{{field.getLabel()}}</td>
			<td>{{field.render()}}</td>
			{% if field.hasMessages() %}
			<td>
				{% for msg in field.getMessages() %}
				<div class="msg">{{msg}}</div>
				{% endfor %}
			</td>
			{% endif %}
		</tr>
		{% endfor %}
		<tr>
			<td colspan="2">
				<input type="submit" value="Zapisz">
			</td>
	</table>
</form>
[HTML] pobierz, plaintext 

LOL Kod PHP wyglądałby lepiej. Tu można przenieść komunikaty o błędach. Czy opłaca się używać klas formularzy w Phalconie? Są one rzeczywiście przydatne, czy tylko niepotrzebnie komplikują kod?

[Crozin]

Formularz bardzo często nie operuje bezpośrednio na modelu aplikacji, a na swoim własnym, stąd wymaga on innego zestawu reguł walidacji. Przykład z podwójnym hasłem jest całkiem dobrym przykładem. Z punktu widzenia logiki aplikacji nie istnieje coś takiego jak "powtórzone hasło użytkownika" - istnieje jedynie hasło. W dodatku taki formularz zainteresowany jest jedynie małym fragmentem danych dot. użytkownika.
Jeżeli całą walidację przeniósłbyś do warstwy modelu, skończyłbyś z czymś tak bezsensownym w przykładowym mechanizmie tworzenia nowego konta z losowym hasłem:

[PHP] pobierz, plaintext 
$password = getSomeRandomPassword();
 
$userData = array(
    'username' => 'Crozin',
    'password' => $password,
    'repeatedPassword' => $password
);
[PHP] pobierz, plaintext 

Trochę bez sensu, prawda?

Takie coś jak komunikaty błędów, faktycznie powinno zostać zrealizowane przez widok/szablon. Generując każdy z elementów formularza mogący posiadać jakieś błędy (formularz sam w sobie, grupy pól czy w końcu pojedyncze pola) powinieneś generować jego:
- nazwę,
- listę błędów, jeżeli jakieś wystąpiły,
- kontrolę formularza.
Taki schemat generowania zapewnia pewnie klasa ...\Form z frameworka.

Wtedy Twój kontroler będzie wyglądać tak:

[PHP] pobierz, plaintext 
[...]
 
if ($request->isPost()) {
    $form->bind($_POST, $user);
 
    if ($form->isValid() && $user->save()) {
        // przekierowanie
    }
}
 
[...]
[PHP] pobierz, plaintext 

Teraz jest już znacznie prościej i wygodniej.

[WebCM]

Czyli ostateczny kształt akcji jak poniżej?

[PHP] pobierz, plaintext 
class UsersController extends Phalcon\Mvc\Controller
{
	public function addAction()
	{
		$user = new User;
		$form = new UserForm($user);
 
		if($this->request->isPost())
		{
			$form->bind($_POST, $user);
			if($form->isValid())
			{
				if($user->save())
				{
					$this->view->disable();
					$this->response->redirect('users');
				}
				else
				{
					//Odczyt błędów modelu
					foreach($user->getMessages() as $msg)
					{
						$this->flash->error($msg);
					}
				}
			}
		}
		$this->view->form = $form;
		$this->view->user = $user;
	}
}
[PHP] pobierz, plaintext 

Odczyt błędów formularza przenosimy do widoku jak w pierwszym poście. Może odczyt błędów modelu też da się przenieść do widoku, bo można odczytać błędy dla konkretnego pola. Na razie zostawmy tak jak powyżej. Niestety, nie działa to prawidłowo - field.hasMessages() zwraca fałsz, a field.getMessages() pustą tablicę. Błąd w Phalconie lub coś mam nie tak. Pozostaje kwestia klucza CSRF. Też sprawdzamy go w kontrolerze?

Ten post edytował WebCM 26.12.2013, 21:36:39

[Crozin]

1. Nigdy nie korzystałem z Phalcona, nie znam go więc ciężko mi się tutaj wypowiadać.
2. Sprawdzanie tokena CSRF powinno zostać obsłużone przez samą bibliotekę zajmującą się formularzami. Jednak z tego co widzę w dokumentacji chyba trzeba to robić ręcznie.
3. Jeżeli dane przeszły pomyślnie walidację formularza model nie powinien już wyrzucić żadnych błędów-komunikatów dla użytkownika - dane powinny być w pełni poprawne. Tutaj powinien już raczej lecieć wyjątek wywalający całą aplikację.

[WebCM]

Ad 2. Formularze w Phalconie to poczwarka. Może kiedyś wyrośnie motyl. Tak, aktualnie trzeba generować klucz CSRF ręcznie. Można napisać nakładkę i dodawać pole w initialize().
Ad 3. Można ustawić tryb, aby model wyrzucał wyjątek. Czy to rzeczywiście lepsze wyjście?

Ten post edytował WebCM 26.12.2013, 22:44:46

[ShadowD]

Korzystałem w kilku apkah z phalcona, z punktu widzenia mojego klasy formularzy są odpowiedzialne za filtrowanie danych, a nie modele. Przykład jest banalny, admin ma często większe możliwości edycji jakiś danych niż user, a fizycznie korzystają z jednego modelu.

Jeśli chodzi o stwierdzenie, że formy to poczwarka to się zgodzę, moja tymaczasowa mam nadzieje rezygnacja z phalcona jest podyktowana wieloma niedoróbkami jakie ten FW aktualnie posiada, a z klasą formów szybciej jest podciąć sobie żyły z złości niż zbódować jakiś większy form. Aczkolwiek Framework jest na prawdę domry i miejmy nadzieje, że wersja 2 będzie już czymś bardziej dopracowanym. ;-)

[WebCM]

Programiści Phalcona wymyślili normalizację wartości pól formularzy do UTF-32. Niestety w PHP funkcja mb_convert_encoding psuje kodowanie.

[PHP] pobierz, plaintext 
// ą ć ę ł ń ś ź ż ? ?
Phalcon\Tag::textField(['test','value'=>'ą ć ę ł ń ś ź ż Ó ó']);
[PHP] pobierz, plaintext 

Zepsute są litery Ó i ó, ale po wielokrotnym wysyłaniu formularza psują się wszystkie polskie znaki. Czy znacie rozwiązanie tego problemu? Można całkowicie wyłączyć funkcję autoescape, ale wtedy kod staje się podatny na XSS.

Kod źródłowy: https://github.com/phalcon/cphalcon/blob/ma.../escaper.c#L261

Jeśli nie da się z tym nic zrobić, usunę wspólny szablon do generowania formularzy i powrócę do osobnych widoków dla każdego formularza, gdzie wstawię <input> ręcznie. Jaki ma sens wspólny szablon z tysiącami IF-ów, aby obejść problem?

PS. Forum zamienia encje na znaki, ale w rzeczywistości polskie znaki są zakodowane, np. & # x105;

Ten post edytował WebCM 6.01.2014, 16:35:56