[MVC] Czy dobrze interpretuję ?, ciągle to mvc :( Opcje

[matix]

Witam,

Ciągle zastanawiam się, czy dobrze interpretuję zasadę MVC.

Chciałem napisać coś takiego:

KONTROLLER: Index.Controller.php:

Pobiera $_GET['view'] i zwraca $this -> setView():

[PHP] pobierz, plaintext 
<?
class aController 
{
  private $sView;
 
		function __construct() 
	{
		$this -> sView = $_GET['view'];
				self::setView();
	}
 
 
	function setView()
	{
		require_once('view/'.$sView);
	}
}
?>
[PHP] pobierz, plaintext 

Następnie MODEL pobiera dane z mysql z danego projektu i zwraca:

[PHP] pobierz, plaintext 
<?
class db 
{
	function __get() {
		while (...) 
		{
			$oArray[] = $db -> id;
		}
 
		return $oArray;
	}
 
}
?>
[PHP] pobierz, plaintext 

W ostateczności Widok pobiera wszystko i generuje HTML:

[HTML] pobierz, plaintext 
Klient o ID: <?=$db['id'];?><br/>
Pobrał .... <?=$db['nazwa'];?>
 
To jest przykładowa tresc pliku widoku.
[HTML] pobierz, plaintext 

Męczy mnie także pytanie, jak to wszystko połączyć, zeby działało?
Chodzi o większą ilość widoków, lub modeli.

Proszę mnie nie odsyłać do artykułów, bo z nich nic się (niestety) nie można dowiedzieć.

Pozdrawiam, Matix: )

Ten post edytował matix 25.05.2007, 22:03:54

[ActivePlayer]

kontroler:
- sprawdza dane z geta, posta itd itd
- decyduje ktora akcje wykonac

model:
- pobiera//wstawia//edytuje dane w bazie
- obrabia dane, ogolnie operacje na informacjach

widok
- wyswietlanie

akcja
- uzywa modeli zeby cos wykonac

np akcja showNews uzywa modelu news (np $newsFinder->getNews($id)), i wywoluje odpowiedni widok a on wyswietla to co zostalo pobrane

[Jabol]

Widok wywołuje model aby pozyskać dane lub kontroler gdy wywołana zostanie akcja. Widok może też zostać zmieniony niezależnie od kontrolera ani modelu, np. przy zmianie kryteriów sortowania. Obsługuje "logikę wyświetlania".
Model zmienia widok, gdy sam zostanie zmieniony, nie wywołuje kontrolera. Przechowuje informacje. Obłsuguję "logikę danych".
Kontroler zmienia model oraz obsługuje akcje. Kontroler to logika aplikacji.

Akcja - to zapytanie do kontrolera, wywołanie kontrolera. Nie wydaje mi się też żeby kontroler decydował którą akcje wykonąć. To akcja decyduje który kontroler wywołać.

Co do przykładu powyżej. ShowNews to akcja, która wywołuje kontroler News. Kontroler ten nie modyfikuje modelu, wyświetla natomiast widok, który pobiera z modelu dane. Raczej tak rysowłabym te zależności. Dlatego przygotowywanie danych do wyświetlenia już na poziomie kontrolera to troszkę wg mnie za wcześnie. To powinien zrobić widok.

To taki prosty opis zależności. Widok może mieć odniesienia do akcji różnych kontrolerów. Tak samo kontroler po wywołani może zmienić widok - nie tylko zmienić aktualny widok, ale również zmienić samą instacje widoku.
Tak to łaczysz.

Pozdrawiam

Ten post edytował Jabol 25.05.2007, 23:07:04

[jastu]

