Mam już prawie ukończonego frameworka. Z większych rzeczy pozostał mi do napisania kontroler. Podpatrywałem ZF, przeglądałem rózne arty znalezione na google na ten temat. Ale nadal zastanawiam się jak powinien być zbudowany kontroler. Tzn wiem co chcę osiągnąć ale nie wiem jak to podzielić na Front Controller i na kontrolery. Ogólnie chciałbym mieć możliwość wybierania modułów i akcji danego modułu na podstawie np. takiego linka:



Możecie coś doradzić?

Zbudowales framework bez kontrolera - ROTFL

A o adresowaniu - to masz wyszukiwarke i slowo ROUTER.

Co Cię tak bawi?

też nie rozumiem co w tym śmiesznego - framework raczej nie ma w definicji posiadania kontrolera - to tylko zestaw narzędzi do budowania aplikacji - nigdzie nie jest powiedziane że kontroler musi być - bo to zależne jest od zastosowanego wzorca projektowego. To tak OT - a co do tematu to chyba na wortalu był jakis artykuł na ten temat.

Kontroler to serce frameworka - można przypuszczać, że to co nazywasz frameworkiem, to kilka klas, mocniej lub luźniej ze sobą związanych, ale nie ułatwiających pisania pełnej aplikacji.
Widzisz już gdzie jest pies pogrzebany?

Wiem o co chodzi, ale to nie zmienia faktu, że to co napisałem jest frameworkiem (mocniej lub luźniej powiązanych ze sobą klas) pomimo tego, że nie ma jeszcze kontrolera, który ułatwia pisanie aplikacji. Zależy kto jak rozumie zasadę działania kontrolera. Dla mnie front controller ma odpalać główne akcje.


Wiem, czytałem dużo artów ale każdy ma inne podejście do tego.

Zastanawiam się czy zamknąć wszystko w jednej klasie czy utworzyć klasy:

Router - posiadałaby metodę pobierającą z urla nazwę: kontrolera, modułu, akcji i parametry oraz metodę tworzoną urla na podstawie otrzymanego tokenu

Dispatcher - na podstawie otrzymanego tokenu (token byłby tablicą asocjacyjną zawierającą nazwę kontrolera, modułu, akcji i parametry), który odpalałby odpowiednią akcje..

Podziel na klasy. Dzięki temu podmieniając np. Router, będziesz mógł parametry pobierać np. z konsoli a nie url'a. Tak samo dispatcher, podmieniając go akcją nie musi być metoda klasy Kontrolera, a np. klasa w folderze kontrolera

kontroler to serce frameworka MVC. To może i byłaby prawda - a i tak nie do końca.
Tak więc takie ironiczne podejście jest co najmniej nie na miejscu.

Zobacz sobie temat o MVC na tym subforum. jest tam sporo rad, jak uruchamiać akcje, jak można dzielić je na moduły itp.

Czy obiekt kontrolera akcji powinien dziedziczyć po Front Controllerze czy powinien być odrębną klasą?

Dziedziczyć? A po co w kontrolerze akcji metody dispatch(), addFilter(), registerFilter() etc?

Odrębną.

Tak, ale po co stosować MVC ? Nie lepiej IPO zastosować ?

Bo jest wygodne i ktoś tak chce. Przy okazji mógł byś wytłumaczyć magiczny skrót IPO ?

Input Processing Output Mi to znacznie bardziej pasuje - plus jeszcze event driven i jestem w siódmym niebie

Wiesz jakie metody zawiera bo go już anpisałeś. A ja zastanawiam się jak to zrobić..

Nie kolego, ja wiem co Front Controller robi... czyli nie to, co Action Controller.

Ok, jakieś linki czy coś? Pierwsze słyszę. Po za tym wnioskując z nazwy. Input - analizujemy żądanie
Processing - realizujemy je
Output - zwracamy wynik.

Jeżeli tak to jest to samo co MVC i we wszystkich aplikacjach, inaczej się nie da. Nic odkrywczego.


J4r0d:

FrontController analizuje input (te twoje linki), i odpala kontroller który później odpala akcje. Controller napewno nie powinien dziedziczyć po FrontController, jeżeli już to na odwrót.

We wszystkich artykułach, które znalazłem na sieci Front Controller analizuje inputa i odpala odpowiednią akcje.

Strzałek: mógłbyś podać prosty przykład Front Controllera i Action Controllera? Prosty bo chcę załąpać jak to ugryźć. Podglądałem Rapide, ZF i jak na początek nie mogę się w tym odnaleźć..

U mnie nie ma czegoś takiego jak action controller. U mnie jest to mniej więcej tak:

[PHP] pobierz, plaintext 
<?php
class FrontController {
 
  public function dispatch(){
	$controller = $_GET['controller'];
	$action = $_GET['action'];
 
 
	$this -> perform($contrller, $action);
  }
 
  public function perform($controller, $action){
	$c = new $controller();
	$c -> $action();
  }
 
}
 
abstract class Controller {
/* .... */
}
 
class NewsController extends Controller {
  public function showOneAction(){
 
   /* pobieramy z bazy itp itd. */
   $this -> view -> render('showOne.php');
  } 
 
  public function showAllAction(){
 
   /* pobieramy z bazy itp itd. */
   $this -> view -> render('showAll.php');
  } 
 
}
?>
[PHP] pobierz, plaintext 

Powinno Cię trochę naprowadzić.

~J4r0d mam coś co może Ci pomóc stworzyć swojego kontrolera.
Oto lista rzeczy za które odpowiedzialny jest FrontController w Symfony:

• Define the core constants.
• Locate the symfony libraries.
• Load and initiate the core framework classes.
• Load the configuration.
• Decode the request URL to determine the action to execute and the request parameters.
• If the action does not exist, redirect to the 404 error action.
• Activate filters (for instance, if the request needs authentication).
• Execute the filters, first pass.
• Execute the action and render the view.
• Execute the filters, second pass.
• Output the response.

