Witam

Mam trzy pytania odnośnie wzorca MVC, byłbym wdzięczny za wszelkie wskazówki.

1) Co powinno znaleźć się w modelu? Rozumiem że np. wszelkie funkcje dotyczące konretnych zadań nie związanych z wyświetlaniem danych. Czyli w takim razie klasa do zarządzania użytkownikami będzie modelem?

2) Filtracja i walidacja danych wejściowych, które mają mieć jakiś określony typ, powinna się odbywać w kontrolerze czy modelu? Nie mówię tutaj o zapisie do bazy/pliku, ta filtracja jest w osobnym DAO.

3) Wielojęzyczność strony mam rozumieć powinna być w zaimplementowana gdzieś w elemencie widoku?

1. Model to dane oraz czynności wykonywane na nich, czyli po ludzku - symulacja przedstawianego środowiska. Nigdy nie starałem się odwzorować modelu na klasy, bo jest to dla mnie pojęcie abstrakcyjne...

2. Najczęściej dane zostają filtrowane w filtrach przed łańcuchem akcji. Poszukaj czegoś o wzorcu Intercepting Filter, to wyjaśni Ci się sprawa

3. Tak powinno być, lecz niektóre elementy takie jak wersje językowe artykułów są pobierane przed wywołaniem widoku, więc pobranie odpowiedniej wersji artykułu, newsa czy czegokolwiek innego, nie przeszkadza w realizowaniu założeń wzorca. Aczkolwiek elementy interfejsu powinny być tłumaczone w widoku...

No tak. Takie filtrowanie sprawdzi się przy autoryzacji, wybieraniu lokalizaji użytkownika etc. Ale czy to odpowiednie miejsce żeby sprawdzać czy w polu formularza został wpisany poprawny adres email bądź pole nie zawiera tagów html?

Ja mam w akcji metodę validation(), która właśnie jest odpowiedzalna za walidację.

[PHP] pobierz, plaintext 
<?php
// ...
	   /**
	 * Walidacja danych.
	 * 
	 * @param iRequest $oRequest
	 * @return array
	 */
	public function validate(iRequest $oRequest)
	{
		$aErrors = array();
 
		$oV = new HValidation();
		if($oV->isEmpty($oRequest->name)) {
			$aErrors['name'] = 'emptyName';
		}
 
		return $aErrors;
	}
 
 
	/**
	 * Uruchomienie akcji.
	 * 
	 * @param iRequest $oRequest   Przychodzące żądanie.
	 * @param iResponse $oResponse  Przygotowywana odpowiedź.
	 */
	public function run(iRequest $oRequest, iResponse $oResponse)
	{
		// walidacja
		if($aErrors = $this->validate($oRequest)) {
			$oResponse->failed = $aErrors;
			return -1;
		}
// ...
?>
[PHP] pobierz, plaintext 

tutaj najlepiej sprawdza się AJAX...lub poprostu DHTML i JS

A co jeśli user ma wyłączone js ;]

Nie wiem za badzo jak filtrować lub validować dane z formularzy za pomocą interceptiong filter, nigdy nie spotkałem sie z takim czyms ;/

Można dodać filtry wywoływane tylko przed konkretną akcją czy też łańcuchem akcji. Najprościej jednak dodać akcję sprawdzającą te dane przed wywołaniem akcji dodającej je do bazy. W przypadku niepowodzenia zawsze można przekierować kontroler do innej akcji, która wyświetli formularz z zaznaczonymi błędami.

Mimo wszystko raczej zdecyduję się na utoworzenie konretnych obiektów formularzy oraz zawarcie w nich metod sprawdzających poprawność danych. Jeden formularz dla dodawania i edycji newsa, posta etc.

Tworzenie kolejnych akcji w kontrolerze wydaje mi się problematyczne w momencie gdy jest sporo formularzy i każda zmiana w obiekcie widoku (formularz) pociąga za sobą zmiany w kontrolerze (walidacja).

Sprawdzanie samym JSem jest może fajne i wygodne ale co jeżeli ktoś prześle dane $_POST używając swojego formularza a nie mojego? Pomijając fakt że PDO wyeliminuje SQL Injection, będę miał bałagan w danych

Niewiem czy opłaca sie tworzyć jeszcze osobne klasy do każdego formularza aby je sparadzić, bo i tak trzeba robić klase widoku, model, kontroler no i by jeszcze klasa form doszła.

Narazie robie wielkie uproszczenie z walidacją:

[PHP] pobierz, plaintext 
<?php
 
// jakis tam kontroler
 
