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]

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 

Po pierwsze chyba jest literowka ale mniejsza o to.

Ogolnie skoro masz dostep do nazwy kontrolera w obiekcie request to poprostu w klasie Some_View go stworz i bedziesz mial dostep do nazwy kontrolera.

Inaczej nie wiem jak pomoc bo chyba nie do konca rozumiem twoj problem.

[jacekkobus]

Dzieki za odpowiedz.

Chodzi w sumie o przekazanie danych konfiguracyjnych (np sciezka do skryptow phtml) dla wszystkich widokow (Some_View) tak, abym nie musial tych informacji podawac przy ich tworzeniu w kontrolerze akcji.
Myslalem, ze mozna uniknac w jakis sposob uzywania singletona wewnatrz klasy widoku.

[marcio]

Jesli cie interesuje mozesz zobaczyc jak ja to mam w moim fw http://3paste.com/hash/489792946156cf72065c09981b54203a

A tak wywoluje np widok w komponencie logowania:

[PHP] pobierz, plaintext 
 
//walidacja
 
//proces logowania
 
//dodawanie msg do widoku
 
  /*
 
    zwrocenie widoku do glownego layoutu strony
 
 */
return $this -> view -> Layout('Auth', 'component', $this -> auth -> GetUserType()); 
 
 
[PHP] pobierz, plaintext 

[jacekkobus]

Ok dzieki.

Z tego co widze, sciezki do plikow masz "wbite" na stale, i modyfikujesz je uzywajac danych wejsciowych z konstruktora.
Tego wlasnie chce tez uniknac. Ja raczej zmierzam ku temu aby w bootraperze zdefiniowac kilka wariantow scizek, bo widoki moge
chciec przelaczac (np skorki itd), a pozniej w kontrolerze akcji przelaczac sie podajac tylko nazwe zestawu.

wygladalo by to tak

bootstrap.php
Layout::addScriptSource('default', 'application/scripts/default');
Layout::addScriptSource('bubbles', 'application/:module/scripts/bubbles');
Layout::setDefault('default');

a uzycie w Action_Controller:

Layout::using('bubbles');
$view = new Some_View('stopka.phtml'); // czyta plik application/:module/scripts/bubbles/stopka.phtml
Layout::using('default');
$view = new Some_View('stopka.phtml'); // czyta plik application/scripts/stopka.phtml

(:module to zmienna, ktora podmieniam na nazwe aktualnego modulu...)

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

Ten post edytował jacekkobus 20.01.2010, 15:19:24

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