Mam nadzieję że Ci się przyda. Oczywiście masz dowolność w budowaniu swojego, powyższe to tylko przykład (z życia wzięty).

@mike_mech: dziękuje zawsze się przyda. Patrząc na przykład Strzałka to każda akcja to osobna klasa dziedzicząca po klasie abstrakcyjnej kontrolera.. Czyli mając w aplikacji 50 akcji to mamy 50 klas dziedziczących po klasie abstrakcyjnej ? :/

@J4r0d Idac wskazowkami @mike_mech rowniez polecam rozejrzec sie po zrodlach SF odnosnie budowy class do akcji. Sa 2 mozliwosci 1 akcja, 1 klasa, 1 plik. Lub wiele akcji, 1 klasa, 1 plik (oczwiscie tutaj jest to uzaleznione od modulu).

Jeszcze raz przeglądałem tematy na tym forum dotyczące budowania kontrolera i czytałem m.in. takie wypowiedzi niektórych użytkowników: "Tu powinieneś zastosować forward() zamiast redirect()"

Czym w takim razie (chodzi mi o sposób implementacji) różni się redirect() od forward() ? Przecież oba opierają się o header()

Mylisz się redirect() to jest przekierowanie przez header, czyli następuje przeładowanie na następną stronę.
Natomiast forward jest wirtualne, bez przekierowania, jedna akcja wywołuje następną.

Czyli podajesz do forward jakiś argument, który jest nazwą akcji do wywołania?

wyglada to mniej wiejcej tak $this->forward('modul', 'akcja', 'parametry'). Tak jest to u mnie zrobione.

Ok jeszcze jedno: forward i redirect powinno być w kontrolerze czy routerze?

A jak masz redirect? $this->redirect($url) ?

W kontrolerze. Kontroler pobiera z routera url na który ma byc przekierowany w przypadku redirect

[PHP] pobierz, plaintext 
<?php
public function redirect( $sUrl )
	{
		header( "Location: " . _SPARKLE_WEB . _SEP . swRouter::makeUrl( $sUrl ) );
		exit;
	}
?>
[PHP] pobierz, plaintext 

No nie wiem, dla mnie forward jest w kontrolerze, a reditect w Response (wysyłanie nagłówka).

Teoretycznie tak, ale praktycznie jest lepiej w controlerze. Ew. w kontrolerze mozna zrobic nakladke na response

Moim zdaniem (i nie tylko moim bo tak jest w Mojavi, Agavi, Symfony a nawet w CakePHP) controller jest odpowiedzialny zarówno za redirect jak i za forward.

Jest to dla mnie całkowicie naturalne.
forward jets to przerzucenie się na inną akcję podczas tego samego żądania a redirect jest to przeskoczenie na inną akcję z wykonaniem kolejnego żądania. Nie jest to do końca zwrócenie responsea (pomimo tego że wymaga to zwrócenia nagłówków).
Obie powyższe decyzje są decyzjami, które powinien podjąć kontroler i to on powinien się tym zająć.

Za tym rozwiązaniem stoi chmara developerów i jest to rozwiązanie stare i sprawdzone. Nie widzę tu nic nad czym trzeba debatować

@mike_mech: Zgadzam sie. Ale jesli mamy klase typu response która zarzadza w jakis tam sposób wysylanymi nagłowkami to takie redirect() powinno być nakladką na taką klase.

Dokładnie. Też twierdzę że technicznie powinien to być mechanizm wykonywany przez Responsea a tylko ewentualnie uruchamiany przez Controllera.
Powinien pójść nagłówek z kodem 302 i wszystko jasne

[PHP] pobierz, plaintext 
<?php
abstract class sfWebController extends sfController {
 
  // ...
 
  /**
   * Redirects the request to another URL.
   *
   * @param string An existing URL
   * @param int	A delay in seconds before redirecting. This is only needed on
   *			   browsers that do not support HTTP headers
   * @param int	The status code
   */
  public function redirect($url, $delay = 0, $statusCode = 302)
  {
	$response = $this->getContext()->getResponse();
 
	// redirect
	$response->clearHttpHeaders();
	$response->setStatusCode($statusCode);
	$response->setHttpHeader('Location', $url);
	$response->setContent(sprintf('<html><head><meta http-equiv="refresh" content="%d;url=%s"/></head></html>', $delay, htmlentities($url, ENT_QUOTES, sfConfig::get('sf_charset'))));
 
	if (!sfConfig::get('sf_test'))
	{
	  $response->sendHttpHeaders();
	}
	$response->sendContent();
  }
 
  // ...
}
 
?>
[PHP] pobierz, plaintext 

@mike-mech: co robi metoda $this->getContext() ?

Jak wygląda metoda clearHttpHeaders() i setHttpHeaders()?

Powyższa funkcja to tylko przykład, który miał mniej więcej zobrazować to co się dzieje. Jest to część fragment klasy sfWebController z Symfony.
Po szczegóły odsyłam do sfWebResponse

Pewnie jak w większości frameworków:

[PHP] pobierz, plaintext 
<?php
public function getContext()
return $this->context;
}
// --------------------
public function setHttpHeaders($strHeaderName, $strHeaderValue)
{
$this->arrHeaders[$strHeaderName] = $strHeaderValue;
}
// --------------------
public function clearHttpHeaders()
{
$this->arrHeaders = array();
}
?>
[PHP] pobierz, plaintext 

Oczywiście nazwy mogą się różnić.
A co do dyskusji. Imho, nie ma nad czym się rozwodzić. Interpretacji jest tyle, ilu programistów. Każdy robi po swojemu.