Witam.

Po raz kolejny pytanie dotyczące MVC - tym razem chodzi mi o fakt kiedy na stronie mamy jakieś stałe elementy - czy każdy widok musi je generować z osobna i za każdym razem uzywajac systmu szablonów przypisywać jakieś wartości dla nagłówka, stopki, stałego menu - itd itd.

Tak naprawdę akcje decydują u mnie o tym co się wyświetla w głównej części serwisu i chciałbym żeby stałe elementy były wyświetlane wyłącznie w jednym pliku, a takze uruchamiany kontroler ktory zdecyduje co wygenerowac dla glownej czesci serwisu.

Czy to ma prawo bytu? Jezeli nie - jak najlatwiej rozwiazac ten problem - licze na wasze jak zawsze dobre pomysly.

pozdrowka

anas

Nie do końca rozumiem o co tobie chodzi, lecz możesz zawsze użyć cachoe'owania - jeśli używasz Smarty możesz z powodzeniem cachoe'ować tylko niektóre elementy template'ów.

Hej.

Co do cashowania to jasna sprawa - chodzi mi raczej o fakt iż mam serwis www, a w nim naglowek, stopke, menu z lewej strony - ktorej na kazdej podstronie wygladaja tak samo - zmienia sie czesc glowna serwisu(srodek) - tym ma zarzadzac wlasnie moja aplikacja oparta o MVC - ale nie chce tez rozdzielac jednego od drugiego - to co chcialbym osiagnac to taki defaultowy widok do ktorego dolaczane bylyby widoki wywolywane przez jakies tam akcje. A pytanie moje brzmi jak to zrobic - bo sama idee mam - gozej z implementacja... nie wiem od ktorej strony sie do tego zabrac.

pozdrawiam

anas

To czego chcesz przypomina zalążek mojego frameworka - zakładając że używasz Smarty, robisz sobie jednego template'a - nazwijmy go index.tpl.
I teraz robisz tak, że w każdej akcji definiujesz zmienną template'ową "page" - używając:

[PHP] pobierz, plaintext 
<?php
 $objSmarty->assign('page', 'id-strony-do-wyswietlenia');
?>
[PHP] pobierz, plaintext 

A w templacie, na początku:

[HTML] pobierz, plaintext 
{include file="$page.tpl" assign="zawartosc-templatu-podstrony"}
[HTML] pobierz, plaintext 

Dalej w templacie, już po zdefinowaniu headera, menu, itp, wyświetlasz zainkludowany środek strony, pisząc:

[HTML] pobierz, plaintext 
{$zawartosc-templatu-podstrony}
[HTML] pobierz, plaintext 

ja mam w plikui konfiguracyjnym sekcje preLoadingActions i postLoadingActions które zawierają nazwy akcji które mają być wykonane przed wywołaniem właściwej akcji i po.

olo twoje rozwiązanie też jest jeśli reszta strony ma być niestatyczna. Można w sumie też mieć akcję bazową, w której wykonujemy wszystkie czynności które mają zostać wykonane na każdej stronie, a wszystkie inne akcje extend'ują od niej.

@bregovic - tak tez zrobilem - popatrzylem i w phiend jest to rozwiazane wlasnie tak jak mowiles - klasa akcji bazowej, a po niej dziedzicznone pozostale klasy... sprytne rozwiazanie.

@olo - tez nieglupi pomysl - tylko martwi mnie fakt iz zmuszasz aplikacje do wywolanie czegos na stale - chociaz jak kto woli

Ps. a jak sie ma sprawa wydajnosci - moze testowaliscie co dziala szybciej - dziedziczenie po akcji bazowej czy taka sama akcja ktora ma przedakcje i akcje wywolywane po czesci glownej.

pozdrowka

anas

albo można zrobić tak: dla każdej akcji masz zdefiniowane kiedy ma być odpanala (jaki argument GET ma być) i robisz tam always - czyli zawsze. tylko nie wiem za bardzo jak zdefiniować kolejność wyświetlania poszczególnych elementów.

