Zagadnienie co do wzorca MVC, Pobieranie danych do widoku. Opcje

[Przem4S]

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 (IMG:style_emoticons/default/smile.gif) Pozdrawiam.

Ten post edytował Przem4S 7.03.2012, 21:24:04

[marcio]

Poprostu masz MVP

[Przem4S]

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

[Sephirus]

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 (IMG:style_emoticons/default/tongue.gif)

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.

Czyli jak by nie patrzeć widok pobiera zmienną z kontrolera a nie bezpośrednio z modelu?

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

Poprostu masz MVP

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 (IMG:style_emoticons/default/wink.gif)

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? (IMG:style_emoticons/default/smile.gif)

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) (IMG:style_emoticons/default/wink.gif)

Ten post edytował Sephirus 8.03.2012, 09:38:55

[Przem4S]

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ł (IMG:style_emoticons/default/smile.gif) . Pozdrawiam

[Sephirus]

Ten sposób pokazany przez Ciebie z przekazaniem modelu do widoku też jest ok (IMG:style_emoticons/default/smile.gif)

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 (IMG:style_emoticons/default/smile.gif)

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

[marcio]

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)

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?!?

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?

Cytat z wiki:

Widok jest odpowiedzialny za prezentację danych w obrębie graficznego interfejsu użytkownika. Może składać się z podwidoków zarządzających mniejszymi elementami składowymi. Widoki posiadają bezpośrednie referencje do modeli, z których pobierają dane, gdy otrzymują od kontrolera żądanie odświeżenia. Widoki mogą także modyfikować stan modelu, jeśli dana modyfikacja dotyczy sposobu prezentacji danych

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

The presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view.

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

Grunt aby widok zajmował się tylko wyświetlaniem wartości, model ich przygotowaniem/pobraniem/zapisem a kontroler tym wszystkim rządził ;P

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

Ten post edytował marcio 8.03.2012, 10:23:51

[Sephirus]

... and formats it for display in the view.

A od kiedy kontroler formatuje dane do wyświetlenia?

Ten post edytował Sephirus 8.03.2012, 10:21:24

[marcio]

Bo to nie jest kontroler lecz prezenter (IMG:style_emoticons/default/wink.gif)

[Sephirus]

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ć (IMG:style_emoticons/default/smile.gif) 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 (IMG:style_emoticons/default/smile.gif)

Ten post edytował Sephirus 8.03.2012, 10:35:31

[marcio]

Tutaj masz to dobrze opisane.

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

[Sephirus]

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

One other big difference about MVC is that the View does not directly bind to the Model. The view simply renders, and is completely stateless. In implementations of MVC the View usually will not have any logic in the code behind. This is contrary to MVP where it is absolutely necessary as if the View does not delegate to the Presenter, it will never get called.

Jak to rozumiesz - bo ja już zgłupiałem (IMG:style_emoticons/default/smile.gif)

[by_ikar]

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

Do 11 kwietnia nie poczyta (IMG:style_emoticons/default/wink.gif)

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

[marcio]

Rozumiec rozumiem ale przeczytaj calosc i spojrz na diagramy.

[Przem4S]

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

[marcio]

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.

[Sephirus]

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 :/

[Przem4S]

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

[marcio]

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 :/

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

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

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.