Hm...ja korzystam z trochę innej interpretacji, możliwe że prostszej, może Ci się przyda ten opis ale uwag też chętnie posłucham.
Mam jeden plik index.php który jest jądrem (logiką) aplikacji, jeden plik Controller który filtruje dane z GET i POST po czym odpala odpowiednią akcję (której nazwa i paramerty są w URL). Akcja wykonkuje operację na modelu po czym ustala nazwę widoku. Całość pracy polega na dodaniu pliku akcji i szablonu widoku. Można przygotować odpowiednie wersje Controllera pod różne rodzaje URLi, a obecnie testuję różne szablony bo smarty wg xDebuga trochę mi zbyt wiele czasu wykonania skrytpu zabierają.

Rozumiem jak działają łańcuchy akcji ale nie potrafię ich zaimplementować, napisać (np. jak przechodzić z akcji do akcji i w jakiej postaci zwracane sa ewentualne wyniki (błędy) wykonanej akcji ?).

Ten post edytował jastu 26.05.2007, 12:23:59

[koodlaty]

[PHP] pobierz, plaintext 
<?
class aController 
{
  private $sView;
 
		function __construct() 
	{
		$this -> sView = $_GET['view'];
				self::setView();
	}
	function setView()
	{
		require_once('view/'.$sView);
	}
}
?>
[PHP] pobierz, plaintext 

Jeśli nie zamierzasz wywoływać metody statycznie, zamiast:

[PHP] pobierz, plaintext 
<?php
...
self::setView();
...
?>
[PHP] pobierz, plaintext 

bardziej po bożemu było by tak:

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

Jeśli natomiast masz zamiar używać metody statycznie - konstrukcja winna wyglądać:

[PHP] pobierz, plaintext 
<?php
public static function nazwaMetody(){...self::mojePoleLubMetoda...}
?>
[PHP] pobierz, plaintext 

(To tak na marginesie jeśli mówimy o PHP5 )

[matix]

Ok,
mniej więcej rozumiem i dziękuję za wszystkie przemyślenia na temat MVC.

Mam teraz pytanie, czy np:

Skrypt, który odbierze zmienną $_GET['type'] i wyświetli odpowiedni dla niego sposób widoku, będzie w kontrolerze ? Jeśli tak, to w jaki sposób powinien wyglądać ?
Może tak:

[PHP] pobierz, plaintext 
<?
class Controller 
{
	private $_sType;
	private $_aType;
 
	function __construct($sType) {
		$this -> _sType = $_GET['sType'];
	}
 
	public static function _set() {
		switch($this -> _sType) {
			case 1: $this -> _aType = 'rss'; break;
			case 2: $this -> _aType = 'news'; break;
		}
 
		return $this -> _aType;
	}
 
}
?>
[PHP] pobierz, plaintext 

Dałoby to radę?

Pozdro

[koodlaty]

Kod odbierajacy i filtrujacy dane z POST/GET (i wszelkie dane pochodzace od użytkownika) powinien znajdować się w metodach kontrolera, bardzo esencjonalnie zasady konstrukcji wzorca MVC podał ActivePlayer.
Polecam lekture dokumentacji Zend Framefork-a - kopalnia wiedzy o wzorcach i OOP.

Źle natomiast zrozumiałeś zastosowanie metod statycznych.
Nie ma powodu by Twoja metoda _set() była statyczna. Jej statyczne wykorzystanie i tak nie będzie mozliwe bo odnosi się do pól obiektu. Metody statyczne wywolywane są bez tworzenia obiektu, nie mogą więc odwolywać się do jego pól.

Opisując Ci sposób tworzenia metody statycznej chcialem powiedzieć że statyczne wywolanie self::setView(); było niepotrzebne i gdyby setView() odnosiło się do pól klasy jej działanie okazać by się moglo inne niż oczekiwane.

W tym konkretnym przypadku zamiast

[PHP] pobierz, plaintext 
<?php
self::setView();
?>
[PHP] pobierz, plaintext 

powinno być

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

to wszystko.

Konstrukcja:

[PHP] pobierz, plaintext 
<?php
public static function _set() {
		switch($this -> _sType) {
			case 1: $this -> _aType = 'rss'; break;
			case 2: $this -> _aType = 'news'; break;
		}
 
		return $this -> _aType;
	}
