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.

[Sedziwoj]

Mi też się wydaje że problemem jest raczej ustalenie jak to ma się dzielić, gdzie co wykonywać, a nie jak to zaimplementować.
bo mamy konkretną akcję, ona pobiera dane, obrabia, i tu nasuwa się pytanie co dalej, przekazuje do widoku, ale z tego co się mówi, to ta akcja powinna wybrać jaki.
I teraz te dane trafiają do widoku, czy to będzie Smarty/OPT/XML/PDF tworzony (jeśli jest, bo przy czystym html+php niema) odpowiednie obiekty i przekazywane dane oraz "szablon", i tu dla Smart to plik *.tpl, dla PDF to zunifikowany obiekt renderera, który będzie umiał wygenerować dokument wykorzystując obiekt stworzony w widoku. Potem widok uruchamia display na tym generujący i na tym kończy swoje działanie.

Tak to wygląda moim zdaniem, aby rozdzielić coś co generuje Smarty itd. od konkretnego przypadku *.tpl czy renderera dla PDF.
Sama akcja na podstawie jakiś danych powinna określić co będzie tym generatorem, a sam generator wie jaki typ danych zwraca.