[MVC] Rozbudowany router i wyspecjalizowane kontrolery?, czy rozbudowane i „inteligentne” kontrolery? Opcje

[MacDada]

Hej,

mam dwa koncepty na pisanie aplikacji, ale właściwie to oba mi nie podchodzą pod gust.

Koncept 1: Rozbudowany router i wyspecjalizowane kontrolery.
Wygląda to tak, że router pobiera sobie PATH_INFO, rozbija na tablice i interpretuje co jest kontrolerem, co akcją, co innymi parametrami. Odpala więc odpowiedni kontroler i przekazuje mu tablicę z ustaloną akcją i parametrami.

Koncept 2: Mały router, rozbudowane i „inteligentne” kontrolery.
Router pobiera sobie PATH_INFO, rozbija na tablice, rozpoznaje pierwszy parametr jako kontroler i odpala go, przekazując mu surową tablicę. Dopiero kontroler ma swój mini-router, który rozpoznaje co jest akcją, co parametrem i na tej podstawie działa.

Które rozwiązanie jest lepsze?

Kolejne pytanie. Chciałbym, żeby aplikacja była możliwie bardzo zmodularyzowana, a więc, żeby można było wziąc klocki i na ich podstawie zbudować stronę. Takimi klockami byłby moduł menu, moduł newsów, moduł kalendarza, księgi gości, moduł reklamy, itd. Każdy moduł miałby swój kontroler i zestaw widoków. Czyli działanie aplikacji wyglądałoby tak:

Chcę wyświetlić stronę z newsem, to odpalam kontroler newsów, który zajmuje się wyświetleniem newsa. Oprócz tego odpalam kontroler menu i kontroler reklamy. Każdy to niezależny klocek, który można wykorzystać na dowolnej stronie. Już o tym kiedyś pisałem.

Jak jednak to zrealizować? Musiałbym kontrolerowi newsów w odpowiednim momencie kazać wyświetlić to menu, czyli kontroler musiałby albo mieć metodę render (czyli zajmować się aspektami widoku) albo zwracać w zmiennej gotowy kod HTML, który wyświetlałby dopiero kontroler, który wywołał moduł tworzenia menu...

No kolejna sprawa.

Mam np http://strona.com/news/4/
Czyli strona odpala kontroler News, akcja domyślna View, parametr 4 jako identyfikator newsa.

Z drugiej strony mam panel admina: http://strona.com/admin/news/4/edit/
Czyli strona odpala kontroler admin, ten odpala kontroler news, itd.

Czy powinienem zrobić dwa oddzielne kontrolery - jeden "kliencki" tylko z opcją wyświetlania, drugi adminowy, z edycją, itd. - czy może jeden kontroler „inteligentny”, który w zależności od kontekstu inaczej się zachowuje?


Dzięki za odpowiedzi, ostatnio więcej siedzę i myślę nad koncepcją pisania niż rzeczywiście spędzam czas na kodowaniu... (IMG:style_emoticons/default/sciana.gif)

[Pilsener]

1. Router vs controller - router to router, sam sobie odpowiedziałeś, router ma zwrócić tablicę parametrów i dołączyć ją do rejestru czy czego tam używamy by mieć łatwy dostęp do zmiennych, kontroler nie powinien zajmować się obróbką adresów typu index,34.html, bo pogubimy się w logice aplikacji, tablica parametrów powinna wynikać jasno z routingu.

2. Masz coś takiego jak LAYOUT, lub "drzewo widoków", każdy szablon może się składać np. z:

[HTML] pobierz, plaintext 
<p>{pogoda}</p>
[HTML] pobierz, plaintext 

- a zmienna pogoda może zawierać kolejny layout, obiekt, szablon, zwykły html lub liczbę. Przy strukturalnym realizowałem to tak, że dla każdego modułu/kontrolera/akcji była podpięta tablica modułów, które należało zaincludować i te includowane bajery dodawały swoje zmienne do przypisanego do tego adresu szablonu. Możesz w widoku strony głównej wywołać kontroler news:

[PHP] pobierz, plaintext 
$this->action(array('action'=>'view','module'=>'news','controller'=>'index'));
[PHP] pobierz, plaintext 

3.

Czy powinienem zrobić dwa oddzielne kontrolery - jeden "kliencki" tylko z opcją wyświetlania, drugi adminowy, z
edycją, itd. - czy może jeden kontroler „inteligentny”, który w zależności od kontekstu inaczej się zachowuje?

- do wyświetlania newsów jeden kontroler, a do adminowania (back office) drugi, kontroletry bym podzielił na poszczególne akcje, oprócz kontrolerów i akcji dodałbym jeszcze moduły. Oczywiście czasem są elementy wspólne, mniej lub więcej - podział aplikacji na moduły/kontrolery/akcje musi to uwzględniać.

Ja bym Ci radził skorzystać z frameworków i zobaczyć, jak tam się to odbywa, nie ma sensu popełniać czyichś błędów.