Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [ZF] Pominięcie domyślnej ścieżki widoku
Forum PHP.pl > Forum > PHP > Frameworki
Daimos
Witam,
głowię się nad drobnym problemem, chodzi o domyślną ścieżkę dla widoków w ZF1.
Ustawiam sobie ją za pomocą setBasePath i co widzę w przypadku aplikacji z modułami? ZF mimo wszystko najpierw zagląda do folderu z modułem i to mi się nie podoba, kolejność:
1. /modules/[MÓJ MODUŁ]/views/scripts
2. [Mój basePath]
2. [Mój basePath 2]
Jak wyeliminować punkt 1? Nie chcę, aby ZF tam szukał szablonu. Może ktoś z Was się już w to zagłębiał?
--- edit:
Jeśli to możliwe, to najlepiej by było po prostu zmienić kolejność wczytywania widoku na:
1. [Mój basePath]
2. [Mój basePath 2]
3. /modules/[MÓJ MODUŁ]/views/scripts
Ale problem w tym, że podstawowa ścieżka /modules/[MÓJ MODUŁ]/views/scripts jest chyba generowana w locie przez helper viewRenderer. Mogę nadpisać chyba to w pluginie, ale wtedy, jeśli w jakiejś akcji mam zmieniony widok za pomocą tego helpera - to nie zadziała.
Turson
Jeżeli odpalany jest kontroler z modułu to dlaczego widoku nie miałby szukać w module? Na tym polega modularyzacja.
Daimos
Skoro już interesuje Cie powód smile.gif
Mam aplikację, gdzie jest kilka modułów i chcę zrobić szablony. Tworzę folder z domyślnym systemowym szablonem, gdzie są wszystkie widoki, podzielone m.in. na foldery moduł/kontroler/akcja i szablony dzieci, które posiadają nadpisany domyślny szablon, lub nie.
Dlatego też, nie pasuje mi zupełnie szukanie widoku w katalogu modules.
Struktura mojej aplikacji to mniej więcej:
Kod
application
    modules
        modul1
             forms/models/controllers
        modul2
             forms/models/controllers
        modul3
             forms/models/controllers
    views
        system #katalog z szablonem systemowym
            modul1
                kontroler
                    akcja
        dowolnyszablon
            modul1
                kontroler
                    akcja

Wiem już, że problemem jest helper viewRenderer, ale jak to obejść, na razie nie wiem. Spróbuję jeszcze dodać jakiś prefix path dla niego, może coś z tego wyjdzie.
Innym rozwiązaniem, będzie trzymanie szablonu systemowego w każdym module, czyli tak, jak jest to domyślnie, ale nie mogę aktualnie tego zrobić, bo jest to pierwsze miejsce, w którym szablon jest poszukiwany, więc w razie czego, nie mogę go nadpisać - zamieszczając nowy szablon, zostanie on pominięty, bo najpierw wczytają się standardowe widoki.
viking
Dla każdej akcji można indywidualnie zmieniać szablon, można zmienić też domyślne zachowanie nadpisując standardowe klasy. Zobacz dokumentację http://framework.zend.com/manual/1.12/en/z...ontrollers.html
Natomiast i tak nie wiem co podany przykład ma dać bo wyrzucasz tylko wszystko poza katalog domyślny. Według mnie mało intuicyjne. Masz też layouty czyli podstawowy wygląd identyczny dla podstron.

Kod
    $view = new Zend_View();
    $view->setScriptPath('/path/to/app/views');
Daimos
Ok więc inaczej.
Docelowo, chciałbym ustalić folder podstawowy dla wszystkich widoków. Będzie to folder szablonu, np: /szablonNaNowyRok/
Całość ma polegać na tym, że jeśli w katalogu szablonu nie ma danego pliku phtml, to ma go pobierać ze standardowych, systemowych.
I jak pisałem wyżej, nie mogę tego zrobić, ponieważ ZF najpierw szuka w standardowej ścieżce, mimo, że ustawiam setScriptPath i co tam sobie nie wymyślę.
Także viking, pisałem już o setScriptPath, czytałem manual, ale problem w tym, że co bym nie ustawił, ZF zawsze i tak najpierw sprawdza standardową ścieżkę, a chcę, aby sprawdzał ją w ostatniej kolejności.

Aktualnie rozwiązałem to w ten sposób, jak opisałem w pierwszym poście. Dodałem 2x scriptPath i tam mogę trzymać systemowe widoki, bo jestem w stanie kontrować kolejność ich wczytywania.
viking
Nawet jeżeli sprawdzisz źródło:
  1. /**
  2.   * Resets the stack of view script paths.
  3.   *
  4.   * To clear all paths, use Zend_View::setScriptPath(null).
  5.   *
  6.   * @param string|array The directory (-ies) to set as the path.
  7.   * @return Zend_View_Abstract
  8.   */
  9. public function setScriptPath($path)
  10. {
  11. $this->_path['script'] = array();
  12. $this->_addPath('script', $path);
  13. return $this;
  14. }

Widać wyraźnie że czyści. addScriptPath dodaje tak jak mówisz. Jest jeszcze setBasePath.
Daimos
Viking, czytałeś całego mojego posta? smile.gif Problem w tym, że pomimo setBasePath, zend w pierwszej kolejności szuka widoku w folderze:
modules/MODUL/views/scripts/KONTROLER/AKCJA.phtml

Robi to prawdopodobnie, jak pisałem wyżej: viewRenderer (helper kontrolera). Robi to świetnie, ale chcę się wgryźć przed to, żeby najpierw sprawdził mi, czy widok istnieje w folderze z szablonem.

- edit
Wiem już więcej. ViewRenderer ma metodę: setViewBasePathSpec();
W której mogę ustawić ścieżkę dla domyślnych plików. Ale tylko jedną, koniec. Chyba jedynym wyjściem będzie napisanie swojego helpera, jako rozszerzenie viewRenderer
- edit 2
Na chwilę obecną napisałem plugin, który rozwiązuje problem, ale będę szukał jeszcze innego rozwiązania:
  1. class MyPrefix_View_Plugin extends Zend_Controller_Plugin_Abstract
  2. {
  3. public function preDispatch(Zend_Controller_Request_Abstract $request)
  4. {
  5. $template = 'templateName';
  6. $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
  7. if(file_exists(APPLICATION_PATH.'/views/'.$template.'/scripts/modules/'.
  8. $request->getModuleName().'/'.$viewRenderer->getViewScript()))
  9. {
  10. $viewRenderer->setViewBasePathSpec(APPLICATION_PATH.'/views/'.$template.'/');
  11. $viewRenderer->setViewScriptPathSpec('modules/:module/:controller/:action.:suffix');
  12. }
  13. else
  14. {
  15. $viewRenderer->setViewBasePathSpec(':moduleDir/views');
  16. $viewRenderer->setViewScriptPathSpec(':controller/:action.:suffix');
  17. }
  18. }
  19. }

Załatwia to problem, sam sprawdzam, czy w szablonie istnieje plik do podmiany. Mimo to, nie podoba mi się za bardzo takie rozwiązanie, pewnie da się lepiej smile.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.