public function addAction()
	{
		$view = $this->getView('ogloszenie');
		$view->add();
 
			if($this->request->requestMethod() == 'POST')
			{
				$t['title'] = $this->request->post('s_title', 1);
				$t['price'] = $this->request->post('s_price', 1);
				$t['time_to'] = $this->request->post('s_timeto', 1);
				$t['category'] = $this->request->post('s_category', 1);
				$t['content'] = $this->request->post('s_content', 1);
				$t['autor'] = $this->getUser()->id;
				$t['time_from'] = time();
				$error = false;
 
				foreach($t as $key => $value)
				{
					if(empty($value) || !isset($value))
						$error = true;
				}
 
				if($error === true)
				{
					$view->errors = 'Prosze wypelnic wszystkie pola';
					$view->t = $t;
				}
				else
				{
					$model = $this->getModel('ogloszenie');
 
					if($model->dodajOgloszenie($t))
						$view->errors = 'Ogloszenie zostalo dodane';
				}
			}
 
		$view->fetch();
	}
 
?>
[PHP] pobierz, plaintext 

Jak widać jest to nie estetyczne rozwiązanie. Lepiej stworzyć formularz dzięki xml i napisać jakąś 1 klase sprawdzającą i walidującą pola a na koncu wyświetlenie błędów.

Tak, stworzenie systemu obsługi formularzy z walidacją jest najlepszym pomysłem, ale gdzieś trzeba utworzyc instancje tych klas. Najwygodniejszym momentem jak dla mnie jest odpowiednia akcja. Tak czy inaczej trzeba gdzieś potworzyć te obiekty, a akcja będzie jedynym miejscem, w którym to nastąpi, a co za tym idzie, jedynym kawałkiem kodu, który trzeba będzie poprawić przy zmianie widoku. To nie są chyba duże zależności

Jeżeli masz jakieś schematy tworzenia formularzy (xml czy coś w tym stylu), to obiekty pewnie stworzysz dynamicznie w filtrach.

To ja zaprezentuje jak obsługa formularzy wygląda u mnie, na przykładzie dodawania nowego użytkownika

[PHP] pobierz, plaintext 
<?php
class fAddUser extends Forms {
		// Jeżeli pole nie jest type="input"
	protected $aFieldSubmit = array (
			'AddUser'
		);
	protected $aFieldPass = array (
			'UserPass'
		);
		// Definuje jakie warunki muszą byc spełnione by przepuscić formularz
	public function validate()
	{
		$this -> UserName() -> must();
		$this -> UserMail() -> mail();
	}
		// A tutaj sprawdzam i wysyłam błędy
	public function check()
	{
		if( $this -> UserName() -> errorMust() )
		{
			$this -> UserName() -> error( 'Musisz podać nazwe użytkownika' );
		}
		if( $this -> UserMail() -> errorMail() )
		{
			$this -> UserMail() -> error( 'Musisz podać prawidłowy mail' );
		}
	}
}
// Klasa akcji
class aAddUser extends Actions implements iViews, iAppends, iModel, iInput, iForms
{
	public function start()
	{
				// Tworze instancje
		new fAddUser;
				// Rozpoczyna inicjowanie fomularza
		$this -> to();
	}
 
		// Wywoływanie gdy nie stwierdzi błędu
	public function resultAddUser( Forms $oForm )
	{
		// Sprawdzenie czy użytkowników lub mail istnieje
		$oUsers = $this -> append( 'UsersAndGroups' );
		if( $oUsers -> userExists( $oForm -> post( 'UserName' ) ) )
		{
			$oForm -> UserName() -> error( 'Taki użytkownik już istnieje' );
			$bError = 1;
		}
		if( $oUsers -> mailExists( $oForm -> post( 'UserMail' ) ) )
		{
			$oForm -> UserName() -> error( 'Taki mail już istnieje w bazie' );
			$bError = 1;
		}
		if( $bError )
		{
			return;
		}
		// Wykonanie dodania użytkownika
		$oUsers -> addUser( $oForm -> post() );
		$oModules = $this -> append( 'Modules' );
		$iUser = Db::getInstance() -> lastInsertId();
		$oUsers -> addToGroupRegister( $iUser );
		if( $oModules -> isOn( 'Auth' ) )
		{
			$this -> assign( 'iUserAuth', $iUser );
		}
		$this -> assign( 'iUser', $iUser );
		Output::getInstance() -> redirectAfterForm();
	}
}
?>
[PHP] pobierz, plaintext 

A w widoku opieram się na funkcjach formularza: form, error, isError, field.

Ja tutaj wcisnę swoje pytanie z zupełnie innej beczki. Gdzie i kiedy najlepiej tworzy egzemplarz klasy request ? Czy do niej wsadzać parameters z path_info ?

Instancja requesta tworzona jest w kontrollerze. To ona odpowiada za dane wejściowe do systemu. Ona sprawdza dane czy są poprawne ($_GET). To poprzez nią pobierasz dane z tablicy POST.

Także nie ma co zapychać go parametrami z path_info, stwórz sobie do tego ParameterHolder.