Przekazywanie danych o sciezce plikow widoku do kontrolera, Dont Repeat Yourself. Jak ? Opcje

[jacekkobus]

Czesc.

Zaprezentuje na przykladach:
To narazie mam:

[PHP] pobierz, plaintext 
#(jestesmy w kontrolerze akcji)
$widok = Some_View('index/plik.phtml');
$widok->setScriptsDirectory('application/tutaj_modul/view/scripts/tutaj_kontroler');
 
(...)
 
return $widok->render();
[PHP] pobierz, plaintext 

A chce:

[PHP] pobierz, plaintext 
#(jestesmy w kontrolerze akcji)
$widok = Some_View('index/plik.phtml');
return $widok->render();
[PHP] pobierz, plaintext 

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:

[PHP] pobierz, plaintext 
$widok = Some_View('index/plik.phtml', $this->request);
[PHP] pobierz, plaintext 

... 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.

Ten post edytował jacekkobus 19.01.2010, 22:40:10

[marcio]

Ogolnie troszke dziwnie Ci to wyszlo. Nie myslales, zeby np.: "addJs" wylaczyc do osobnego obiektu, helpera czy tez pluginu ?
Ja mam klase Object_Header ktora rozszerza klase Some_View i ow obiekt zawiera metody addJs, addCss, setTitle itd.

Wtedy robie:

$strona = new Some_View('strona.phtml');

$strona->header = new Object_Header();
$strona->header->setTitle('tytul strony');

return $strona->render();

Formularze na przyklad rowniez sa u mnie rozszerzeniem klasy widoku, z tym ze zawieraja metody odpowiadajace za dodawanie pol itd...

plugin to calkiem inna bajka.

Po co mam sobie utrudniac zycie i miec 3 klasy view 4 helpery jak i tak tego nie bede uzywal?

Klasa prosta spelnia swoje zadanie i tak ma byc pod moja implementacje jest dobra.

Formularze wole pisac na sztywno nie widze powodu zeby robic cos w stylu:

[PHP] pobierz, plaintext 
 
$forms = new Form();
 
$forms -> OpenForm('post','self');
 
$forms -> AddInputText('login');
 
//i inne badziewia
 
[PHP] pobierz, plaintext 

Jak narazie takie cos mi nie upraszcza zycia tylko je komplikuje.

Jednak nie rozumiem twojego problemu masz juz opis co i jak teraz tylko to zaimplementuj i potestuj ja nie wiem jak dziala i jak wyglada twoj system wiec rozwiazanie jest bardziej subiektywne niz obiektywne, to bardziej zalezy od ciebie ma pasowac tobie nie jakiemus pr0 programiscie ktory ci powie nie tak jest do dupy.