Będe tu zamieszczał pytania odnoscie działania FW, oraz róznych kruczków
Pierwsze z nich to pobieranie aktualnej akcji i modułu. Moge to zrobić pobierając z adresu w Kontrolerze module oraz action. Jesli wartosci sa puste podstawiamy domyslne. Bułka z masłem. Jednak co jesli rozszerzymy funkcjonalnosc o znaną funkcje forward()? Przekierowywuje ona do innego modułu i/lub akcji bez zmiany parametrów w adresie. I co teraz? W adresie mamy dane dotyczącego poprzedniej akcji, wiec pobieranie z adresu nie ma sensu. W tym wypadku odpada pobieranie z adresu. Jak to najlepiej rozwiązać? Jak wy to widzicie

EDIT: Zmieniłem nazwe tematu, na bardziej adekwatny

W moim frameworku mam to tak rozwiązane, że każdy widok/akcja może być odpalony z parametrami. ..zatem dla przykladu w akcji, ktora utworzyla nowy news:

[PHP] pobierz, plaintext 
<?php
 
function Execute()
{
   [...]
   // kod wewnatrz akcji
   // $rek['ID'] - id ostatniego newsa
   $this->setNext('NewsPlus', 'NewsPlusShow', array('newsPlusShow'=>$rek['ID'], 'saved'=>true));
   return true;
}
 
?>
[PHP] pobierz, plaintext 

..normalnie widok NewsPlusShow odpalam z parametrem get newsPlusShow zwierajacym ID rekordu, ktory chce pokazac Tutaj wywoluje ja z parametrem wewnetrznym.. a co robie w samym widoku?

[PHP] pobierz, plaintext 
<?php
function Display()
{
 
   $idNews = $this->getParam('newsPlusShow', array('get','action'), 'Integer'); // pobieramy ID
   $saved = $this->getParam('saved', 'action', 'Integer'); // dzieki temu moge potem to .tpl przekazac informacje, ze trzeba wyswietlic komun
ikat o nowoutworzonym news
}
?>
[PHP] pobierz, plaintext 

..dzięki temu w widoku nie obchodzi mnie skąd parametr przyszedł i czemu widok został odpalony (bezpośrednio przez Router, czy w wyniku odpalenia jakiejś innej akcji). Oprócz 'get' i 'action' metoda getParam obsługuje mi też 'post'.

W sumie teraz się zorientowałem, że nie do końca na tym polega Twój problem. Tobie chodzi o tzw łańcuchy akcji. Rozwiązałem to u siebie podobnie jak to zrobił Hawk w swoim Phiend (przynajmniej w Phiend 1 tak było..). Pierwsza akcja jest odpalana rzeczywiście przez router, lecz następne są odpalane jako wynik działania akcji/widoku poprzedniego. Jeżeli nie ma w kolejce żadnych akcji/widoku, to wyświetlam to, co się nazbierało w moim obiekcie Response. Ustawianie następnej akcji odbywa się za pomocą setNext (tak, jak powyżej to pokazałem), które dodaje do kolejki w kontrolerze - posiadam jeden, centralny kontroler w swojej implementacji MVC.

Może to w czymś Tobie pomoże ;>)

Pozdrawiam

A co gdyby przenieść sterowanie z kodu do... pliku XML? Spotkałem przykład w książce i zaimportowałem sobie ideę.
Wg. mnie łańcuchy akcji to jedna z bardziej skomplikowanych rzeczy w FW. Przywykłem już patrzeć na akcje jako na uczestników pewnego bardzo rozproszonego systemu.

Moja definicja akcji.
Akcja to podstawowa jednostka w systemie odpowiadająca za wykonanie określonego zadania (model) przy użyciu dostępnych jej bibliotek i funkcji. Wyrózniam dwa podstawowe typy akcji (chyba nie tylko ja):
- prosta
- złożona (kompozyt)