?>
[PHP] pobierz, plaintext 

Nie bedzie mogla być wywolywana statycznie, poza tym jest to bezzasadne.

[sf]

Proponowałbym wprowadzić dwie klasy - Request (przechowuje zmienne get / post ) i Response (odpowiedzialna za wyświetlanie). W mojavi3 bodajże tak jest

U mnie kontroler jest jeden i to on uruchamia zależnie od $Response->action odpowiednią akcję Jest także odpowiedzialny za obsługę łańcucha akcji oraz autoryzację (niektórzy ten element wyodrębniają z frameworka, ale wydaje mi się, że niepotrzebnie).

Ten post edytował sf 26.05.2007, 10:50:33

[Cysiaczek]

Rozumiem jak działają łańcuchy akcji ale nie potrafię ich zaimplementować, napisać (np. jak przechodzić z akcji do akcji i w jakiej postaci zwracane sa ewentualne wyniki (błędy) wykonanej akcji ?).

@jastu Co do zwracania błędów, to można się długo spierać. Ja rozwiązałem to poprzez zgłoszenie stanu aplikacji, co podpatrzyłem w książce (ok, error, jakiTylkoSobieWymyslisz). Łańcuchy akcji z kolei mi sie udało zaimplementować. Zapraszam do obejrzenia małej demonstracji (sorry za kiepską jakość, ale komp strasznie zwalniał przy nagrywaniu : )

@sf - Widzę, że mamy podobnie : >

żądanie -> rozwiązanie żądania (tworzy początkowy łańcuch akcji) -> wykonanie żądania (wywoływanie w pętli akcji i ewentualna modyfikacja łańcucha akcji) -> zebranie danych do wyświetlenia -> Output (rózne np, XML, HTML)

i jeszcze filmik, który niektórzy już widzieli
Filmik prezentuje między innymi jeden ze sposobów obsługi braku parametru żądania (id) i dwie różne reakcje na ten błąd.
http://cysiak.freeweb7.com/kvktest3 (plik video w formacie Theora, 2.8 MB)

Pozdrawiam.

[Ludvik]

Akcja wykonkuje operację na modelu po czym zwraca odpowiedni obiekt widoku.

Tak być nie powinno. Akcja nie ma prawa być powiązana w żaden sposób z obiektem widoku. MVC polega na oddzieleniu od siebie tych trzech warstw, więc wprowadzanie zależności pomiędzy modelem a widokiem łamie podstawowe zasady tego wzorca. Zmiana widoku spowoduje katastrofę w klasach akcji... Model powinien zwracać kontener z danymi, który następnie zostanie przekazany do widoku, tak aby nie były tworzone powiązania pomiędzy warstwami.

Sam pracuję w tej chwili nad implementacją MVC. Kontroler u mnie integruje całą aplikację, posiada wymienne Dispatchery, które tłumaczą żądanie HTTP na żądanie wykonania łańcucha akcji. Przed wykonaniem łańcucha, żądanie musi przejść przez filtry, w których np. można umieścić autentykację i autoryzację. Następnie kontroler iteruje przez kolekcję obiektów wywołujących akcje (czyli po prostu wykonuje kolejne akcje z łańcucha). W razie zmiany łańcucha, zostaje o tym poinformowany kontroler, który w razie czego wróci na jego początek. Kwestia implementacji obserwatora. Nad widokiem jeszcze myślę, gdzieś to upchnę po łańcuchu akcji... Dane są przesyłane w odpowiednich obiektach pomiędzy akcjami. W obiekcie kontekstu można zapisać informacje dotyczące całego żądania, czyli stan sesji itp...

[jastu]

Zmiana widoku spowoduje katastrofę w klasach akcji...