moze na chama zserializowac tablice i do sesji wrzucic

ja standardowo wykorzystuję dziedziczenie po róznych rodzajach akcji.
Jest to bardzo przydatne, bo można np. tylko raz zdefiniować, co ma być wykonywane na np. stronie z wydrukiem, (np. nie drukuje menu, wiec nie muszę go generować)

Następnie wszystkie akcje związane z wydrukiem dziedziczą po tejże, i odpowiednio ją rozszeżają.

Czasem można ten proces skomplikowac jeszcze bardziej. Jakiś przykład?
Sonda wyświetlana jest na głownej stronie, gdzie jest menu boczne i górne. Nie ma jednak innych dynamicznych elementów.
dziedziczy wiec po abstrakcyjnej pseudo akcji "strona głowna" "wyłączają" w niej pewne bloki.
A teraz pojawia się akcja OddajGłos ... Wyświetlana oczywiście w takim samym "środowskiu" . Wystarczy więc dziedziczyć z sondy, dodając tylko odpowiednie mechanizmy.

Oczywiśćie konieczna jest bardzo duża ostrożność, by nie zgbubić się w tych związkach, ale w wielu przypadkach może to znacznie ułatwić życie.

@DeyV:
Tak tez to rozwiazuje - wlasnie sie tym zajalem i all dziala jak nalezy - jak dla mnie najbardziej przejrzysty i sprawdzony sposob

Thx za tyle ciekawych propozycji... ide dalej meczyc klawiature.

pozdrowka

anas

DeyV: możesz to pokazać na jakimś prostym przykładzie bo próbuję, ale nie mogę skumać Tzn mniej więcej kumam ale jakoś nie mogę wpaść jak to elegancko rozwiązać - same badziewiacke rozwiązania przychodzą na myśl... za dużo tej marychy...

Pozwolę sobie przedstawić moje rozwiązanie.
Moja koncepcja była bardzo prosta, mianowicie są elementy strony, które mogą się zmieniać (np. pojawiające się menu dostępne tylko dla zalogowanych osób ). Jako, że korzystam jak narazie tyko ze zwykłego widoku html obsługiwanego przez smarty dodałem tablicę zawierającą pliki do wywołania pod koniec tworzenia strony.
Przykładowy blok:

[PHP] pobierz, plaintext 
<?php
class LoginForm
{
	function LoginForm( ) { }
	function run( ) {
		$reg = &Registry::instance( );
		$view = &$reg->load( 'view' );
		$io = &IO::instance( );
		if(	$io->getSession( 'user_id' ) > 0 ) { //zalogowany
			$model = Init::model( 'user_model' );
			$data = $model->getUserById( $io->getSession( 'user_id' ) );
			$view->assign( 'username', $data['login'] );
			$view->assign( 'login_form', $view->fetch( 'logined.tpl' ) );
		} else { //gość
			$view->assign( 'login_form', $view->fetch( 'login_form.tpl' ) );
		}
 
	}
 
}
 
?>
[PHP] pobierz, plaintext 

Oczywiście można łatwo dodać kolejne elementy do szablonu i jeśli użytkownik jesst zalogowany wyświetlać.
Klasa widoku:

[PHP] pobierz, plaintext 
<?php
class SmartyView {
	var $smarty;
	var $autoLoadBlocks = array( );
 
	function SmartyView( ) {
		$reg = &Registry::instance( );
		$config = $reg->load( 'viewconfig' ); // ładuję ustawienia z rejestru
 
		$this->autoLoadBlocks = $config['autoload']; // domyślne bloki
		unset( $config['name'], $config['autoload'] );
 
		include_once DOCUMENT_ROOT .'libs/smarty/Smarty.class.php';
		$this->smarty = new Smarty; //tworze obiekt
 
		foreach( $config as $key => $value ) { // ustawienia konfiguracyjne
			$this->smarty->$key = $value;
		}
		$reg->save( 'view', $this ); //zapisuje widok w rejestrze
	}
 