Akcja złożona może składać się z innych akcji wywoływanych w łańcuchu i korzystać z wyników pracy tych akcji. Jej ciało może zostać wykonane na początku łańcucha, na jego końcu (częstszy przypadek) lub po dowolnej z subakcji. Subakcje są wywoływane w pętli przez kontroler i powinny być tak poskładane, żeby w żaden sposób nie mogły doprowadzić systemu do upadku.
Akcja może też przekazać działanie do innej akcji (forward), ale nie sama, a za pośrednictwem kontrolera. Sama ustawia jedynie swój status, który odczytany przez kontroler umożliwia uruchomienie (np. przez header()) kolejnej akcji. Akcja wywołana funkcją forward nie jest częścią łańcucha akcji i stanowi niejako jego przerwanie.
Celem istnienia akcji złożonych jest ponowne wykorzystanie istniejącego kodu poprzez użycie go w niezmienionej formie w innym kontekście. Uff : P

Sorry, że jest tak mądrze napisane, ale może komuś się przyda. Wg. mnie, właśnie to jest esencja wszystkich frameworków - organizacja pracy z kodem i styl programowania. Jako, że aktualnie piszę takie cóś (idzie jak krew z nosa), pozwoliłem sobie na podsumowanie dotychczasowych przemyśleń.

Pozdrawiam.

@Cysiaczek: Zgadzam sie z Toba, ale chyba nie do konca. Nie wiem czy dobrze zrozumiałem twoją definicje forward() Wydaje mi sie ze pomyliłeś z redirect() (głownie przez tenheader()), aczkolwiek moge sie mylić A wracając do mojego pierwszego rozwiązania. Wyznaje zasade uproszczenia sobie działań, nawet jesli nie wygląda to profesjonalnie, ważne ze skutecznie i prosto. A o to w koncu w programowaniu chodzi. Do pobierania służą funkcje wbudowane w kontroler. W najczestrzym wypadku tak jak opisałem pobierają one dane na podstawie Routera. Jesli jednak uzyjemy funkcji forward() to w jej ciele ustawiamy recznie akcje. Moze przyklad to lepiej opisze niz moje słowa

[PHP] pobierz, plaintext 
<?php
public static function getModule( $sModule = null )
	{
		if( $sModule == null )	
		{
			$aUrl = Router::decodeUrl();
			if( !isset( $aUrl['module'] ) )
			{
				return _DEF_MODULE;
			}
			else
			{
			  return $aUrl['module'];		
			}	
		}
		else
		{
			return $sModule;
		}
	}
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
public function forward( $sAction, $sModule = null )
	{
		Controller::getAction( $sAction );
		Controller::getModule( $sModule );		
	}
?>
[PHP] pobierz, plaintext 

Przez forward rozumiem uruchomienie innego łańcucha akcji. Ok. za mnie niech przemówi XML : )

[XML] pobierz, plaintext 
<index>
      <status>
            <ok>
                  <view>index</view>
            </ok>
            <error>
                  <forward>error</forward>
            </error>
      </status>
 
      <subactions>
            <news />
            <menu />
      </subactions>
</index>
 
<news>
      <status>
            <ok>
                  <view>news</view>
            </ok>
            <error>
                  <view>error</view>
            </error>
      </status>
</news>
 
<menu>
      <status>
            <ok>
                  <view>listmenu</view>
            </ok>
            <error>
                  <view>error</view>
            </error>
      </status>
 
</menu>
 
 
<error>
      <status>
            <ok>
                  <view>ErrorPage</view>
            </ok>
            <error>
                  <exit>Blad krytyczny</exit>
            </error>
      </status>
 
      <subactions>
            <logError />
            <sendNotify />
      </subactions>
</error>
[XML] pobierz, plaintext 

