Zaprezentuje na przykladach:
To narazie mam:
#(jestesmy w kontrolerze akcji) $widok = Some_View('index/plik.phtml'); $widok->setScriptsDirectory('application/tutaj_modul/view/scripts/tutaj_kontroler'); (...) return $widok->render();
A chce:
#(jestesmy w kontrolerze akcji) $widok = Some_View('index/plik.phtml'); return $widok->render();
Pierwsze rozwiazanie to oczywiste zlo. Przy okazji kazdy nowy widok (klasa Some_View) wymagalby takiej samej procedury,
co przy podziale strony na osobne elementy - z uzyciem layoutu, stanowilo by spore uniedogodnienie.
Jak byscie rozwiazali ten problem ?
Mam kontroler frontowy, rejestr, w kontrolerze akcji mam rowniez dostep do obiektu request. Obiekt request ma dostep do nazwy kontrolera, akcji i modulu.
W zendzie rozwiazane jest to na zasadzie ... pluginu. I nie do konca to pojmuje.
Teoretycznie moglbym zrobic jeszcze:
$widok = Some_View('index/plik.phtml', $this->request);
... i wydedukowac sciezke do ow plikow widoku z tego, co daje mi request, ale to tez wydaje sie byc srednim rozwiazaniem.
Nie chcialbym angazowac tutaj (wewnatrz Some_View) zmiennych statycznych. Powinienem ?
W sumie prosilbym o przyklad jakiegos wzorca. Stosowane praktyki...
Myslalem nad fabryka inicjalizowana w bootstraperze, ktora przekazywana by byla do kontrolera akcji i produkowala widoki wstrzykujac im
te opcje konfiguracyjne, ale tu mam inny dylemat - gdzie ow fabryke przechowac. We froncie, a moze w rejestrze, a moze ma byc statyczna ...
Bede wdzieczny za pomoc.