	function autoLoad( ) {
		foreach( $this->autoLoadBlocks as $id => $name ){
			$block = Init::block( $name );
			if( $action !== false ){
				$block->run( );
			}
		}
	}
 
	#inne metody
 
	function assign( $key, $value ) {
		$this->smarty->assign( $key, $value );
	}
 
	function fetch( $tpl ) {
		return $this->smarty->fetch( $tpl );
	}
 
	function display( $tpl = null ) {
		if( $tpl === null ) {
			$this->autoLoad( );
			$this->smarty->display( 'home.tpl' );
		} else {
			if( sizeof( $this->autoLoadBlocks ) > 0 ) { // są jakieś bloki
				$this->autoLoad( );
			}
			$this->smarty->display( $tpl );
		}
	}
}
 
?>
[PHP] pobierz, plaintext 

Wycinek z pliku config.php

[PHP] pobierz, plaintext 
<?php
$viewconfig['smarty']['name'] = &#092;"smarty\";
$viewconfig['smarty']['template_dir'] = &#092;"templates/\";
$viewconfig['smarty']['compile_dir'] = &#092;"compiled/\";
$viewconfig['smarty']['config_dir'] = &#092;"tpl/config\";
$viewconfig['smarty']['debugging'] = false;
$viewconfig['smarty']['compile_check'] = true;
 
//bloki ktore beda automatycznie ladowane
$viewconfig['smarty']['autoload'] = 
array(
	'Menu', 'News', 'Hello', 'auction_box', 'login_form'
);
?>
[PHP] pobierz, plaintext 

W zależności od potrzeb akcja może usuwać lub dodawać nowe elementy blokowe. Jeśli serwis jest pod sporym obciążeniem to wtedy można włączyć buforowanie. Myślę, że takie rozwiązanie jest bardzo elastyczne i umożliwia tworzenie nawet bardzo złożonych bloków.