W powyższym przykładzie wywołując akcję index wywołujemy subakcje
<news />
<menu />
W razie powodzenia zostaną wybrane odpwiednie widoki i system jakoś sobie dalej poradzi. W razie błędu kontroler uruchomi nowy łańcuch, czyli akcję <error />. To, czy zrobi to przez header, czy nie, jest kwestią drugorzędną. Faktycznie można uznać, że mój forward to coś w rodzaju redirect i chyba można stosować zamiennie ta nazwę : )
powyższy przykład nie uwzględnia oczywiście modułów (bo i po co - to przykład)
Twoja metoda forward() to u mnie ekwiwalent execute(). Akcja go nie ustawia.
Jeszcze pokażę akcję.

[PHP] pobierz, plaintext 
<?php
class Index extends Action {
 
public function Perform(){
$test=1;
// tak poglądowo
$this->aVars['tekst']="jakiś tekst";
$this->aVars['lista']=$array;
 
if ($test==1){
$this->setStatus("ok");
}
else {
$this->setStatus("error");
}
 
}
 
}
?>
[PHP] pobierz, plaintext 

Pozdrawiam

Kod który przedstawiłem dla funkcjiforward jest szczątkowy. Chodzi tylko o ukazanie głownego problemu jakim jest "dobieranie" sie do informacji jaki jest aktualny moduł i akcja Forward własciwie jest tylko funkcją dostępową do zmiennych prywatnych Ustawia on odpowiednie zmienne w klasie i metoda executeAction wywołuje akcje i nastepnie widok dla tej akcji. Całośc znajduje sie w klasie AppController. Tak więc mamy: Controller -> AppController->View && Action. Tak to wygląda w uproszczeniu.

Ciekawie prezentuje sie to drzewo xml. Mogłbyś napisać coś wiecej

Zastanawia mnie jeszcze jedno pytanie. Jak najskuteczniej wywołać kilka akcji wraz z widokami w jednej akcji? Troche namieszałem. Dajmy przyklad:

[PHP] pobierz, plaintext 
<?php
class DefaultAction extends View
{
	public function Index()
	{
		$this->newModel( 'Index', 'Test');
		$this->newModel( 'Info', 'Modul');
	}
}
?>
[PHP] pobierz, plaintext 

Najspierw wywołujemy akcje Index() w module Default. W tej akcji wywołujemy 2 nowe akcje. Czyli wywołując jedną akcje otrzymujemy ich aż 3. Kiedyś sie nad tym męczyłem jak tworzyłem CMSa, ale nic ciekawego nie wymysliłem. Teraz po przejsciu na OOP chce to już rozwiązać. Przydatne jest to w sytuacji kiedy mamy moduł newsy oraz moduł komentarze. Wywołujemy akcje showNews i w tejże akcji wywołujemy akcje ShowComments z Modułu komentarze. Oczywiscie mozna przekazywać parametry do akcji ShowComments z wnetrza ShowNews takie jak id komentarza itp. Na przeszkodzie stoi mi tylko połączenie wyświetlania szablonów. Bo jest to zrobione, że mamy głowny szablon strony z całym szkieletem w którym jest $this->LoadView(). LoadView załaduje nam podszablon dla danej akcji i modułu. Wszystko działa bardzo ładnie dla pojedynczego wywołania akcji bądź dla forward. Natomiast nie wiem jak to rozwiązać dla większej ilości.
[EDIT] Męcze sie już nad tym pare godzin, aby wywołać klilka akcji w jednej. Prawie mi sie udało, tylko jest jeden problem. Nie wiem jak "złączyć" akcje z widokiem w taki sposób aby widok mógł sie odwołać tylko do zmiennych z jego akcji. Bo w tym do czego doszedłem, widok "gubi" $this. Czy jest jakiś sposób aby "połączyć" obiekty? Przyklad:

[PHP] pobierz, plaintext 
<?php
$o = new Obiekt1
$o->funkcja();
 
$o = new Obiekt2; //Zeby Obiekt2 "dołączył" sie do Obiekt1
$o->Innafunkcja();
?>
[PHP] pobierz, plaintext 

