mam pytanie o budowę obsługi kilku layout'ów dla jednego systemu MVC.
np. do strony głównej mam przypisany layout "main", do podstron np "pages", do listy produktów "products" - wszystkie one mają elementy wspólne - np top menu , foot menu, ale mają elementy różniące je np. left menu i np ("products") zawiera wyszukiwarkę , mogą mieć tez inne style CSS, inne przypisane skrypty JS
w jaki sposób to zaimplementować tak, żeby najmniej logiki pchać do samego szablonu a przy tym, żeby nie duplikować sobie kodu.
wiem, że mogę użyć helperów (przecież helper to w zasadzie logika wewnątrz szablonu) i tam gdzie ma być top menu dać bezpośrednio w szablonie np funkcje top_menu() ale wolał bym generować menu zanim będę obrabiał szablon danego layoutu
chciałbym to zaimplementować jak najprościej i najczytelniej, przeglądałem kilka rozwiązań np "Layout.php" z Zend framework, dekorowanie szablonów w Symphony ale nie jest to dla mnie do końca czytelne. brakuje też w necie bardziej skomplikowanych przykładów generowania w jednym projekcie kilku layoutów - najczęściej jest tylko pokazane czytanie jakiś elementów dla danej akcji ale słobo jest opisane co z elementami które dla wielu akcji są identyczne (np wczytanie biblotek js)
mam taki pomysł , żeby:
1. zrobić ogólną klasę "layout", która zawierała by kilka metod wspólnych - np przypisanie domyślnej bliblioteki js, css
2. dla każdego layoutu tworzymy nową klasę dziedzicząc po tej klasie np layout_majn, layout_pages (mogła by dziedziczyć po layout_main), layout_products, które by zawierały odpowiednie rozszerzenie w stosunku do domyślnej klasy o nowe helpery (lub tylko ich wywołanie), dodatkowe definicje css, js.
3. każda z klas dziedziczących po klasie "layout" musiała by mieć metodę "run()", która była by uruchamiana przez "dispacher" i robiła tą cała brudną robotę wygenerowania danych ogólnych dla wybranego layout. przed wczytaniem wybranego template danego layoutu
nie wiem czy to rozwiązanie jest dobre? macie może jakieś tutoriale, przykłady jak jeszcze to można rozwiązać?
Pełna wersja: multiple layouts
Taki coś robi się dość prosto. Piszesz kontroler główny strony i dla niego jego widok główny z kilkoma elementami stałymi dla wszystkich (ramy szablonu i choćby część topu lub stopka) i elementami "pustymi", czyli zmieniającymi się. To zazwyczaj content, menusy, ogólnie panele 
One w trakcie wywoływania adresu będą wołały o główny szablon i uzupełniały "luki", czyli owe brakujące elementy szablonu. Łatwo i szybko ideę tego rozwiązania można załapać studiując tworzenie strony w frameworku Kohana 2.X. Nie jest to MVC, ale myślę, że sama idea pomysłu jest tam prosta do wyhaczenia
One w trakcie wywoływania adresu będą wołały o główny szablon i uzupełniały "luki", czyli owe brakujące elementy szablonu. Łatwo i szybko ideę tego rozwiązania można załapać studiując tworzenie strony w frameworku Kohana 2.X. Nie jest to MVC, ale myślę, że sama idea pomysłu jest tam prosta do wyhaczenia
a czy w Kohana 3 jest to jakoś inaczej zrobione? bo 2-ki nie oglądałem, 3-kę znam jako tako.
a co do tego kontrolera głównego - to jak sobie radzić, gdy jednak layout bardzo mocno różni się w zależności do wybranej akcji i w zasadzie poza strukturą headera html nie ma podobieństwa? np panel administracyjny a np widok artykułu - czy tu nie lepiej mieć 2 kontrolery?
a co do tego kontrolera głównego - to jak sobie radzić, gdy jednak layout bardzo mocno różni się w zależności do wybranej akcji i w zasadzie poza strukturą headera html nie ma podobieństwa? np panel administracyjny a np widok artykułu - czy tu nie lepiej mieć 2 kontrolery?
A tam gadasz ) Panel amina z reguły i tak korzysta z głównego layoutu. Główny layout może mieć postać:
Poza tym chyba nie rozumiesz jednego. MVC nie polega na tym, że tworzysz jeden kontroler, który gra i tańczy. Żądanie wywoła właściwy kontroler, ale ów właściwy i tak najpierw zawoła o główny, by go informacjami swoimi wypełnić. Tak więc niemal nigdy nie będzie tak, że wywołasz tylko jeden kontroler i na tym się skończy. Zazwyczaj łańcuchem wywołasz jeszcze kilka innych.
i to koniec... Klasy dziedziczące po kontrolerze szablonu, który ów widok ma jako bazowy same mu zmienne wypełnią. Czym? A co nas to obchodzi? Niech one się martwią
Poza tym chyba nie rozumiesz jednego. MVC nie polega na tym, że tworzysz jeden kontroler, który gra i tańczy. Żądanie wywoła właściwy kontroler, ale ów właściwy i tak najpierw zawoła o główny, by go informacjami swoimi wypełnić. Tak więc niemal nigdy nie będzie tak, że wywołasz tylko jeden kontroler i na tym się skończy. Zazwyczaj łańcuchem wywołasz jeszcze kilka innych.
to co przedstawiłeś jest dla mnie oczywiste - sam układ szablonu nie jest dla mnie problemem, mam tam wszystko opracowane. mam też przygotowane same moduły z akcjami i ich kontrolery.
ja zastanawiam się nad tym jak zorganizować te dodatkowe kontrolery tak, żeby nie powielać za wiele kodu który wczytuje np jakieś helpery albo bilioteki js.
w Symphony widzę, że helpery includowane są bezpośrednio w szablonach (czasai na podstawie jakiś warunków) - tego chcę uniknąć - chciałbym je ładować poziom wyżej w jakimś kontrolerze.
to, że dana akcja (na podstawie swojego indywidualnego kontrolera) może wczytać potrzebne jej elementy to nie problem
ale co jeśli 2 lub 3 moduły z kilkudziesiecioma akcjami wczytuja te same helpery (przecież nie będe ich deklarował w każdej akcji, że ma je wczytać) a inne moduły wczytuja inna grupę helperów, js, css.
mam juz zrobione to, że każda akcja ma plik konfiguracyjny, który określa do jakiego jest przypisana layoutu, chcę to efektywnie wykorzystać.
sama nazwa "layout", nie jest dla mnie nazwą konkretnego szablonu (bo rzeczywiśćie dla wszystkich może być nawet taki sam ogólny szablon) tylko nazwą, która ma mi pozwolić wczytać odpowiednią grupę helperów, bibliotek css, js (te których nie wczyta mi kontroler konretnej akcji). zastanawiam się nad takim rozwiązaniem, żeby z każdym "layout" powiązać sobie plik konfiguracyjny z listą tego co ma być wczytane (wtedy miałbym jeden kontroler layoutu) lub drugie rozwiązanie - dla każdego layoutu tworzyć osobny kontroler, który opakuje/udekoruje wynik danej akcji (wygenerowany szablon akcji) w to co trzeba
ja zastanawiam się nad tym jak zorganizować te dodatkowe kontrolery tak, żeby nie powielać za wiele kodu który wczytuje np jakieś helpery albo bilioteki js.
w Symphony widzę, że helpery includowane są bezpośrednio w szablonach (czasai na podstawie jakiś warunków) - tego chcę uniknąć - chciałbym je ładować poziom wyżej w jakimś kontrolerze.
to, że dana akcja (na podstawie swojego indywidualnego kontrolera) może wczytać potrzebne jej elementy to nie problem
ale co jeśli 2 lub 3 moduły z kilkudziesiecioma akcjami wczytuja te same helpery (przecież nie będe ich deklarował w każdej akcji, że ma je wczytać) a inne moduły wczytuja inna grupę helperów, js, css.
mam juz zrobione to, że każda akcja ma plik konfiguracyjny, który określa do jakiego jest przypisana layoutu, chcę to efektywnie wykorzystać.
sama nazwa "layout", nie jest dla mnie nazwą konkretnego szablonu (bo rzeczywiśćie dla wszystkich może być nawet taki sam ogólny szablon) tylko nazwą, która ma mi pozwolić wczytać odpowiednią grupę helperów, bibliotek css, js (te których nie wczyta mi kontroler konretnej akcji). zastanawiam się nad takim rozwiązaniem, żeby z każdym "layout" powiązać sobie plik konfiguracyjny z listą tego co ma być wczytane (wtedy miałbym jeden kontroler layoutu) lub drugie rozwiązanie - dla każdego layoutu tworzyć osobny kontroler, który opakuje/udekoruje wynik danej akcji (wygenerowany szablon akcji) w to co trzeba
Szczerze mówiąc, to ja uwazam, że do szablonu pchać można tylko coś generealnego. Tak jak tutaj. Jesli coś nie pasue do wszystkiego to lepiej to zamieścić albo w samej metodzie kontrolera poprzez dołączanie, albo jesli jest to coś wspólnego dla wszystkich metod kontrolera, to walę to w jego konstruktorze już. Ogólnie jednak najczęściej bywa tak, że coś takiego jak style lub pliki JS dołączane są w razie zapotrzebowania i faktycznie lepiej mieć do tego jakiś helper, by sobie tylko walnąć add::js(url) lub add::css(url).
Dlatego myślę, że nC jaką znasz a dołączanie plików "zwal" na najbardziej generalizujący stopień zagłebienia. Plik dołączany do wszystkiego (choćby główny plik stylu serwisu) - pchaj do szablonu bazowego, plik dołączany w danym kontrolerze dla wszystkich metod/akcji - wal w konstruktor. Tylko dla danej akcji kontrolera - dołączaj dopiero w tej metodzie. Tutaj jakiś helper byłby już przydatny. Najlepiej własnie taki, który niezależnie od miejsca wywołania uzupełni sekcję head (czy tuż przed zamknięciem body - optymalizacja skryptów) o element podany w argumencie.
Dlatego myślę, że nC jaką znasz a dołączanie plików "zwal" na najbardziej generalizujący stopień zagłebienia. Plik dołączany do wszystkiego (choćby główny plik stylu serwisu) - pchaj do szablonu bazowego, plik dołączany w danym kontrolerze dla wszystkich metod/akcji - wal w konstruktor. Tylko dla danej akcji kontrolera - dołączaj dopiero w tej metodzie. Tutaj jakiś helper byłby już przydatny. Najlepiej własnie taki, który niezależnie od miejsca wywołania uzupełni sekcję head (czy tuż przed zamknięciem body - optymalizacja skryptów) o element podany w argumencie.
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.