Na początek sory za temat ale nie bardzo wiem jak to nazwać. Nie wiem jak rozwiązać mój problem, a mianowicie mam index i chce zrobić menu (w indexie), ewentualnie część prawą, lewą i jakąś stopkę i tu moje pytanie jak wy to rozwiązujecie w waszych frameworkach. Najbardziej bym chciał mieć np application.Controller.php (w nim zawarte jakieś akacje odnośnie indexu) i inne kontrollery, np news.Controller.php, ogolnie chodzi o to jak includować newsController w applicationController. Ja widze tylko takie rozwiązanie: w odpowiednim miejscu w pliku z szablonem wstawić coś typu



ale takie rozwiązanie nie bardzo mi się podoba, tak samo nie chciałbym dzielić indexu na górną i dolną cześć.\

Pozdrawiam Piotrek.

layout w całość łączymy w widoku ale każdy robi jak lubi w ZF chyba masz ładny foward, przejrzyj dokumentację.

W różnych frameworkach jest to różnie rozwiązane np. (najczęściej spotykany) główny plik widoku tzw. layout gdzie możesz utworzyć szkielet strony (nagłówek, stopka, menu i render widoku z kontrolera). Jeżeli chcesz, by te poszczególne części były dynamiczne (po to zapewne używasz kontrolerów), możesz wtedy skorzystać z helperów/komponentów/apletów (w zależności od nazewnictwa frameworka) widoku.

Tak ja to widzę.

Nie mieszałbym widoku z akcjami. Ja bym to zrobił tak:

Application Controller wybiera akcję, która jest realizowana przez jakieś polecenie, które przygotowuje wszystkie potrzebne dla widoku dane. Po pobraniu treści, wybierany jest widok i przekazywany do niego obiekt kontekstu, który zawiera wszystkie niezbędne dla widoku informacje. Renderujemy widok.

Sam widok jest złożony - do szablonu dołączamy komponenty. Jednym z nich może być menu. Generujemy wszystkie z nich, łączymy w głównym szablonie i zwracamy klientowi.

Warto poczytać o wzorcach projektowych, np. o Composite View.

Czyli w każdym widoku, każdej akcji musimy manualnie, w trakcie tworzenia widoku, dołączać helpery (menu), ewentualnie podwidoki (nagłówek, stopka)?



Ja polecam to

Dzięki Panowie, jak wrócę do domu to się będę z tym bawił i ewentualnie zadawał kolejne pytania

Pozdrawiam.

Można tak zrobić. Jeżeli możesz wyodrębnić wyraźny szkielet widoku, to można utworzyć podstawowy widok, w którym zagnieździmy inne. Wtedy wybór widoku ograniczałby się do wyboru podwidoku... W gruncie rzeczy, jak to zrobisz, to sprawa programisty... Nie ma konkretnego sposobu, są wzorce, które dają ogólny pogląd, jak np. Composite View. Jest widok i są w nim zagnieżdżone elementy, ale implementacja jest sprawą osobistą...

Co do książki, to też mogę polecić... Warto też korzystać z blueprints...

Sa dwa rozwiazania,ktore przychodza mi do glowy i zeby, jak to powiedzial poprzednik, nie wklepywac wywolywania akcji komponentow manualnie. Pierwsze juz opisal Ludvik i mozna je zastosowac jezeli np. komponenty layoutu wystepuja ale moga w ogole nie wystapic.

Drugim rozwiazaniem (moze nawet lepszym, o ile elementy te zawsze wystepuja, ale sa dynamiczne) jest zastosowanie wzorca Intercepting Filter i wykonywanie akcji menu,header,footer jako akcje preprocessing,
a nastepnie przekazanie wynikow wraz z akcja wywolywana do renderowania. Drugi sposob mozna takze wykorzystac, jezeli elementy te nie wystepuja zawsze - nalezy wtedy zastosowac kilka rodzajow filtrow.

Wywoływanie kolejnych kontrolerów w celu dekorowania widoku nie jest złe, ale z pewnością kłopotliwe. Zwykle filter chain jest już zainicjowany a akcja jako taka jest jego ostatnim elementem wiec dorzucanie kolejnych rzeczy wiąże się zawsze z problemami. Na przykład renderowanie dwóch różnych stron może przebiegać w następujący sposób:


Menu jest stałe, ale renderowanie pozostałych elementów zależne od różnych czynników. Aby uzyskać interesujący efekt konieczne byłoby ręczne konfigurowanie łańcucha w każdej akcji, co zdecydowanie wygodne nie będzie.

W Agavi, Symfony, Mojavi 4 i inne frameworki, które wywodzą się z Mojavi 2/3 a mają wyodrębnioną obsługę widoków wspierają forwardowanie akcji oraz, jak mi się wydaje, rozwiązanie Twojego problemu - mianowicie layouty.

Wygląda to tak, że definiuje się układ, komponenty, które wchodzą w jego skład (menu, stopka, jakieś dodatkowe bloki) i nadaje mu nazwę - powiedzmy "front", "admin", "product", "category" i tak dalej. Każdy z nich różni się przy produktach dorzucamy od razu komentarze i galerię. W widoku danej akcji wystarczy wywołać metodę setLayout(nazwa) by zmienić układ. W sloty wskoczą wyniki wykonywania danych akcji.
Logika bez zmian, widok bardziej elastyczny a i jego zmiany nie wpływają na warstwę biznesową.

Forwardy są przeznaczone do wpięcia pewnego fragmentu uniwersalnej logiki - takich sytuacji jest tak na prawdę niewiele, ponieważ jeśli coś powtarza się często, powiedzmy logowanie operacji wygodniej jest to wrzucić do filtru, zatem forwardy głównie sprowadzają się do zrobienia redirecta, stąd w Agavi od wersji 0.11 forwardy nie są dostępne, w ich miejsce można robić "mini forwardy" na widoki.