Jest coś podobnego mozliwe? Albo może kto ma jakiś złoty środek? Ja juz nie mam pomysłow

Najlepszy moim zdaniem (ale do średnich i dużych) projektów jest wzorzec two-step-view, który zakłada najpierw rendering mniejszych widoków, a potem ich połączenie w całość.
Jeśli spojrzysz na XML, który dałem wyżej, to zobaczysz znaczniki <view>nazwa</view>. To są właśnie widoki, które będą renderowane. W tym drzewie pominąłem część znaczników, więc nie ma np, znacznika <viewFrame>nazwa</viewFrame>, który jeśli akcja jest wywoływana żądaniem (nie jest subakcją), stanowi schemat łączenia poszczególnych mniejszych widoków. W prezentowanym przykładzie, jeśli wszystko pójdzie dobrze, to akcja Index będzie miała do dyspozycji aż 3 widoki
news.tpl
menulist.tpl
index.tpl

oraz schemat łaczenia index.frame.tpl

news.tpl (pseudo-kod)

[PHP] pobierz, plaintext 
<? print $news['title']; ?>
<br>
<? print $news['body']; ?>
[PHP] pobierz, plaintext 

index.frame.tpl

[PHP] pobierz, plaintext 
<html>
<head></head>
<body>
<div>
<? AHelper->get("menu"); ?>
</div>
<div>
<? AHelper->get("news"); ?>
</div>
</body>
</html>
[PHP] pobierz, plaintext 

Metoda get() przyjmuje jako parametr nazwę akcji i dołącza aktualny widok tej akcji (wybrany przez kontroler na podstawie statusu zgłoszonego przez akcję) z pliku XML. Oczywiście każdy widok ma dostęp tylko do danych, które wygenerowała jego akcja (wewnątrz metody get()). Wydaje mi się, że właśnie o taki złącznik Ci chodzi, tak?

Pozdrawiam.

Nie wiem czy sie rozumiemy do konca.
Widok jest podzielony na szablon głowny:

[PHP] pobierz, plaintext 
Witamy na stronie Sparkle Works :)<hr><br>
 
<?php
$this->loadModuleView();
?>
 
<br><br><br><br><br><br>
<hr>
Powered by Sparkle
[PHP] pobierz, plaintext 

