Budowa kontrolera Opcje

[Jarod]

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:

Kod

http://serwer/module=module1/action=action1/value=1/value2=2/.../...

Możecie coś doradzić?

Ten post edytował J4r0d 22.02.2007, 18:00:25

[NuLL]

Zbudowales framework bez kontrolera - ROTFL

A o adresowaniu - to masz wyszukiwarke i slowo ROUTER.

[Jarod]

Zbudowales framework bez kontrolera - ROTFL

Co Cię tak bawi?

[devnul]

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.

[LBO]

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?

[Jarod]

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.

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.

(...)a co do tematu to chyba na wortalu był jakis artykuł na ten temat.

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..

[LBO]

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

[DeyV]

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.

[Jarod]

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

Ten post edytował J4r0d 6.03.2007, 10:34:40

[LBO]

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

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

Odrębną.

[Turgon]

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

[Strzałek]

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 ?

[Turgon]

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

[Jarod]

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

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

[LBO]

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.

[Strzałek]

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

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.

[Jarod]

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źć..

[Strzałek]

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ć.

[mike]

~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).

[Jarod]

@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 ? :/