Czy możesz dokładniej opisać ? Normalnie (chyba wg wzorca) to controller odpowiada za zarządzanie akcjami(łańcuchami) i w zależnosci od wyniku uruchamia widok ... u mnie jeden dla całej aplikacji controller(sprawdza ządanie) wywołuje jedną dla każdego żadania akcję i dopiero ona w zależności od wyniki operacji na modelu określa widok - ale widok uruchamia controller. W ten sposób tworzenia aplikacji ogranicza się do przygotowania szablonów widoku i pisania akcji.

Powyższy opis sprawdza się przy aplikacjach o małym zróżnicowaniu uprawnień. Obecnie korzystając z tego modelu budowy do modelu trzeba wysyłać uprawnienia bierzącego użytkownika ( ). Przeczytałem kilka wątków o uprawnieniach użytkowników ale czytam chyba ze zbyt małym zrozumieniem - jak w MVC zarządzac uprawnieniami - musiałyby być przekazywane do Controllera ? do Widoku ? skąd ma obiekt widoku wiedzieć czy dany przycisk ma być wyświtelony czy nie ?

[Cysiaczek]

Obiekt widoku nie powinien nic wiedzieć o logice systemu. Jeśli chcesz wyświetlać coś, co jest zmienne, to możesz przesłać informacje z kontrolera do widoku w postaci jakiejś zmiennej i potem:

[PHP] pobierz, plaintext 
<?php
if ($costam){
//wyswietl cos
}
else {
//cos innego
}
?>
[PHP] pobierz, plaintext 

[jastu]

Skoro widok ma nic nie wiedzieć o logice systemu a ma otrzymać tylko dane modelu to znaczy że uprawnienia muszą wędrować do akcji lub controllera (albo do obu)...bo rozumiem że model nie interesuje się uprawnieniami - jest to logiczne jeśli chodzi o operację na modelu i akcje ... W tej sytuacji skomplikowanie obsługi żadania z uwzględnieniem uprawnień jest wysokie i uzasadnia to tworzenie oddzielnego controllera dla kazdego wywołania strony...tylko gdzie podejmuje się decyzję o uprawnieniach użytkownika dla elementu strony www.
Próbujemy - jeśli ze strony www którą tworzymy da się wyodrębnić elementy które decydują o nawigacji (np.menu bądz jakiś panel przycisków) i stworzyć z nich obiekty należące do obiektu widoku oraz przekazać im informację o uprawnieniach to...?

Piszę o uprawnieniach bo męczy mnie pisanie oddzelnych panelów administracyjnych...przeglądam stronę i jest coś nie tak to klikam i poprawiam bez dodatkowego logowania i podobnych.
Pozdrawiam

[Ludvik]

Dobrym rozwiązaniem jest wzorzec View Helper.

Chodziło mi o to, że akcje mają operować na danych i co najwyżej je zwracać. Komunikacją pomiędzy widokiem a modelem ma się zająć kontroler. Tak czy inaczej model nie ma prawa nic wiedzieć o widoku, ma tylko zrobić to, o co go proszono (operacje na danych). Wybieraniem widoku powinien zajmować się kontroler...

[Cysiaczek]

Może ustalimy jakieś słownictwo? Każdy tu używa innych definicji i stąd większość problemów.
Implementacji MVC i innych wzorców jest wiele - wiele z nich również inaczej definiuje pojęcia.
Moja propozycja jest następująca:

Model (nie mylić z modelem dziedziny (domain model))
Pozyskiwanie danych z bazy danych lub innych źródeł - udostępnia zwarty interfejs dostępu do danych. Wykonuje wszystkie operacje za tzw. zamkniętymi drzwiami.

Controller
Z premedytacją nie definiuję tu Front Controllera i Application Controllera, bo ich implementacje najczęściej są łączone i z biegiem czasu wychodzą poza definicje tych wzorców.
Tu definicje będą dwie:
a ) Controller jako klasa zawierająca akcje
Najczęściej spotykana odmiana implementowana przez np, CakePHP. W jego ramach definiujemy metody naszej aplikacji. Jest on częścią logiki aplikacji

