Zalążek frameworka z MVC, Proszę, zweryfikujcie moje podejście Opcje

[aleksander]

@eMartio: http://php.pl/wortal/artykuly/php/architek...wadzenie_do_mvc

[eMartio]

@eMartio: http://php.pl/wortal/artykuly/php/architek...wadzenie_do_mvc

Znam to. Czytalem. Szkoda, ze artykul z 2004... Tema stary, ale cos nowego mozna byloby zredagowac...

[Prph]

Przeczytajcie na końcu!. Jak rozwiąć Widok?

Witam,

ja rozwizalem to tak:

w index.php laduje FrontController. Pierwsza czynnoscia jaka on wykona bedzie wydobycie informacji, jaka akcje powinien odpalic. Tym zajmie sie obiekt klasy URL. za pomoca metod getActionName() i getParameters() zwraca odpowiednie dane.

Majac juz nazwe akcji, Front kontroler wczytuje konfiguracje dla akji. Uruchamiany jest takze mechanizm autoryzacji, jezeli w konfiguracji bylo podane ze akcja jej wymaga.

Po przejsciu testow, zwyczajnie ladowana jest klasa, tworzony obiekt i wykonywana na nim metoda run();

Co robi run()?
1. Wybiera dla siebie model.
2. Wybiera dla siebie widok.
3. Wykonuje jakies dzialania
4. zwraca albo true, kiedy akcja sie powiedzie, albo tablice parametrow dla kolejnej akcji, albo false jak cos sie popsuje.

Znowu wszystko wraca do kontrolera. Ten czyta konfig czy ma wykonac nastepna akcje i czy ma jej przekazac parametry. Dane zwrotne z poprzedniej akcji ma, wiec reszta juz jest banalna.

Framment kontrolera glownego:

[PHP] pobierz, plaintext 
<?php
	try
	{
	  do
	  {
		$this->_loadConfig($sActionName);
 
		if(Registry::doesEntryExist($sActionName, 'useAuth'))
		  if(Registry::getEntry($sActionName, 'useAuth'))
			$this->_checkAuth($sActionName);
 
		$oAction = $this->_prepareAction($sActionName, $aParametersForAction);
 
		$mResult = $oAction->run();
 
		if(Registry::doesEntryExist($sActionName, 'nextAction'))
		{
		  $sActionName = Registry::getEntry($sActionName, 'nextAction');
		  $bContinueChain = true;
 
		  if(Registry::doesEntryExist($sActionName, 'passParameters'))
			$aParametersForAction = $mResult;
		}
		else
		  $bContinueChain = false;
	  }
	  while($mResult && $bContinueChain);
	}
	catch(Exception $oException)
	{
	  throw $oException;
	}
 
?>
[PHP] pobierz, plaintext 

Metoda prywatna _prepareAction($name) po prostu sprawdza czy pliki akcji istnieja, dlaczaje, tworzy obiekt i go zwraca.

Przykladowa akcja:

[PHP] pobierz, plaintext 
<?php
 
class DefaultExampleAction extends Action
{
  public function run()
  {
	$this->_setModel('ExampleModel');
	$this->_setView('DefaultExampleHtmlView');
 
	$aParameters = $this->_getParameters();
 
	$aAnswer = $this->_getModel()->getExampleMethod();
 
	$aData = $aAnswer;
	$aData['PARAMETERS'] = $aParameters;
 
	$this->_getView()->display($aData);
	return true;
  }
}
 
?>
[PHP] pobierz, plaintext 

Klasa ta dziedziczy po Action. Wszystkie akcje we frameworku musza z niej dzidziczyc.. No chyba ze ktos woli swoje pisac

[PHP] pobierz, plaintext 
<?php
$this->getParameters();
?>
[PHP] pobierz, plaintext 

Jezeli podano url postaci strona.pl/JakasAkcja/Opcja1/Opcja1/ to klasa nadrzedna Action zwroci w tej chwili tablice array(Opcja1, Opcja2). Parametry przekazywane sa do konstruktora Action we Front kontrolerze.

[PHP] pobierz, plaintext 
<?php
 
	$this->_setModel('ExampleModel');
	$this->_setView('DefaultExampleHtmlView');
 
?>
[PHP] pobierz, plaintext 

Co robia te metody nadrzednej klasy Action? Tworza obiekty Modelu i widoku, dostepne pozniej za pomoca:

