Widok - renderowanie widoku, sposoby implementacji, różnice w istniejacych rozwiązaniach Opcje

[Cysiaczek]

Mam nadzieję, że trafię w gusta z takim tematem.
Dyskusja dotyczy szeroko rozumianego V w architekturze MVC, jego budowy i sposobów działania w różnych frameworkach i rozwiązaniach własnych.

Terminologia A
Proponuję przyjąć taką terminologię , aby nie było w dyskusji nieporozumień.

Widok to inaczej warstwa prezentacji wyników użytkownikowi. W budowie występują: format i renderer
Formatami są np. HTML, XML, plik tekstowy, obrazek
Rendererami dla formatu HTML są np. (gołe)PHP, Smarty, OPT

Dane widoku to wszelkie dane, przekazane do widoku przez kontroler lub dane, do których widok ma dostęp w inny sposób.
Proszę zatem nie pisać, "że widok pobiera dane z modelu", bo jeśli ma do niego dostęp, to model jest daną, którą widok potrafi zinterpretować.


Mile widziane diagramy UML lub inne, byle miały ręce i nogi (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Proszę nie zadawać pytań przedszkolnych!

P.S Jeśli ktoś ma jeszcze jakieś propozycje terminologii, proszę zgłosić mi, albo któremuś moderatorowi - jeśli będa sensowne, zostaną dodane w tym poście.
Jeśli ktoś się nie zgadza z tą terminologią, niech zaproponuje inną i zaznacza, której używa w dyskusji (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Następna nazwa to 'B', potem 'C' itd

Pozdrawiam.

[LBO]

Od samego typu widoku nie jest zależne która akcja się wykona, więc to nie Router powinien decydować jaki będzie "typ" wynikowy. To już jest poziom kontrolera. Można oczywiście wykorzystać mainControler do tego, ale to jednak w nim powinien być wybierany widok.

Jak nie? Przecież router tłumaczy URLe, parametry z CLI, komendy głosowe ((IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) ) jaką akcje ma wykonać? Tym samym wydaje mi się, że od niego zależy jaki format wynikowy ma być. Dla CLI, czy SOAP to będzie jasne, ale dla web requestów już nie (HTML, (AJAX) JSON, (AJAX) XML).
Kontroler/Akcja ma byc niezależna od formatu wynikowego. Dlatego tak potepiam te stosy ifów sprawdzających rodzaj żądania i generujacych odpowiedni output w wewnątrz akcji.

[edit]Hmmm, tak myślę, że może nie tyle Router, co warstwa requestu.[/edit]

Zauważyłem właśnie, że strasznie dużo ludzi utożsamia widok z renderem.

[PHP] pobierz, plaintext 
<?php
// pseudo costam kontroler
function executeListingAction($request_parameters) {
    $model = new SomeListingModel();
    $listing = $model->getAllByPage($request_parameters['page']);
 
    // i tutaj pies pogrzebany, bo patrząc na większość frameworków
    // $this->view jest instancją jakiejś nakładki np MyFrameworkSmartyView,
   // MyFrameworkOptView, albo MyPDFView, czyli w istocie renderera.
    $this->view->set('listing', $listing);
 
   // i co potem?
   if($this->request_type == 'pdf') {
      $this->resonse->setContentType('application/pdf');
      $this->view->setPDFTemplate('templates/listing.pdf'); // bo tutaj renderer obsluguje PDF, nie ma tego w podstawowym interfejsie klasy widoku. bleh!
   } else if($this->request_type == 'ajax') {
      $this->resonse->setContentType('application/json');
   }
   // gdzie tu jakikolwiek podzial kontrolera/akcji od widoku?
}
?>
[PHP] pobierz, plaintext 

Pytanie, jak z szablonami html wiadomo, mają określoną nazwę i lokalizacje i w tan sposób są dobierane, to jak sprawa przy PDF, gdzie musi istnieć klasa która umie wygenerować odpowiednie dane wynikowe? W sumie to sam widok powinien wiedzieć jaka jest domyślna konfiguracja, więc można dla PDF tworzyć unikatowe klasy renrerer'ów, które by potrafiły obsłużyć to co widok dostał.
(chyba muszę sobie przyswoić lepiej słownictwo, bo się nie dogadamy ;] )

Lepiej stworzyć widok(i) akcji, który bedzie potrafil obsluzyć kilka rodzajów formatów wyjściowych w tym np. modyfikować dane z kontrolera i dopiero je przekazywać do renderera. O tyle wygodniej, że nie trzeba robić renderera JSON, bo wystarczą fukcje natywne.

A no i to sam widok określa jaki typ jest zwracany, bo on wie kim jest, nie ma żadnego ustawiania.

Ogólnie tym do czego dążę to aby mieć jakieś widoki (Smatry/OPT/XML/PDF/JSON) i do nich odpowiednie "renderer"y dla smarty .tpl, dla PDF odpowiednia klasa itd.
Dzięki temu, jakby ktoś chciał zmienić system szablonów wystarczy zaimplementować odpowiedni interfejs/abstrakcje widoku i dla miejsc wystąpienie potrzebne renderery. W czym renderery nie są jakoś zunifikowane, bo należą tylko do widoku.

EDIT: literówka

O i doszedłem do Tego, przeczytałem i też mi się podoba. Chociaż trochę sie skrzywiłem, na to, że dla każdego rendera na twardo będzie trzeba obsługę formatu wpisać (czyli ten skrypt PHP dla PDF i tpl dla Smartów). Nic nie przebije samego PHP gdzieś pomiędzy jeszcze - chociażby mozliwości jego użycia.

Ten post edytował LBO 16.09.2008, 21:36:45