Hej,

Mam takie pytanie, starm sie napisac strone stosujac wzorzec MVC, stosuje przy tm Smarty i Peara ale to nie wazne. Glowny problem dla mnie tkwi w teorii samego rozwiazania. Otoz jesli chodzi o sterowanie kacja to jest niby wszystko dosc proste ale nie wiem czy zalozenie dobrze rozumiem. Wysiwetlenie strony polega na tym ze zmianie ulega tytul, dane ktore pojawiaja sie w dziale content, tlo strony i boczne menu. Nie wiem wiec czy stosowac i pisac osobne akcje dla kolejnych odslon, czy napisac jedna mmetode klasy Controllera, pobierajaca odpowiednie parametry. Nie chce tutaj podawac kodu, ktory juz napisalem, bo jest go dosc sporo, ale powiem tylko ze obecnie lacze klasy modelu, akcji i widoku z instrukcja switch-case w indexie i wlasnie nie wiem czy teoretycznie jest to zgodne z zalozeniami MVC. Dodam ze nie zalezy mi narazie na optymalizacji skryptu a raczej na zglebieniu samej teorii.

Dzieki i pozdrawiam.

Wzorce to nie są sztywne założenia że musi być tak i koniec. Są to ... wzorce. Każdy może implementować je inaczej i właśnie to jest w tym najfajniesze.

Więc weźmy na warsztat MVC. Wzorzec mówi nam o tym że aplikacja dzieli się na trzy warstwy - Model, Widok i Kontroler. Oddzielenie tych warstw od siebie daje nam dużą wygodę, by z biegiem czasu odkrywać kolejne plusy tego rozwiązania. A jak to zaprogramujesz? To już zależy od Ciebie. Ja kiedyś rozwiązałem to bardzo prosto, działało szybko i prosto. Mianowicie aplikacja składała się z 3 folderów, Controller, Model i View.

W Controller było np. NewsController, z metodami showAll(), showOne(), archive().

Model przechowywał modele - NewsContainer, z metodami getAllNews, getById().

Natomiast w View były zwykłe szablony php.

Potraktowałem to bardzo luźno i uważam że tak powinno się traktować wzorce.
Dlatego zrób jak uważasz. Jak Ci jest wygodnie. Oczywiście pamiętaj by oddzielić 3 warstwy od siebie, jednak nie rób czegoś na siłę - np. tego że muszą być akcje czy coś tam jeszcze ciekawego.

Możesz ewentualnie podpatrzeć rozwiązania jakie są zastosowane w frameworkach np. agavi.

Pozdrawiam.

Nie zgodze się z tym. W wielu fw. szablony sa traktowane jako widok, a nie powinny. Jest to oczywiście "pójście na łatwiznę". Chodzi o to, że jeżeli generujemy sobie www to jest ok, ale jak ma dojsc do generacji PDF, czy XML' a ? Chyba nie bardzo już by działało. Zadaniem kontrolera jest podać do warstwy widoku dane, jego nie interesuje w jaki sposob widok je wyświetli - Jak mu sie zachce wygeneruje z tymi danymi PDF, a jak ie to wgra szablon i wygeneruje (X)HTML'a...

Owszem tak zrobiłem, bo tak było mi wygodnie i szybko. Nie potrzebowałem generowania fikuśnych rzeczy. Ja nie zgodzę się że:



Nie zgodzę się bo to w sumie jest nie prawda. Czemu nie powinny? Widok to warstwa prezenacji, a plik php z html jak najbardziej nim jest. A to że nie będę miał opcji generowania PDFów, XML itp to inna para kaloszy.

Jednak jak najbardziej jest to poprawne.

Zresztą, dyskusja na temat MVC jest w odpowiednim dziale i tam zapraszam zainteresowanych Chyba że autor ma jakieś nie jasności u siebie w projekcie.

Dziekuje za odpowiedzi. Nie chce robic offtopa, jesli to zly dzial, ale jak zaczalem pytac, to poprostu chodzi o to czy dobrze rozumiem idee MVC, czy np. instrukvja case, ktora podaje pod spodem a ktora znajduje sie w pliku index, powinna byc wlasnie tam, a jesli nie to jakie miejsce jest najbardziej odpowiednie dla niej. Mam obawe wpychania jej w metode jakiejs klasy, z tego wzgledu ze zdaje mi sie iz klasy powinny byc jak najbardziej ogolne(tylko wzorami dla obiektow), jesli wiec w klasie umiescilnbym tak szczegolowe parametry $tablica settings, to czy nie kluci sie tym samym z zalozeniami elastycznosci OOP. Wybaczcie prostote kodu, wolalem spytac, zanim klasy nie roznasnal sie bardziej tracac czytelnosc.