buuuu ;( glowie sie i glowie i nie wiem jak wyglowic.
chce, zeby ustawienia jaki akcje uruchamiac przed i po właściwej akcja byly zapisane w konfiguracji frameworka (czyli plik xml). Chcialbym, zeby to bylo w miare elastycznie, wymyslilem takie sposoby:

[XML] pobierz, plaintext 
<action type="alwaysPre" showId="1"> <!-- showId ustala kolejnosc wyswietlania. wszystko musi byc elastyczne! -->
      <name>main</name>
      <requiredRoles></requireRoles>
      <type>view</type>
      <matches>main</matches>
    </action>
 
<action>
      <name>main</name>
      <requiredRoles></requireRoles>
      <type>view</type>
      <matches>_alwaysPre1</matches> <!-- cyferka oznalcza kolejnosc wyswietlania -->
    </action>
 
<action>
      <name>main</name>
      <requiredRoles></requireRoles>
      <type>view</type>
      <always where="pre" showId="1" />
    </action>
[XML] pobierz, plaintext 

Jednak te wszystkie pomysły wydają się jakieś nie tego teges Any suggestions?

może wzorzec Intercepting Filter

taa juz bo mi to cos mowi

swoja droga przed chwila zdalem sobie sprawe ze popelniam blad. W koncu za wyglad odpowiada warstwa widoku, a ja probuje to rozwiazac w warstwie kontrolera.

Ok zrobilem cos takiego:

[PHP] pobierz, plaintext 
<?php
abstract class StronaGlowna
{
		protected function runPreActions()
		{
				//tutaj odpalamy akcje, ktore powinny byc wyswietlone przed wlasciwa akcja (np header, menu, sonda)
		}
 
		abstract protected function Action(); // akzja bazowa czyli to co wywolujemy
 
		protected function runPostActions()
		{
				// tutaj odpalamy  akcje, ktore powinny byc wyswietlone po wlasciwej akcji (typu stopki albo menu z prawej)
		}
 
		public function Run() // metoda wywolywana przez kontroler
		{
				$this->runPreActions();
				$this->Action();
				$this->runPostActions();
		}
}
 
class someView extends StronaGlowna implements Action
{
		protected function Action()
		{
				// tutaj zapisujemy wlasciwa akcje
		}
}
 
// dorzucam jeszcze interfejs Action (b. prosty)
interface Action
{
		public function Run();
}
 
// akcje wywolujemy poprzez
$objAction = new someView();
$objAction->Run();
?>
[PHP] pobierz, plaintext 

DeyVowi chyba o to chodzilo nie?

Uhm, IMHO nie. DeyV mówił o dziedziczeniu z akcji bazowych, które zawierają kod wyświetlający np. menu. Nie o dziedziczeniu z akcji, które wywołują inne akcje.

Chociaż to drugie też jest możliwe i sensowne. Trzeba jakoś zapanować nad tym, które akcje wymagają wywołania przed/po jakiś innych akcji. To można zrealizować właśnie przez dziedziczenie ze wspólnej akcji bazowej, która zawiera implementację runPreActions i runPostActions.

Oczywiście, to wszystko ma sens przy założeniu, że widok jest typem akcji, i że możemy wywoływać kilka akcji jedna po drugiej. A obie te rzeczy nie są standardowe i nie każdy framework musi to umożliwiać. No ale jak widać są przydatne... tylko w tym momencie to co nazywamy "akcją" staje się coraz mniej akcją w sensie MVC, a raczej, hmm, jednostką kodu/pracy. No problem, tylko można się zakręcić w dyskusji z ortodoksyjnymi znawcami MVC.

PS Ja miałem kiedyś inny sposób, chyba lepszy niż dziedziczenie, bo elastyczny, ale nie pasujący do starej wersji phienda:
W konfiguracji akcji przydałby się dodatkowa informacja: "layout". Taki layout to byłaby klasa, która wyświetlałaby wszystkie stałe elementy, a w środku wynik działania akcji-widoku.

[PHP] pobierz, plaintext 
<?php
class View {
  public function run() {
	//pobierz layout z konfiguracji
	$layout->run($this);
  }
 
  public function display() {
	//tutaj wyświetlamy zawartość
  }
}
 
class Layout {
  public function run($view) {
	//wyświetl header
	$view->display();
	//wyświetl footer
  }
}?>
[PHP] pobierz, plaintext 

Layouty można zmieniać, można dziedziczyć, itd.

no jasne, na pewno te sztuczki z MVC zgodne nie są, tyle że moim TODO jest zrobienie frameworka, który będzie podwalinami do dowolnego portalu.

BTW w tym co mowil DeyV trzeba zauwarzyć, że to menu w akcji bazowej jest po prostu kodem html a u mnie to miejsce ma zająć kolejna akcja.

Z tym ostatnim stwierdzeniem nie mogę się zgodzić.
To "menu" to jakiś dowolnie generowany fragment kodu strony.
W takiej sytuacji potrzebny jest jakiś kod, który pozwoli na pobranie tych danych i przesłanie ich do szablonu.
I tu pojawia się konieczność wydzielenia samodzielnego działu w kodzie - zestawu klas o podobnych możliwościach jak akcje (np. korzystanie z modelu) jednak nie odpalane przez router, a przez zainteresowane nimi konkretne akcje.
Pozwala to na uproszczenie kodu tej akcji bazowej, a zarazem na prostą, modularna obsługe pozostałych elementów.

Możecie wyjaśnić o co chodzi z tą akcją bazową?

Czy to coś w tylu: tworzę sobie akcje BaseAction, która np. zawiera metodę compose(). Metoda compose() odpowiedzialna jest za wygenerowanie nagłówka, menu i stopki. A pozostałe akcje generujące zawartość contentu (środka) dziedziczą po BaseAction?

Jeśli tak to jak rozwiązać problem kolejności ładowania poszczególnych sekcji: nagłówek, menu, stopka? A co jeśli zawartość menu zależy od uprawnień które posiada zalogowany użytkownik? Nie mogę sobie jakoś tego wyobrazić? Może jakiś kodzik?