oraz Szablon akcji. Metoda loadModuleView() to poprostu include('szablonAkcji.php); I to nad czym sie aktualnie męcze to jak zrobić aby przy wywołaniu Akcji ShowNews jednoczesnie wywołać ShowComments, bez ingerencji w głowny szablon. Kawałek kodu z AppController:

[PHP] pobierz, plaintext 
<?php
public function executeAction( $sAction, $sModule, $a = '' )
	{
		//echo 'Action'. $sModule;
		$sTempModule = $sModule.'Action';
		$this->oModule = new $sTempModule;
		$this->oModule->$sAction();
 
		$t = $this->s($this->oModule, $sAction, $sModule);
 
		if(is_array(self::$om))
		{
			include(_SPARKLE_PATH.'/app/'._SPARKLE_APP.'/modules/'.self::$om['mod'].'/action/Actions.class.php');
			$this->oModules = new TestAction;
			$this->oModules->Index();
		}
$this->oModule->loadAppView($this->oModule);
//echo self::$om;
	}
 
	public function newModel( $sAction, $sModule = null )
	{
		include(_SPARKLE_PATH.'/app/'._SPARKLE_APP.'/modules/Test/action/Actions.class.php');		
		$o = new TestAction;
		$o->Index();
		//$this->s($o, $sAction, $sModule);
	}
?>
[PHP] pobierz, plaintext 

Nie przejmujcie sie bałaganem, gdyż to tylko testy I wszystko jest prawie pwisane na sztywno. Plik Action wyglada tak:

[PHP] pobierz, plaintext 
<?php
class DefaultAction extends View
{
	public function Index()
	{
		$this->d = 'sssssdszzzzzzzzzzzzzzz<br>';
		//$this->test = 'duuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuupa';
		//echo '<br>ddddddddddddddddddddddddddddddddddddd';
		$this->newModel( 'Index', 'Test');
	}
}
?>
[PHP] pobierz, plaintext 

I to własnie on jest wywołany w przegladarce. Wenatrz akcji index wywołujemy moduł Test, z akcją Index. To jakoś działa. Tylko niestety wszystko sie pipeprzy w

[PHP] pobierz, plaintext 
<?php
$this->oModule->loadAppView($this->oModule);
?>
[PHP] pobierz, plaintext 

Przez takie wywołanie gubie referencje w szablonie do Obiektu $this->oModules. I wszelkie zmienne zadeklarowane w Module test w akcji index, nie zostaną wyswietlone w szablonie. Jak temu zaradzić?

Wprowadź obiekt kolekcji uruchamianych modułów. Przy próbie inicjalizacji nowego modułu, referencję wywołującego umieść najpierw w kolekcji, a dopiero potem wywołaj nowy.

[PHP] pobierz, plaintext 
<?php
$collection->registerModule($this);
$this->newModel( 'Index', 'Test');
?>
[PHP] pobierz, plaintext 

Potem jak potrzebujesz danych z modułu, to pobieraj go z kolekcji.

[PHP] pobierz, plaintext 
<?php
$module=$collection->getModule($moduleName);
// albo konkretnie
$this->oModule->loadAppView($collection->getModule($this->oModule));
?>
[PHP] pobierz, plaintext 

Pozdrawiam.

Nie za bardzo rozumiem. Obiekt kolekcji? Co to

Obiekt, który coś przechowuje i pozwala na przeglądanie tego oraz zarządzanie itp. W najprostszym przypadku może to być tablica, ale obiekt daje więcej możliwości.

Pozdrawiam.

Czyli na polskie tłumacząc napisz sobie rejestr ;]
Co do widoków używam ten wzorzec co podał Cysiaczek proste i wygodne ;] .

Ufff....
Już sie uporałem, bez rejestru Troche pokombinowałem z referencjami do obiektów i działa
Narazie to tylko światełko w tunelu, bo większość rzeczy wpisałem na sztywno, ale to już poprawki kosmetyczne Aby nie myliły sie zmienne w szablonach, tzn aby nie została wykorzystana przez przypadek zmienna z akcji pierwszej w szablonie drugim zrobiłem małe myku Tzn. Zamiast w szablonach odwolywac sie do zmiennych przez

[PHP] pobierz, plaintext 
<?php
$this->zmienna
?>
[PHP] pobierz, plaintext 

robimy tak:

[PHP] pobierz, plaintext 
<?php
$NazwaModulu->zmienna
?>
[PHP] pobierz, plaintext 

W ten sposób mamy wszystko odzzielone w szablonach. Natomiast w akcjach uzywamy normalnie $this->zmienna Jednak mój sukces nie kończy dyskusji

Turgon: Mógłbys troche szerzej opisać ten "wasz" wzorzec widoków

Tzn. tak ;]

Np. mam newsy i podpinam tam obiekt view. Renderuje sobie do zmiennej po kolei każdego. Podaje je szablonowi newses, który je listuje i znowu do zmiennej. Potem ta zmienna dopiero wędruje do szablonu index i tam jest wyświetlana razem z nim.

Czyli zawartość szablonu news wczytujesz do zmiennej zamiast includowac szablon? Zgadza sie?

Tak ;] To jest wygodne i szybkie Tak jest np. w CI

Ja z kolei includuję : )

Wygodne to napewno Ale czy szybkie... Include szybsze

menic: Bez różnicy ;] Sprawa gustu przedewszystkim

