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]

Mnie osobiście denerwuje, że w MVC rozpowszechnionym przez ROR brakuje rzeczywistego podziału pomiędzy Widokiem, a Kontrolerem (lub akcją – umownie będę stosował termin kontroler).

Symfony:

[PHP] pobierz, plaintext 
<?php
// Proszę nie traktować poniższego przykładu dosłownie, wiem, że można
// to po części zautomatyzować, ale chcę pokazać, że nie da się całkowicie uniknąć.
class PostActions extends sfActions
{
  public function executeRead()
  {
   // pobieramy dane z modelu
 
  if ($this->getRequestParameter("type") == "pdf") {
    // Generujemy post jako PDF
    $this->getResponse()->setContentType('application/pdf');
    // reszta kodu wykorzystująca np. Zend_Pdf
  elseif ($this->getRequestParameter("type") == "mp3" ) {
    // Generujemy post jako dźwięk – czyta Michał Żebrowski 
    $this->getResponse()->setContentType('audio/mpeg3');
    // reszta kodu wykorzystująca… cokolwiek co będzie dostępne pewnie za 50 lat
  } else {
     // to zapewne jest domyślne, ale zostawiam dla przejrzystości
     $this->getResponse()->setContentType('text/xml');
     // reszta kodu…
  }
}
?>
[PHP] pobierz, plaintext 

Podobnie ma się z innymi frameworkami tj. Cake, Zend, czy Kohana. Widok istnieje w nich bardziej jako abstrakcyjny byt. Fakt można to obejść – ZF proponuje zaimplementowanie logiki widoku w szablonach. Ale przecież szablon nie musi być PHPowy, może to być phpTAL, Smarty czy cokolwiek innego, pełniąc rolę tylko prezentacyjną (np. żadnego ustawiania nagłówków).
Co za tym idzie – w wymienionych przeze mnie frameworkach - nie ma miejsca na odseparowaną logikę widoku. Wszystko jest wszyte w kontroler – co mija się z jego celem jako pośrednika pomiędzy Modelem, a Widokiem.


@orglee - nie do końca rozumiem co napisałeś.
Chodzi Tobie o szablony, które są parsowane przez renderery, tak?