robiac portal skladajacy sie z roznych modułow: core ( odpowiedzialny za wyswietlenie strony glownej itp ) + galeria + newsy + artykuly itp.... ;]
lepiej jest poslugiwac sie na sztywno metodami statycznymi do pobierania blokow np: strona glowna sklada sie menu + blok ostatnich 10 newsow + blok ostatnich 10 artow i teraz

class IndexContoller extends Zend_Controller_Action

function indexAction() {
$this->view->blockNews = BlockNews::showLastNews( 10 );
$this->view->blockArticles = ArticlesNews::showLastArticles( 10 );
echo $this->view->render('IndexPage.tpl');
}

}

czy lepiej jest w wyswietlic samo
class IndexContoller extends Zend_Controller_Action

function indexAction() {
echo $this->view->render('IndexPage.tpl');
}

}

a w widoku za pomoce plugina $this->_action(....) odwolywac sie to wybranych kontrolerow / akcji

Moim zdaniem lepiej korzystać z pluginu w widoku. Dzięki temu poszczególne akcje stają się bardziej uniwersalne (reusable).

W pierwszym przypadku za bardzo mieszasz logikę widoku z kontrolerem - wyobraź sobie ile akcji byś musiał zmieniać gdybyś w ten sposób dołączał np. menu strony? Od tego jest widok i niech tak zostanie.

czyli wychodzi ze najlepsza metoda na tego typu serwisu jest cos takiego ?

Przykład:
-IndexController
-NowosiController
-GaleriaController
-ArtykulController

(podział na moduły itp odpuscilem - chodzi o sam schemat )

IndexController odpowiedzialny jest za pierwsza strone

----------------------------------------------------------------
| $this->partial('header.tpl'); |
|---------------------------------------------------------------
| | |
| | |
| $this->action( odwolanie do | $this->action( |
| NewsController....) | Menu.... |
|-------------------------------------------- |
| | |
| $this->action(odwoloanie do | |
| ArtykulController....) | |
| | |
| | |
----------------------------------------------------------------

Dokładnie, dodatkowo tą część z headerem i menu (+ np. footer) przeniósłbym do layoutu.

masz przecież modele...

ja bym to zrobił tak

[PHP] pobierz, plaintext 
<?php
/**
 * IndexController - The default controller class
 */
 
require_once 'Zend/Controller/Action.php';
 
class IndexController extends Zend_Controller_Action 
{
	public function indexAction() 
	{
		Zend_Loader::loadClass('NewsModel');
		Zend_Loader::loadClass('ArticleModel');		
		$news = new NewsModel();
		$art = new ArticleModel();
		$this->view->news = $news->fetchAll(null, array('published'=>'DESC'),10);
		$this->view->art = $art->fetchAll(null, array('published'=>'DESC'),10);
	}
}
?>
[PHP] pobierz, plaintext 

i opracowujesz to sobie ładnie w widoku ;-) do tego sugeruję configi w których będziesz przechowywał liczbę pobieranych newsów; drugą dobrą opcją jest plugin + config, aczkolwiek cały render sugeruję już w widoku

tylko chciałbym mieć wieksza 'elastycznosc' aplikacji - tj. na stronie glownej chce miec od box z promocyjnymi towarami to w widoku wstawiam sobie
<div class="box_promocje">{$this->action( PromocjeController ...... )}</div> )
więc jakoś to rozwiązanie z pluginami bardziej do mnie przemawia

a header + footer - faktycznie do Layout ;]

Oczywiście że najlepiej korzystać z helpera widoku 'action'. Powstał on właśnie do tego żeby można było robić opisane przez Ciebie widgety (bloki). Opisany sposób przez ~kosmowariata jest bezsensu bo w takim rozwiązaniu trzeba by przekazywać do widoku w każdej akcji te wszystkie bloki. To już lepiej by było zastosować actionstack i wykonywać równocześnie akcje odpowiedzialne za bloki i przekazywać wyniki do layoutu.

Sabistik: powiedz mi jeszcze tylko jak najrozsadniej zablokowac uzytkownikowi dostanie sie do funkcji odpowiedzialnej za wyswietlanie: box z logowanie ktory bedzie umieszczony layout... bo majac np:

class UzytkownikController {

public function boksLogowaniaAction() {
//... tu cala logika zwiazana ze sprawdzanie czy user logniety czy nie...
//.. tu views/script zostanie 'zrenderowany'
$this->_helper->viewRenderer->setResponseSegment('boksLogowanie');
}

}