b ) Controller jako obiekt sterujący akcjami
Nie zawiera żadnych metod odpowiedzialnych za logikę aplikacji, a jedynie steruje obiektami (np. polecenia/akcji) i reaguje na wyniki ich działania.

Widok
Tu jest wiele niedomówień

a ) Widok jako obiekt systemu (Output)
Część systemu odpowiedzialna za renderowanie (tu strony www). Odwołuje się do danych (udostępnionych przez kontroler, bądź model, co zależy od implementacji).

b ) Widok jako szablon
W praktyce plik, który jest wypełniany danymi przez aplikację (php, smarty, opt, i inne)
Można podzielić na:
- pasywny - przyjmuje dane, ale nie odwołuje się do metod kontrolera, czy modelu, czy innych obiektów obecnych w systemie. Operuje tylko na danych, które otrzyma.
- aktywny - to samom co wyżej, ale może się odwołać do innych obiektów systemu

Akcja
Tu również definicje mogą być różne, choć wszystkie dotyczą logiki aplikacji

a ) Akcja rozumiana jako obiekt polecenia
Wykonuje działanie (np. modyfikuje pobrane z modelu dane) i jest w jakiś sposób sprzężona z kontrolerem

b ) Akcja rozumiana jako część kontrolera
Jest metodą w ramach klasy kontrolera

c ) Akcja rozumiana jako użytkownik kodu
Wykorzystuje zarówno kontroler, model jak i inne klasy/obiekty w systemie.


Sami widzicie, ile może być różnych znaczeń słowa kontroler. Większość z Nas używa różnych kombinacji, co prowadzi do nie zrozumienia. Jeśli ktoś widzi inne możliwe definicje, to niech się podzieli. Zapewne można jeszcze parę znaleźć - można by stworzyć osobny topik : )

Pozdrawiam.

[Ludvik]

Mi się wydaje, że MVC to nieco wyższy stopień abstrakcji niż klasy, obiekty itp... Dlatego nie powinniśmy rozmawiać o klasach, tylko o tym, czego te warstwy dotyczą.

Model, czyli warstwa biznesowa, to po prostu wszelkie operacje na danych. Widok, czyli warstwa prezentacji. Prościej mówiąc warstwa odpowiedzialna za interakcję użytkownika z aplikacją. Widok nie może być jednym obiektem, gdyż do widoku zaliczamy wszelkie żądania, odpowiedzi. Tego w jeden obiekt nie można zamknąć, głównie z powodu podstawowych zasad OOP. Kontroler, to warstwa, która pośredniczy pomiędzy dwiema poprzednimi. Odbiera żądania, rozdziela zadania, współuczestniczy przy transferze danych pomiędzy warstwami modelu i widoku. Nie ma tu znaczenia, czy rozmawiamy o Front Controllerze czy Application Controllerze.

Akcja to po prostu jakieś działanie na danych. Akcje oczywiście, można pozamykać w obiekty, ale tak czy inaczej akcja jest raczej ogólniejszym pojęciem.

Wzorce projektowe są narzędziem nie są związanym z warstwą implementacji. Dlatego np. programiści PHP korzystają z katalogu wzorców J2EE. Każdy implementuje wzorce na swój sposób. Inny nie znaczy zły... Natomiast w rozmowie o wzorcach, rozmawiamy o architekturze, a nie implementacji.

[Cysiaczek]

Model, czyli warstwa biznesowa, to po prostu wszelkie operacje na danych

i za chwilę

Akcja to po prostu jakieś działanie na danych. Akcje oczywiście, można pozamykać w obiekty, ale tak czy inaczej akcja jest raczej ogólniejszym pojęciem.

Mógłbyś to sprecyzować? Jakie działania wykonuje tu model? Model zawiera akcje, czy odwrotnie?

