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
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 Następna nazwa to 'B', potem 'C' itd

Pozdrawiam.

[starach]

Dobra to ja doleję oliwy do ognia i zacznę.
Format HTML versus XML. Jestem za pierwszym. Standard sprawdzony zaimplementowany w wielu projektach jak Wordpress.
Moim skromnym zdaniem główną jego przewagą nad formatem XML jest możliwość szczegółowej definicji sposobu wyświetlania w kodzie HTML.
Renderer taki jak Smarty parsuje 'pseudo-kod' który pozwala na zmianę formatowania poszczególnych elementów.
Tak niestety nie jest przy Rendererach XML. Załóżmy że FronController modułu wywołuje Controller akcji ( np. edytuj wpis w blogu )
Po czym dane są umieszczane, a nie przekazywane, bezpośrednio w widoku który jest plikiem XML. Zachodzi tutaj potrzeba utworzenia dodatkowej klasy która odpowiadałaby za manipulację widokiem lub rozszerzenie funkcji kontrolera akcji co mogłoby prowadzić do LavaFlow.
Jest to wielkim utrudnieniem jeśli praca jest podzielona między programistę i webmastera który ma za zadanie sformatować tylko sposób wyświetlania danych i wystarczyłaby mu odrobiona znajomości pseudokodu np. pakietu Smarty.

edit>
Jest to moim zdaniem o tyle bezsensu co przerzucanie się z dnia na dzień co chwile z różnych języków programowania.
Sprawa jest tutaj o tyle gorsza że PHP i HTML / XHTML mają ze sobą tylko tyle wspólnego że pierwszy używa dwóch pozostałych do prezentacji danych.
Więc jest to swojego rodzaju wybijanie się z rytmu.

edit>>
No co jest. Na prawdę liczyłem że ktoś mnie opieprzy i uświadomi że się baaaardzo mylę...

Ten post edytował orglee 13.09.2008, 14:19:08