Mianowicie czy dopuszczalne jest coś takiego że załóżmy mam kontroler setup:

[PHP] pobierz, plaintext 
 class Setup extends Controller
 {
    public function __construct()
    {
        parent::__construct();
    }
 
    public function index()
    {
		// Zainicjowanie zmiennej która zostanie wprowadzona do widoku:
		$var = null;
		// Załadowanie modelu:
		$this -> load -> model('setup');
		$model = new Model_Setup; // Przypisanie widoku w kontrolerze
                $var['title'] = $model -> get_title();
		// Załadowanie widoku i przekazanie do niej zmiennych:
		$this -> load -> view('setup', $var);
   }
 }
[PHP] pobierz, plaintext 

Czyli w moim wypadku działa to tak iż Kontroler inicjuje model i widok następnie przepisuje do zmiennej w tablicy funkcję pobierającą dane z modelu i tą że zmienną umieszczam w widoku. Czyli jak by nie patrzeć widok pobiera zmienną z kontrolera a nie bezpośrednio z modelu? Czy ja się już pogubiłem? Praktycznie wszędzie pisze jako że widok ma pobierać dane z modelu, jak to ustosunkować w moim wypadku? Z góry dzięki za odpowiedzi Pozdrawiam.

Poprostu masz MVP

Mógłby się ktoś jeszcze wypowiedzieć? Ewentualnie odpowiedzieć na moje pytania?

Mimo że twoja metoda jest troszeczkę oryginalna to jest w pełni ok.

Założeniem MVC jak wiesz jest oddzielenie M od V i od C

C powiniem miec wiedze i dostęp do M i V ale M nie powinno mieć nic wspólnego z V i na odwrót - chyba że ktoś przekaże M jako zmienna do V ;P

U Ciebie działa to tak, że C zbiera wszystkie dane, powołuje model zbiera z niego dane, następnie przekazuje je do widoku. Z podanego kodu wynika, że wszystko jest ok.



I tak powinno być. To C powinien dane zwrócone przez model przekazać widokowi ... Jak niby model sam miałby je przekazać widokowi... Gdzie tak piszą Oczywiście to są ząłożenia, czasem się je nieco nagina ale zasada jest właśnie taka...



Ok skąd to się tu wzięło to nie wiem... To nie jest żadne MVP - to jest zwykłe MVC - z kodu wynika że wszelkie obowiązki są zachowane , C nic sam nie wyświetla, przekazuje dane do widoku który to powinien je wyświetlić. Gdzie tu Prezenter?

@Przem4S - wszystko jest ok

Dla przykładu jeszcze podam jakiś kawałek kodu zaciągnięty z przykładu kursu dla Zenda. jest to akcja "add" jednego z kontrolerów.