W praktyce, podejrzewam jest niewielka róznica jesli chodzi o wydajność. Ale jeśli chodzi o wygode to jak najbardziej. Gdybym u siebie tak zrobił to nie męczyłbym sie tyle z ładowaniem akcji itp. Ale no wlasnie... Kwestia gustu
A co do moich akcji i widoków to już chyba skonczyłem skończyłem Właściwie zrobiony jest już cały Controller, AppController, oraz View. Sporo sie męczyłem z forward'em i załadowaniem akcji w akcji, ale w koncu sie udało. Było warto poświęcic tyle czasu. Mam tylko nadzieje, że nie odbije sie to negatywnie na zaliczeniach, które mam w tym tygodniu

Witam, zaprezentuje moje rozwiązanie tego problemu

posiadam plik konfiguracyjny bloków np:

[XML] pobierz, plaintext 
<block>
<default>
    <layout>index.tpl<layout>
    <blocks>
         <main controller="index" action="index" />
         <info controller="index" action="info" />
    </blocks>
</default>
<login>
    <layout>login.tpl<layout>
    <blocks>
         <main controller="login" action="index" />
    </blocks>
</login>
</block>
[XML] pobierz, plaintext 

default - są zdefiniowane domyślnie odpalane bloki i szablon który ma je wykorzystać
login - jak wyżej ..

z odpaleniem default nie ma problemu ( odpalany domyślnie ) ale teraz jak odpalić login otóż posiadam aliasy na rutera które definiują w sobie odpalane bloki przykład pliku konfiguracyjnego aliasów
w szablonie wykorzystuje je w następujący sposób

[XML] pobierz, plaintext 
<alias>
    <login controller="logowanie" action="main" block="login"/>
<alias>
[XML] pobierz, plaintext 

w kontrolerze definiuje "łapanie" bloków poprzez metode setBlock() np.

