Forum PHP.pl

Nie wiem od czego zacząć pisac mój pierwszy kontroler. Wiem, że musze zacząć od front kontrolera ale nie moge załapać, jak zacząć, co on ma robić i jak dalej ma przekazywać żadania, akcje i gdzie je w końcu wywoływać. Jak ma to wszystko działać i z czym to się je.
Googlowałem, szukałem na forum, czytałem ale dalej mam wiele wątpliwości.
Z tego co rozumiem to front controller ma za zadanie tylko wyciąganie akcji z adresu, i uzyskiwanie odpowiedniej formy żądania? tzn. np utowrzenie tablicy z poszczegolnymi parametrami żadania ze stringu.
Np. z http://.../index.php?mod=newsy&pokaz=34&parametry=23;56;21
nasz FC ma za zadanie tylko uzyskanie odpowiedniej formy, np. tablicy i przekazanie akcji dalej... ale gdzie dalej i jak...?

Jestem początkującym programistą więc proszę o proste tłumaczenie i wyrozumiałość

pozdrawiam

dużo się nauczysz przeglądając klasy i opis do nich z Zend pseudo Frameworka.

Front Controller to wzorzec projektowy i robi tyle, ile chcesz aby robił. Jeśli jak mówisz, jesteś początkujący, to obejrzyj stronę
http://martinfowler.com/eaaCatalog/

Wzorzec, o którym rozmawiamy, to http://martinfowler.com/eaaCatalog/frontController.html
Jest on punktem wejścia dla każdego żądania. Określa, jaka komenda zostanie uruchomiona, uruchamia wszelkie globalne walidatory, określa kontekst żądania. To nie znaczy, że ma wiedzieć, jak się to odbywa, bo najczęściej zleca to innym obiektom przekazując potrzebne informacje, a on je jedynie... kontroluje

Pozdrawiam.

Przeglądam Zend Frameworka... przeglądałem cake php i code codeIgniter...
ich kontrolery są ogromne, rozubodowane... myślę, że zdecydowanie za duze jak na moje projekty.

Dalej nie wiem od czego zaczac... :/

Zacznij od teorii wzorców.
Pierwszy trop dostałeś od ~Cysiaczka. Jest tam kilka słów tytułem wstępu.

Bardzo obszerny artykuł (najlepszy jaki widziałem) o tym wzorcu przeczytasz tutaj: Core J2EE Patterns - Front Controller.
Bez znajomości teorii wzorców projektowych nie masz co podchodzić do tematu.

Ja w swoim FW, front controllera użyłem do załadowania i odpalenia całego systemu (i on tam rozdzielał zadania do reszty modułów frameworka). Kontroler jest czynnikiem logicznym aplikacji i nie powinieneś tam umieszczać takich rzeczy jak kontakt ze źródłem danych i wyświetlanie (ani drobne echo, żadnego formowania tekstu). Co tam powinno być? Obliczenia na danych, sortowanie, przygotowanie do wyświetlenia (udostepnienie modułowi View). Najważniejsze jest odpowiednie rozdzielenie operacji pomiędzy 3 warstwy: M V C.
Wyświetlaniem zajmuje się warstwa View. Na początek może to być klasa includująca pliki szablonów (w miare rozwoju fw, będziesz mógł bez konsekwencji zmienić metodę wyświetlania). Taka porada: w klasie View dobrze jest przeciążyć magiczne metody _set() i __get(). ;]

Napisalem cos takiego, ale wiem, ze to jest zle:

index.php:

[PHP] pobierz, plaintext 
<?php
// read current path
$thisPath=$_SERVER[&#092;"SCRIPT_FILENAME\"];
$end=strlen($thisPath)-9;
$main=substr($thisPath, 0, $end);
 
// set pathes
// all pathes contain \"/\" on the end
$GLOBALS[&#092;"_PATHS\"][\"main\"]=$main;
$GLOBALS[&#092;"_PATHS\"][\"config\"]=$main.\"config/\";
$GLOBALS[&#092;"_PATHS\"][\"controllers\"]=$main.\"controllers/\";
$GLOBALS[&#092;"_PATHS\"][\"classes\"]=$main.\"classes/\";
$GLOBALS[&#092;"_PATHS\"][\"images\"]=$main.\"images/\";
$GLOBALS[&#092;"_PATHS\"][\"models\"]=$main.\"models/\";
$GLOBALS[&#092;"_PATHS\"][\"libs\"]=$main.\"libs/\";
$GLOBALS[&#092;"_PATHS\"][\"photos\"]=$main.\"photos/\";
$GLOBALS[&#092;"_PATHS\"][\"styles\"]=$main.\"styles/\";
$GLOBALS[&#092;"_PATHS\"][\"templates\"]=$main.\"templates/\";
$GLOBALS[&#092;"_PATHS\"][\"views\"]=$main.\"views/\";
 
// load config
$conf=parse_ini_file($_PATHS['config'].&#092;"config.ini\", true);
$GLOBALS[&#092;"_CONFIG\"]=$conf;
 
 
// include libaries
require($_PATHS['libs'].&#092;"db_mysql_dev.php\");
require($_PATHS['libs'].&#092;"mapper.php\");
 
// start
require($_PATHS['controllers'].&#092;"front.php\");
?>
[PHP] pobierz, plaintext 

ustalam sciezki
czytam konfiguracje
includuje biblioteki i na koncu przekazuje kontrole do wlasciwego kontrolera
A wlasciwy kontroler wyglada tak:
front.php

[PHP] pobierz, plaintext 
<?php
// module
$module=null;
if(isset($_GET[&#092;"module\"]))
  $module=$_GET[&#092;"module\"];
if(isset($_POST[&#092;"module\"]))
  $module=$_POST[&#092;"module\"];
 
// select module
switch ($module){
  case &#092;"konkurs\":
	require($_PATHS['controllers'].&#092;"competition.php\"); 
	break;
 
  case &#092;"regulamin\":
	require($_PATHS['controllers'].&#092;"rules.php\");
	break;
 
  case &#092;"dodaj\":
	require($_PATHS['controllers'].&#092;"add.php\");
	break;
 
  case &#092;"porady\":
	require($_PATHS['controllers'].&#092;"advices.php\");
	break;
 
  case &#092;"galeria\":
	require($_PATHS['controllers'].&#092;"gallery.php\");
	break;
 
  case &#092;"nagrody\":
	require($_PATHS['controllers'].&#092;"awards.php\");
	break;
 
  case &#092;"organizatorzy\":
	require($_PATHS['controllers'].&#092;"organisers.php\");
	break;
 
  default:
	require($_PATHS['controllers'].&#092;"competition.php\");
	break;
}
?>
[PHP] pobierz, plaintext 

dodam ze powyzszy kontroler jest zrzutowany na odpowiedni dzialy. Tzn. powyzszych requierow jest tyle ile mam glownych dzialow - przyciskow w glownym menu.

Zatem glowny kontroler przekazuje kontrole dalej do kolejnych 'Page controllerow'? tak sie to nazywa w terminologi kontrolerow. Zatem powyzsza czesc to moj front controller, tylko ze wszedzie jest pisany obiektowo a ja mam strukturlanie i nie wydaje mi sie on byc poprawny... nie lezy mi on.

Ten post edytował Beynar 13.01.2008, 21:44:24

oj oj, ten switch gryzie w oczy. wiem ze to jest zabezpieczenie anty h4x, ale można swobodniej nieco postąpić. po przesianiu wartości $_GET['module'] można spokojnie dać require($_PATHS['controllers'].$_GET['module']);. Da ci to aplikacji większą elastyczność.
Co do ładowania systemu i FC, troche za mało OOP, właściwie jego tam wcale nie ma. Powinno być coś z rodzaju $oRouter->init(); i kilka innych linijek które mówią dokładnie co jest kiedy ładowane ;]

A co sadzicie o pomysle, zeby w osobnym pliku konfiguracjynm ini opisac np. czego wymaga dana akcja tzn. okreslac tam jakich wymaga bibliotek, jaki uruchamia moduł, jaki parametrów są niezbędne i czy wymagana jest jakas dodatkowa autentykacja.
Kontroler na podstawie takiej konfiguracji moglby wszystko ładować
Jak wy to rozwiazujecie?
Na sztywno w kodzie wywolujecie dla danej akcji odpowiednie includy i powolujecie odpowiednie metody? a sprawdzanie czy są wymagane argumenty itd? Mozna by to skupic w jednym pliku konfiguracyjnym kontrolera.

Ja mam tak że router zwraca mi tablice do kontrollera w takiej formie (przyklad)

Przekazuje to do controllera, ktory w tym wypadku wczytuje klase NameControllr z metoda NameMethod i przekazuje jej podane zmienne. Oczywiście mozesz zrobic zamiast przekazyania do metody w klasie do czystego pliku, to juz rozwiazesz jak bedziesz chcial

1. Pojawiły sie jeszcze dwa pojęcia ktorych do konca nie rozumiem: dispatcher i router

router ma odpowiadac za przekierwoanie akcji? redirect i forwardowanie

2. Jakkolwiek do kazdej strony musze pisac obsluge danej juz akcji. Strukturalnie? Jak wy piszecie wykonanie akcji na samym koncu - przed przekazaniem danych wynikowych do widoku

Prosze o wyrozumialosc
jestem poczatkujacym

pozdrawiam

Ten post edytował Beynar 14.01.2008, 12:05:36

Tak się niczego nie nauczysz - będziesz miał tylko mętlik w głowie. Biorąc po uwagę przedstawiony przez Ciebie kod uważam, że za wcześnie bierzesz się za wspomniane wzorce i tak, jak powiedział ~mike - poznaj teorię - najlepiej z jakiejś książki.

Mówisz, że ZF i inne FW mają rozbudowane kontrolery - nie zgodzę się - uważam, że w każdy z nich jest wręcz ubogi. Skoro jednak uważasz, że są to za ciężkie rozwiązania dla Ciebie, to tym bardziej nie powinieneś implementować kontrolera fasady, routera itp.
Ogranicz się do prostych kontrolerów strony (Page Controller)

Umieszczane informacji o akcjach w zewnętrznych plikach ma sens jedynie wtedy, gdy dysponujesz odpowiednio rozbudowanymi kontrolerami - inteligentnymi kontrolerami. Wspomaga to wówczas programowanie wg. wzorca Command, którego implementacje (akcje) nie muszą się martwić o poboczne zadania (np. ustalenie widoku, który zostanie wywołany).

Pozdrawiam.

Jeśli mówimy o wzorcach projektowych to mówimy tylko i wyłącznie w kontekście programowania obiektowego.

I na prawdę polecam najpierw teorię. Kontrolery w Zendzie są jednymi z prostszych, więc może się okazać, że powywasz się na coś czego nie rozumiesz.