[PHP] pobierz, plaintext 
function addAction() {
   $this->view->title = "Add New Album";
 
   if ($this->_request->isPost()) {
      Zend_Loader::loadClass(’Zend_Filter_StripTags’);
      $filter = new Zend_Filter_StripTags();
 
      $artist = $filter->filter($this->_request->getPost(’artist’));
      $artist = trim($artist);
      $title = trim($filter->filter(
      $this->_request->getPost(’title’))); 
 
      if ($artist != ” && $title != ”) {
         $data = array(
           ‘artist’ => $artist,
           ‘title’ => $title,
         );
         $album = new Album();
         $album->insert($data);
         $this->_redirect(’/');
         return;
      }
   }
   // set up an "empty" album
   $this->view->album = new stdClass();
   $this->view->album->id = null;
   $this->view->album->artist = ”;
   $this->view->album->title = ”; 
 
   // additional view fields required by form
   $this->view->action = ‘add’;
   $this->view->buttonText = ‘Add’; 
}
[PHP] pobierz, plaintext 

Jak widać kontroler sprawdza wejście, powołuje model, przekazuje jakieś dane do widoku itd... To też nie jest MVC?

P.S. Nawiasem mówiąc jeśli robisz ten framework sam - polecam dodawanie do akcji kontrolerów jakiegoś postfixa - na przykład Action tak jak w zendzie - to daje tyle, że wewnątrz wtedy masz rozróżnienie czy dana metoda jest akcją czy zwykłą metodą obiektu kontrolera (której nie można wywołać jako akcji z przeglądarki)

Po prostu myślałem że w kontrolerze mam przypisać tylko model do zmiennej i przekazać go do widoku, a w widoku zrobić coś w stylu:

[PHP] pobierz, plaintext 
$model -> funkcja_w_modelu();
[PHP] pobierz, plaintext 

Ale wtedy wydaje mi się że i tak wszystko opierało by się na kontrolerze który to przekazywałbym model. Po prostu już się pogubiłem czy naginać to jeszcze do wzorca czy jest ok. Ale uzyskałem odpowiedź za którą serdecznie dziękuję. Leci pomógł . Pozdrawiam

Ten sposób pokazany przez Ciebie z przekazaniem modelu do widoku też jest ok

O ile model nie został powołany w widoku, który to z reguły takimi rzeczami zajmować się nie powinien jednak jeśli model ma na przykład metodę, która zwraca jakąś tablicę to jak najbardziej można przekazać model taki do widoku pod jakąś zmienną i w skrypcie widoku w pętli wyświetlić poszczególne wartości

Wówczas wszystko też jest jak najbardziej zachowane Grunt aby widok zajmował się tylko wyświetlaniem wartości, model ich przygotowaniem/pobraniem/zapisem a kontroler tym wszystkim rządził ;P

Zacznijmy od tego ze jesli taka metoda nie jest akcja kontrolera to bedzie to raczej metoda z zasiegiem protected/private skoro nie ma do niej odwolania przez url to po co ona ma byc w ogole publiczna?!?



Cytat z wiki:


Poprostu prezenterem jest wlasnie kontroler, widokiem szablon(zalezy od implementacji) a model to model
MVP wiki:

http://nirajrules.wordpress.com/2009/07/18...vs-mvp-vs-mvvm/


No i wlasnie tu sie chyba mylisz, poczytaj bloz Zyx'a tez wlasnie w MVC kontroler nie pelni roli posrendika

EDIT:
https://github.com/zyxist/Trinity/blob/mast...s/View/Grid.php tak wyglada widok w MVC

A od kiedy kontroler formatuje dane do wyświetlenia?

Bo to nie jest kontroler lecz prezenter

Nie o to mi chodziło.

Opisz mi co to jest formatowanie danych do wyświetlenia w widoku?

Czy przekazanie widokowi danych wprost z modelu jest ich formatowaniem?

EDIT:

Co do widoku z trinity - ok tu masz rację tak to powinno wyglądać Chodzi też jednak o to jak ludzie to tak naprawdę wykonują, w wielu przypadkach nie robi się takich widoków a korzysta z podstawowego obiektu widoku, który jedynie otrzymuje od nas nazwę pliku ze skryptem, który ma wyświetlić a wszelkie dane dopisywane mu są w obrębie danej akcji kontrolera. Tak to jest w 90% robione na przykład w Zendzie gdzie oczywiście widoki można tworzyć indywidualne ale większość tak po prostu nie robi.

To o co mi chodziło nie wiąże się z samym widokiem w sensie klasy/obiektu - może mogłem to bardziej rozpisać - chodzi mi o skrypt widoku (szablon) - ten kod nie powinien powoływać modeli i się nimi "bawić". Jeżeli idziemy tą drogą gdzie budujemy poszczególne obiekty widoków to jak najbardziej jest to słuszne i wówczas wszystko jest w 100% prawdą. Jednak jeśli (a często tak jest) nie chcemy się w to bawić i korzystamy z domyślnego widoku to przerzucamy tą funkcjonalność na kontroler co nie robi z niego zawsze prezentera

Tutaj masz to dobrze opisane.

Chodzi glownie o roznice pomiedzy relacjami kazdej warstwy we wzorcu MVC i MVP

No właśnie taką jedną znalazłem:



Jak to rozumiesz - bo ja już zgłupiałem

Do 11 kwietnia nie poczyta

Nie mniej, w MVC widok powinien się komunikować z modelem, bez pośrednictwa kontrolera.

Rozumiec rozumiem ale przeczytaj calosc i spojrz na diagramy.

Czyli jak to rozumiec? Np w kohanie kontroler tez przekazuje dane z modelu do widoku.

A tak ze zaden fw symfony/kohana/zend/cake/ci nie implementuja "prawidlowego" MVC.

To nie tak że wszystkie te frameworki tego nie implementują a programiści (na pewno w przypadku Zenda bo pozwala on na takie zarządzanie widokiem jak przedstawiłeś z Trinity) ale tego się raczej tak nie robi... bo tak się przyjęło w nim :/

Czyli rozumiem do poprawki relacja widoku z modelem.... Czy juz tego nie zmieniac?

Ze jacy programisci framework z gory narzuca swoja implementacje i tyle.Nie wiem jak to sie ma w Zend ale poprostu wszedzie pisze MVC a to z MVC nie ma az tak duzo wspolnego.Zobacz sobie asp.net mvc


Nie chodzi o to co trzeba poprawic kazdy pisze jak mu wygodniej i tak jak jego idea przybliza sie w "swiecie" kodu.Niemniej jednak jesli cos nie jest MVC to sie tego na chama tak nie nazywa.
Kazdy wzorzec architektoniczny jest dobry jak inny, kazdy ma swoje zalety i wady.