strona glowna portalu:
class IndexController {

public function indexAction() {
$this->_helper->layout()->setLayout('indexPage.phtml');
}

}


natomiast glowny layout:
<html>
<head><title>......</title></head>
<body>
superrrrr portal
<?php $this->action('boksLogowania', 'Uzytkownik', null, array() ); ?>
</body>
</html>

ktos może dostac sie do funkcji opdowiedzialnej za wyswietlenie boksa z logowaniem przez www.portal.pl/uzytkownik/boksLogowanie
jedyne co mi przychodzi do glowy to doszukac sie jakiejs metody a obiekcie request ;]

a przy okazji dobrze zrozumialem 'idee' podziału na komponenty ? ;]

Myślę że można sprobować to sprawdzać w stylu:

[PHP] pobierz, plaintext 
<?php
if( Zend_Controller_Front::getInstance()->getRequest()->getControllerName() == $this->getRequest()->getControllerName() ) { 
/* wywal wyjątek, przekieruj... */ 
}
?>
[PHP] pobierz, plaintext 

oki pierwsza implementacja tego sposobu zrobiona ;] troche to dziwnie wyglada jak co kawłek w kodzie $this->action(.....) ;] i nie jestem do konca przekonany ze jest to w 100 % zgodne z ideą mvc ... chociaz w symfony jest 'odpowiednik' tego: http://www.symfony-project.org/book/1_0/07...ayer#Components

Dlaczego miałoby nie być zgodne? Nadal zachowana jest separacja wszystkich 3-ech płaszczyzn. A jednocześnie jest to wygodne.

Nie bądź ślepo zapatrzony we wzorce projektowe - one są po to by ułatwić programiście życie - tzn. jeżeli coś nie jest w 100-tu procentach zgodne z czymś, nie oznacza, że się nie nadaje. Zwracaj uwagę raczej na to czy nie nabruździsz sobie w kodzie nowym rozwiązaniem.

Dodatkowo, nie ma nigdzie jasno opisanych wzorców, a raczej wzorcowych Ich implementacji. Wiele rzeczy można zrobić na milion sposobów, a i tak będzie to samo.

Pozdrawiam, LBO

oki troche moze i za bardzo 'ksiazkowo' staram sie projektowac app ;] ale tak nauczony.. ;] powiedz mi jeszcze tylko czy np: majac koszyk z towarami / czy boks do logowania lepiej wstawiac go przez odwolanie sie do jakiegos kontrolera/akcji za pomoca $this->action() czy stworzyc sobie wlasny helper wstawKoszyk() / wstawLogowanie() i tam pobierajac dane z bazy / sesji wyswietlic to co nalezy ? ;]

Pracując na Agavi nauczyłem się, że najlepiej większość rzeczy opierać o kontrolery/akcje... jest to wygodne

Np, robisz kontroler odpowiedzialny za logowanie i korzystając z narzędzi dostępnych we frameworku ustalasz czy wyświetlić formularz, czy zwykłe "Witaj użytkowniku taki a taki". Wstawiasz to w szablonie i cała reszta z głowy.

Tak samo menu - tworze cały kontroler odpowiedzialny za dodawanie, odejmowanie czy automatyczne pobieranie linków (z cała otoczką administracyjną) a layoucie wstawiam akcje to menu wyświetlającą.
Tylko faktycznie, Zend powinien zrobić jakiś mechanizm ukrywający kontrolery/akcje przed Dispatcherem - bo rozwiazania które tu widziałem nie wydją mi się eleganckie.

@Sabistik - popraw mnie jeśli się mylę, ale helpera tego nie ma w ostatniej stabilnej wersji ZF

najnowsza stabilna wersja została pozbawiona helpera action / komponentu : Zend_Layout ... ale daj gora miesiac jak 1.5 bedzie stable ;]

Mam pytanie, jak w metodze action przekazuje sie zmienne?

manual zamknęli?

[PHP] pobierz, plaintext 
<?php
string  action  (string $action, string $controller, [string $module = null], [ $params = array()])
?>
[PHP] pobierz, plaintext 

ale mi chodzi o to:
<?= $this->action('latestnews', 'index', null, array('count' => 10, 'idNode' => 149)); ?>
czy takie cos jest dobrze?
I jak pozniej taka zmienna pobrac w konkretnej metodzie?

No przecież cały czas o tym rozmawiamy. Do parametrów odwołujesz się jak przy normalnym requestcie.

Ok, dziala