Zgadzam się, że MVC dotyczy warstw aplikacji, nie klas (nazwałem widok obiektem - powinienem warstwą). Wszystko rozbija sie jednak o implementację. Mówisz, że warstwa kontroli pośredniczy pomiędzy modelem, a widokiem. Mi się wydaje, że jej działanie może być nieco szersze. Może kontrolować sposób wyświetlania (np. może decydować o wyświetlaniu dokumentu w formie zwykłego XML, wysłać do przeglądarki stronę www, a nawet wysłać "goły" tekst - decyduje o tym żądanie, a nie model, czy widok).
Właśnie te różnice utrudniają komunikację, bo to, co dla Ciebie należy do warstwy modelu, u mnie robi akcja. To, co dla Ciebie już jest widokiem, dla mnie może jeszcze być logiką. Trudno więc rozmawiać o MVC bez podparcia się konkretną implementacją, bo jest to zbyt szerokie pojęcie.
Osobiście jako model mogę potraktować klasę:

[PHP] pobierz, plaintext 
<?php
class News{
 
function update() // zmiana właściwści obiektu
function findById() // odnalezienie rekordu
fucnction save() // zapis (przy użyciu jakiejś abstrakcji baz danych)
 
}
 
//uzytkować mogę tak:
 
class mojaAkcja extends Action(){
 
function Perform(){
 
$id=$params->get('id');
$model=new News();
$news=$model->findById($id);
$news->setTitle('tytuł newsa');
$model->update($news);
$model->save();
}
 
}
 
// żadanie przychodzi tak:
// <a href="http://host.com/news/mojaAkcja/id_10" target="_blank">http://host.com/news/mojaAkcja/id_10</a>
?>
[PHP] pobierz, plaintext 

U Ciebie zapewne wygląda to inaczej i inne partie sytemu odpowiadaja za wykonanie tego żądania
url, który podałem jest rozpracowywany przez obiekty wchodzące w skład kontrolera, u Ciebie może to robić obiekt wogóle nie związany w kontrolerem.
Jednak jedno i drugie będzie dalej MVC

Pozdrawiam.

[Ludvik]

Tak jak pisałem, model to dane i operacje na nich. Skoro akcje zawierają operacje na danych, to zawierają się w modelu. Model jako obiekt nie powinien według mnie istnieć. Po prostu nie lubię pojęcia model, bo do niego zalicza się wszystko... Weźmy za przykład sklep internetowy.

Do modelu zaliczymy dane dotyczące produktów, działów, klienta oraz wszystkie operacje związane z nimi. Jeżeli klient kupuje książkę, to do modelu musimy wliczyć wszystkie operacje dotyczące produktu, zamówienia i użytkownika. Akcje odpowiadałyby za kolejne zadania: utworzenie zamówienia, związania zamówienia z użytkownikiem, dopisania produktu do list itd...

Może kontrolować sposób wyświetlania (np. może decydować o wyświetlaniu dokumentu w formie zwykłego XML, wysłać do przeglądarki stronę www, a nawet wysłać "goły" tekst - decyduje o tym żądanie, a nie model, czy widok).

Żądanie jest elementem widoku, bo widok jest warstwą prezentacji. Z kolei warstwa prezentacji odpowiada za interakcję z użytkownikiem, a jest nią bez wątpienia wysłanie żądania w dowolnej formie. W aplikacjach okienkowych żądaniem jest np. naciśnięcie przycisku. W aplikacjach sieciowych tę rolę pełnią żądania, w szczególności HTTP. Racja leży po środku, bo obie warstwy są w to zaangażowane. Tak czy inaczej, wszystkie te działania prowadzą do ustanowienia komunikacji pomiędzy modelem a widokiem. Wszystko w końcu musi się trzymać kupy...

Na schemacie widać to doskonale:
http://java.sun.com/blueprints/patterns/im...ure-generic.gif

[matix]