Plik index.php:

[PHP] pobierz, plaintext 
<?php
$page=$_GET['page'];
$id=$_GET['id'];
 
switch($page){
case 'contact-address':
	$settings['tableName']='kontakt_dane';
	$settings['title']='dane teleadresowe';
	$settings['cNum']=2;
	$settings['background']='address_bg.jpg';
	$settings['specialQuery']='SELECT * FROM '.$settings['tableName'];
break;
// Pozostale opcje switch;
$view->setLayout($settings);
$view->displayLayout('main.tpl');
?>
[PHP] pobierz, plaintext 

i klasa view:

[PHP] pobierz, plaintext 
<?php
class MVCView{
	public $smarty;
	public function __construct(){
		$this->smarty=new Smarty();
	}
	public function setLayout($settings){
		$this->smarty->assign('title',$settings['title']);
		$this->smarty->assign('background',$settings['background']);
		$this->smarty->assign('cNum',$settings['cNum']);
		$this->smarty->assign('leftCol', $settings['leftCol']);
		$this->smarty->assign('createLinks', $settings['createLinks']);
		$this->smarty->assign('leftMenuLink', $settings['leftMenuLink']);
		$this->smarty->assign('rightCol', $settings['rightCol']);
		$this->smarty->assign('includeImages', $settings['includeImages']);
		$this->smarty->assign('imagesResults', $settings['imagesResults']);
		$this->smarty->assign('mainMenuLink',$settings['mainMenuLink']);			
	}
	public function displayLayout($layout){
		$this->smarty->display($layout);
	}
}
?>
[PHP] pobierz, plaintext 

Dzieki i pozdrawiam!

Mieszasz ze sobą warstwy modelu i kontrolera.

[PHP] pobierz, plaintext 
<?php
$settings['tableName']='kontakt_dane';
$settings['title']='dane teleadresowe';
$settings['cNum']=2;
$settings['background']='address_bg.jpg';
$settings['specialQuery']='SELECT * FROM '.$settings['tableName'];
?>
[PHP] pobierz, plaintext 

To są szczegóły związane z wyświetlaniem i pobieraniem danych. Pobieranie jest związane z warstwą modelu, a wyświetlanie z widokiem. Kontroler nie ma prawa wiedzieć nic o zapytaniach do bazy czy tytule strony. On ma wywołać akcję, która pobierze dane i zwróci je (za jego pośrednictwem) do widoku. Czyli:

1. Pobierasz nazwę akcji na podstawie URL żądania
2. Uruchamiasz akcję (np. wzorzec Command)
3. Akcja pobiera dane i zapisuje je w jakimś kontenerze (np. tablica)
4. Dane zostają zwrócone do kontrolera.
5. Kontroler przekazuje dane do widoku.
6. Widok obrabia dane, dostosowuje je do interfejsu uzytkownika i zwraca wynik przetwarzania.

Najważniejsze jest to, żeby kontroler i widok nie wiedziały jak i skąd zostaną pobrane dane. Warstwa danych natomiast nie ma pojęcia jak zostaną wyświetlone.

Hej,

Dzieki za odpowiedz. Napisze juz super szybko zeby nie truc:

Problem w tym, ze normalnie za wyswietlanie strony powinna byc odpowiedzialna jaksa akcja. Poszczegolne odslony, nie zmieniaja, sie z wyjatkiem tego co wypluwa baza danych, iloscia kolumn, rlem i tematem(to widac w tablicy $settings z mojego postu). Niestety tabele sa tak dziwnie zrobione, ze nie mozna napisac prostej metody modelu, lub kilku i je wywolywac, Wlasciwie kazdy dzial ma niestety inna tabele, inne nazwy pol(bez ladu zadnego), w zwiazku z tym zastanawiam sie czy do kazdje strony(odslony) powininenm napisac inna akcje, bo w przeciwym razie wyghlada na to ze pozostaje mi takie wlasnie mieszanie widoku z modelem i kontrolerem o jakim napisales lsusznie...

Pozdrawiam!

Skoro na każdej stronie wykonujesz różne czynności, to za każdą czynność odpowiada inna akcja. Każda z nich zwraca jakiś zbiór danych, który następnie trafia do widoku. Widok możesz zrobić bardzo prosty: kontroler (z pomocą modelu) wybiera odpowiedni widok. Jeżeli masz elementy wspólne na wszystkich stronach, możesz zagnieździć szablon w drugim, ogólniejszym.

Zauważ, że w każdej akcji operujesz na danych tak jak chcesz... Zwracasz tylko zbiór danych, który ma być wyświetlony...