[PHP] pobierz, plaintext 
<?php
class indexAction extends AController
{
	  public function index(){
			$view = $this->getView();
			$this->setBlock('main', $view->parse('index/main.tpl');
	  }
 
	  public function info(){
			$view = $this->getView();
			$view->infoMSG = 'jakaś informacja';
			$this->setBlock('info', $view->parse('index/info.tpl');
	  }
}
 
class logowanieAction extends AController
{
	  public function main(){
			$view = $this->getView();
			$this->setBlock('main', $view->parse('logowanie/main.tpl');
	  }
}
?>
[PHP] pobierz, plaintext 

i wykorzystuje je w szablonie głównym poprzez taką linijkę

[PHP] pobierz, plaintext 
<?php print $this->block->main?>
[PHP] pobierz, plaintext 

... mam nadzieje że przedstawiłem to w miare zrozumiale ..

PS1. moim zdaniem definiowanie odpalanych bloków w akcji jest delikatnie chybione, bo gdy chcemy wzbogacić widoko jakieś dodatkowe bloki trzeba przeszukać klasy akcji i je zmodyfikować, a trzymając to w jednym nie pogubimy się przy większych projektach ..

PS2. można też zrobić pomocnika dla widoku który odpala odpowiednie akcje tj ..

[PHP] pobierz, plaintext 
<?php print $this->block->run('index', 'main');?>
[PHP] pobierz, plaintext 

wtedy zabawa nie jest już tak hardkorowa z plikami konfiguracyjnymi ... ale czy jest to zgodne z MVC co o tym sądzicie ..

Szczerze? Nie rozumiem o czym piszesz Co masz pod pojęciem bloki. Bo dla mnie to kawałek kodu php i html umieszczane w glownym layoucie strony, raczej nie mający powiązań z akcjami.

u mnie bloki są wynikiem akcji ..

Po sparsowaniu xml'a (z poprzedniego postu) mam tablice, która zawiera nazwy bloków z kontrolerem i akcją do odpalenia. Wrzucam to do ActionChain i ruszam z tym w FrontControllerze razem z wynikiem rutera.
Każda z odpalonych akcji umieszcza swój wynik w odpowiednim bloku poprzez

[PHP] pobierz, plaintext 
<?php
$this->setBlock('mojBlok', 'trescBloku');
?>
[PHP] pobierz, plaintext 

teraz tak zcachowany widok akcji wywalam do szablonu poprzez

[PHP] pobierz, plaintext 
<?php
print $this->block->mojBlock;
?>
[PHP] pobierz, plaintext 

Mam nadzieje ze sprostowałem nazwe "bloki" w moim FW ..
Ps. rzeczywiście delikatnie odskoczyłem od wątku ... jednak jedną akcja z url'a np. index.php/news/show/2 jestem w stanie jednocześnie odpalić akcje komentarzy do tej akcji i bez problemowo połączyć je w jednym szablonie ..

jak za bardzo namieszałem w wątku z góry przepraszam

Pozdrawiam
widmogrod

Smieszne masz nazewnictwo wszystkiego. U mnie sa tylko dwa kontrolery: Controller oraz AppController. Ten pierwszy znany jest jako FrontController. Dalej jest moduł i akcja z widokiem. U ciebie kazdy moj moduł to jest nowy kontroler :roll2: Ale wracajac do tematu...
Ja nie musze nic edytować, dopisywac do szablonu. Nic z tych rzeczy. Kazdy kazda akcja modułu ma swoj tpl które są ładowane do głownego tpl

[PHP] pobierz, plaintext 
<h1>Witamy na stronie Sparkle Works :)</h1><hr><br>
<pre>
</pre>
 
<?php
$this->loadModuleView();
?>
<br><br><br><br><br><br>
<hr>
Powered by Sparkle
[PHP] pobierz, plaintext 

Kazdy wynik akcji bedzie w loadModuleView().
Natomiast w samej akcji moge zrobić nawet cos takiego:

[PHP] pobierz, plaintext 
<?php
class DefaultAction extends View
{
	public function Index()
	{
		//$this->redirect( 'Show', 'News', Array( 'type' => 'get', 'id' => 77 ) );		
		//echo 'forward<br>';
		$this->forward('Show', 'Default');	//Przekieruje do modułu Default do akcji Show nie wyświetlając wyniku aktualnej akcji	
		$this->newModel( 'Show', 'News' );	//Załaduje akcje Show z modułu News wraz z widokiem	
		$this->newModel( 'Show', 'Test', Array('id' => 77, 'type' => 'get') );	 //Załaduje akcje Show z modułu test wraz z parametrami oraz widokiem
	}
}
?>
[PHP] pobierz, plaintext 

Natomiast jesli forward() damy na koncu to zostaną wykonane wczesniejsze załadowane akcje, ale bez ładowania widoków Tak wiec mozliwosci kombinowania jest dużo I jak zechce to moge odpalic nawet kilka razy ta samą akcje (tylko nie wiem po )

Zwał jak zwał .. funkcje są podobne AForntController - jest to "rozrusznik" zaczyna wszystko i AController - jest to abstrakcja akcji .. u ciebue View, widze ze posiada metode forward() co pasuje mi bardziej do akcji niż do widoku ale to jest kwestia podejścia programisty do projektowania FW i nazewnictwa .. no chyba ze dziedziczony View nie posiada forwarda ... i ma całkiem inne zadanie .. możesz mi powiedzieć jakie cechy ma klasa View?

Powiem ze ciekawe rozwiązanie .. jednak zostane przy swoim .. a zawsze mogę wyposażyć FW w metode

[PHP] pobierz, plaintext 
<?php
$wynik = $this->runAction('controller', 'action', 'params');
?>
[PHP] pobierz, plaintext 

( takie rozwiązanie jest chyba w symfony .. nie jestem 100% pewien .. )

która bedzie mi zwracać wynik akcji z innego kontrollera ect. i później

[PHP] pobierz, plaintext 
<?php
$view->set('main', $wynik);
?>
[PHP] pobierz, plaintext 

i w szablonie

[PHP] pobierz, plaintext 
<?php
print $main;
?>
[PHP] pobierz, plaintext 

i podobny efekt, co o tym sądzisz?

Przyglądam się Waszej i snuje wnioski i pomysły . Wnioski takie mam, że albo lubicie sobie komplikować sprawę albo po prostu 'tak Wam wygodnie'. Oczywiście każdy ma to co lubi i pisze FW dla siebie i pod siebie. Z resztą sam też się w to bawię i więcej mam przyjemności z budowy FW niż z samego korzystania z niego .

Co do wywoływań akcji to akurat ja sobie to zupełnie inaczej obmyśliłem. Wydaje mi się że sporo prościej ale po kolei wytłumaczę. Generalnie jest sobie kontroler. Ma on funkcję statyczną runEvent() z parametrami : jaką klasę i metodę wywołać oraz jakie parametry przesłać do niej. Zwraca to co dana metoda wypluje. Oczywiście sam kontroler ma w sobie mechanizmy sprawdzające czy się wywołania nie zapętlą itp. Ma również obiekty odpowiadające za cache'owanie obiektów akcji (czy jak ja to nazywam 'eventów'), za dane sesji no i za widok.

Metodę runEvent można wywołać z każdego miejsca FW tak więc odpada nam konieczność robienia forward() i martwienia się o to czy można i jak. Dodatkowo daje nam możliwość kontrolowania kazdej akcji z poziomu kontrolera (chyba zamieszałem:) ). Każda klasa obsługująca zdarzenia musi dziedziczyć po bazowej klasie do zdarzeń. Dzięki temu każda z akcji ma możliwość dodania zmiennych wyświetlanych w widoku czy modyfikacji zmiennych sesyjnych. Dopiero później kontroler przekazuje do widoku sterowanie z zebranymi danymi. Jedyne co akcja musi zrobić to zdefiniować nazwę szablony do wyświetlenia i tylko ta akcja która została wywołana z router'a. Dodatkowo mam możliwość zdefiniowania czy daną akcję mogę wywołać przez URL'e czy tylko i wyłącznie przez metodę runEvent.

Jedyne co mnie natchnęliście to muszę się zastanowić czy chcę aby klasy obsługujące zdarzenia miały możliwość definiowania własnych części widoku a nie tylko danych do wyświetlenia.

View dziediczy po AppControlerze, stąd dostepnośc forward. W Klasie View trzymane są metody jak nazwa wskazuje do widoku, takie jak loadModuleView(), loadAppView(), setView() itp. Narazie jeszcze jest nie rozubudowana, gdyz meczyłem sie z kontrolerami

CZy to komplikowanie? W pewnym sensie tak, ale zalezy jak na to pparztec Pisze o głownie dla pożniejszej wygody. Wkurzyło mnie jak pisałem w Symfony, ze w module newsów musze pisac tez moduł komentarzy (wiec po co cała modułowosc?)
U mnie Controller odpowiada tylko za załadowanie odpowiednich plikow i tyle. Reszte przejmuje appController z funkcjiami do ładowania akcji itp. Metoda NewModel() to jest tak jak by nakladka na metode executeAction() z appControllera. Musiałem rozdzielic, bo raczej rzadko sie uzywa newModel wiec bez sensu byłoby to pakowanie do głownej metody wywoławczej
A działanie forward jest takie, ze wykonuje wszystko w danej akcji, lecz nie wyswietla jej wyniku tylko przenosi do innej akcji i tam juz wyswietla wynik tej przeniesionej

@menic - i już wszystko jasne ( ciekawe podejście ) ..

hehe .. z tym sie zgodze

Każdy ma swoje podejście do projektowania i dla mnie takie rozwiązanie jest bardziej przyjemne .. jednak ciągle się rozwijam i kto wie czy za miesiąc nie będę miał nowej wizji rozwiązania tego problemu .. czy też innych

Pozdrawiam
Miłego kodowania