Wybaczcie, ale z tego co widzę to MVC to jedno wielkie nieporozumienie, każdy go pisze inaczej i według innego jest to źle No sory, ale poczytajcie se wszystkie posty;D

Mógłby w takim razie ktoś napisać jakiś prosty przykład z wykorzystaniem Controllera, Modelu i Widoku wraz z połaczeniem tego? Bo ja już teraz nic z tego nie wiem, jedyne co wiem to do czego to wszystko służy, lecz niestety każdy mówi, że w "tym czymś" ma być coś innego
W takim razie proszę o przedstawienie waszych praktycznych przykładów z życia programisty korzystającego z MVC

Pozdro


-edit-

Btw. Który z tych dwóch: Controller czy Model powinien łączyć się do mysql. Chodzi o mysql_connect / mysql_close(nie mówię o mysql_query, itp) ?

Ten post edytował matix 26.05.2007, 18:55:15

[Cysiaczek]

Przykład dotyczy wyświetlenia wartości wpisanej w pole formularza.
jest on bardzo prosty, a mój framework wymaga nieco nakładów pracy przy tworzeniu aplikacji, więc proste przykłady wyglądają dziwacznie.

plik index.php, czyli akcja index
unit oznacza nazwę modułu (mam tak, bo nie ma namespaces w php - jak będzie php6, to zmienie)

[PHP] pobierz, plaintext 
<?php
class unit_index extends Action{
 
function Perform(){
$req=$this->AHelper->getReqRegistry(); //elementy żądania m.in dane przesłane URL i POST
 
	if(!$req->has("tekst", "post")){ //jesli brak zmiennej tekst przesłanej przez post
	$this->setStatus("ERROR"); // zakomunikuj błąd kontrolerowi - wyświetli formularz
	return; //koniec
	}
$this->data->tekst=$req->get("tekst", "post"); //Dodajemy $tekst do danych przekazywanych potem do widoku
}
}
?>
[PHP] pobierz, plaintext 

plik actions.xml zawierający informacje dla kontrolera dotyczące akcji i tego, jak ma reagować na różne zgłoszone przez nią stany

[XML] pobierz, plaintext 
<?xml version='1.0' standalone='yes'?>
<actions>
      <index>
            <slot>index</slot>
            <status>
                  <ok>
                        <view>pokaz</view>
                  </ok>
                  <error>
                        <view>error</view>
                  </error>
            </status>
      </index>
</actions>
[XML] pobierz, plaintext 

Teraz warstwa prezentacji

plik index.slot.php - sloty to miejsca, przez które pliki szablonów są wstawiane na stronę www

[PHP] pobierz, plaintext 
<h1><?php $VHelper->get('index', 'unit'); //pobiera szablon wygenerowany przez akcję index z modułu unit ?></h1>
[PHP] pobierz, plaintext 

plik pokaz.tpl

[PHP] pobierz, plaintext 
<?php print $tekst; //wyświetlamy naszą zmienną zadeklarowaną w akcji ?>
[PHP] pobierz, plaintext 

plik error.tpl - zostanie wyświetlony, gdy nie przesłano danych

[PHP] pobierz, plaintext 
<form method="post" action="<?php print url(array("unit", "index"), '', true); ?>" />
<input type="text" name="tekst" />
<input type="submit" value="send" />
</form>
[PHP] pobierz, plaintext 

---edit
Zobacz, że klasa akcji jest maksymalnie izolowana od warstwy prezentacji - nie wybiera sama pliku, który ma zostać wyświetlony - zgłasza tylko stan, a resztą zajmuje się jądro systemu. Podobnie działają przekierowania. Ba! można w ten sposób nawet wyrzucić wyjątek. Ten przykład nie zawiera manipulacji danymi, ale jeśli takie są konieczne, to robi się to właśnie w ciele akcji lub wydziela się następną akcję, która to robi (to już bardziej zaawansowana zabawa)

Ten post edytował Cysiaczek 26.05.2007, 19:44:27