[PHP] pobierz, plaintext 
<?php
$this->_getModel();
$this->_getView();
 
?>
[PHP] pobierz, plaintext 

Klasa widoku

[PHP] pobierz, plaintext 
<?php
 
class DefaultExampleHtmlView extends HtmlView
{
  public function __construct()
  {
	$this->_setTemplate('DefaultExample');
	parent::__construct();
  }
}
?>
[PHP] pobierz, plaintext 

Klasa dziedziczy z HtmlView, ktora u mnie w zasadzie jest jakby aliasem do SmartyView.


Klasa SmartyView|

[PHP] pobierz, plaintext 
<?php
 
class SmartyView
{
  private $_oSmarty;
  protected $sTemplateName;
 
  public function __construct()
  {
	$this->_oSmarty = new Smarty();
	$this->_oSmarty->tempalte_dir = PATH_TEMPLATES;
	$this->_oSmarty->compile_dir = PATH_VAR;
  }
 
  public function display($aData)
  {
	$this->_oSmarty->assign($aData);
	$this->_oSmarty->display($this->sTemplateName);
  }
 
  protected function _setTemplate($sTemplateName)
  {
	$this->sTemplateName = $sTemplateName.'.tpl';
  }
}
 
?>
[PHP] pobierz, plaintext 

No to tak wyglada to z grubsza. Przepraszam, za brak komentarzy, ale zaraz musze isc na basen :/

Ktos powie, ze to nie tak, ze inaczej, po co tak... MVC mowi - masz miec model i widok, ktore nie sa w jednym miejscu. A kontroler ma pomoc im nawiazac miedzy nimi wspolprace.

Wydaje mi sie, ze moje rozwiazanie jest calkiem wygodne. Oczywiscie sporo brakuje tutaj do funkcjonalnosci. Obecnie mecze mechanizm autoryzacji, obslugi sesji itp.

Pozdrawiam, Adrian.

Jak rozwiązać widok?

Teraz, kiedy napisałem już większość bazowego kodu, stanął przede mną problem rozsądnego rozwiązania klasy widoku.

Chciałbym aby moj Framework był przystosowany do różnego rodzau widoków. Oczywiste jest, że najczęściej wykorzystam widok HTML, ale może się także pojawić widok samego pliku - tzn. akcja w wyniku swojego działania zwróci plik, chociażby obraz który zostanie wysłany wraz zodpowienim nagłówkiem do odbiorcy (prawdopodobnie przeglądarki).

W związku z tym zasada jest taka:

FrontController->Akcja->wykonaj czynnosci->uruchom widok.

Do przeglądarki nie tarfi nic, jeżeli akcja niczego takiego nie zwróci. Jest to normalne rozwiązanie, a do tego dosyć skuteczne, bo wiadome jest, że aby do przeglądarki wysłać naglówki to nic innego wcześniej nie może być wysłanego.

Problem pojawia się przy widoku HTML. Wiadomo przecież, że zwrócenie tabelek z newsami, czy fotek z galerii nie wystarczy - trzeba to ubrać w nagłówek, stopkę, tytuł strony itp.
Bez senu jest, aby szablon newsow zawierał to wszystko w sobie.

Rozwiązanie nasuwa się dosyć szybko - niech każdy widok HTML dziedziczy po jakimś widoku, który ubierze zwrócone dane z akcji w nagłowej, stopkę itp. I to by działało całkiem sprawie.

Jest jedno ale. Mój framework będzie dawał możliwość łańcuchów akcji. A działało to będzie tak:

Front Kontrole->Akcja->wykonaj
jeżeli w konfigu podano, ze ma wykonac nasteona akcje to ja wykonuje itd.

Jezeli tylko otatnia akcja jest widokiem HTML, a poprzednie to tylko działanie na modelu to jest ok:

Akcja ZapiszNewsa
zapisuje newsa w bazie. Nic sie nie wyswietla - nie korzysta z zadnego widoku.
Nastepna akcja to PokazNewsy

PokazNewsy
Wyswietla newsy z bazy danych

W rezultacie na ekranie pojawia sie wynik PokazNewsy - i tylko ten wynik.

Ale możliwe jest aby wykonac kilka akcji z widokiem. W takim przypadki nie ma mowy, aby obie akcje wyswietlały całą stronę...

Jak można to rozwiązac?

Pozdrawiam, Adrian.

Ten post edytował Prph 25.03.2006, 13:54:50