Witajcie,
Od kilku dni nurtuje mnie pewien pomysł na budowę aplikacji. Do tej pory wyglądało to u mnie tak, że do głównego kontrolera podczas jego tworzenia wrzucałem referencję do routera [w ktorym siedzial request, response (iterator przechowujacy odpowiedz z akcji przekazywana dalej do widoku - w celu unikniecia jawnego przekazywania widoku akcjom i odwrotnie), i url decoder], do klasy obslugi baz danych, do menadzera akcji, menadzera widoku, klasy config, etc, byly metody odpalajace poszczegolne etapy wykonywania i w sumie wychodziło dosyć topornie od strony elastycznosci. Ale mniejsza o to czy to podejscie bylo sluszne czy nie - co projekt to inna interpretacja MVC. Poniewaz moja aplikacja ma na podstawie jednego rzadania odpalac kilka akcji - wiadomo, mam strone glowna portalu wiec musi sie zaladowac ShowNews, ShowMenu, ShowCalendar, ShowArticles i tak dalej. Z tego powodu postanowilem zaimplementowac moj stary patent - TaskManager ktory na podstawie pojedynczego rzadania tworzy mi gotowy lancuch akcji i przekazuje dalej do ActionManagera. I tu pojawil sie dylemat - gdzie to wsadzic - czy jako nakladka na ActionManager, czy oddzielny czlon systemu, czy jako filtr requestu tlumaczacy zapytania. W miedzyczasie przeczytalem w Design Patterns opis wzorca Chain of Responsibility, dzieki czemu wpadlem na IMHO ciekawy pomysl. Otoz mysle, aby trzonem systemu byl wlasnie request a nie controller. Mam klase request, ktora - w przypadku aplikacji webowej - trzyma wszystko z superglobali, czyli to co przychodzi z przegladarki. Cala rola kontrolera w tym przypadku to przepuszczenie tego requesta przez lancuch swego rodzaju filtrow dzialajacych na tym requescie i pozniejsze przekazanie response'a do widoku. Mialbym zestaw klas-filtrow opartych o jednolity interfejs, takich jak url decoder czy task manager ktore na podstawie odpowiednich zapytan dodawaly by nowe zapytania do requestu, action manager ktory na bazie otrzymanego zapytania odpalal by akcje i wywalal odpowiedz juz nie do requestu a do responce, moze i cos, co na podstawie zapytania wypluwalo by mi odpowiedni widok czy chociaz jego nazwe...
Pomysl jest bardzo swieży i zastanawiam sie zarowno nad jego implementacja jak i ogolnym sensem takiego podejscia. Wlasciwie czesc opisanych rzeczy wymyslalem prawie ze na zywo podczas pisania postu wiec moglem napisac glupoty, wiec prosze o ewentualne wyprostowanie mojego toku myslenia. W tej chwili wydaje mi sie iz taka modularyzacja systemu oparta o wspolny interfejs nadala by mu elastycznosci, do tej pory nie spotkalem sie jeszcze z tego typu dynamiczna architektura wiec prosze Was o opinie. W praktyce mozna by sprowadzic konstrukcje frameworka do kontrolera lancucha, klasy z requestem, iteratora z responce i interfejsu dla filtrow. Wlasciwie to nawet klasa abstrakcji na bazy danych mogla by byc odpalana przez filtr dopiero jesli jest potrzebna, tak samo nawet i widok - jesli dana instancja ma tylko wyslac do przegladarki plik i doliczyc go do licznika pobran, to przeciez jasne ze nie ma tu miejsca na widok bo zadnego widoku taka aplikacja nie powinna wypluwac.
Nie daje na razie ani zadnego diagramu ani przykladow kodu tylko suchy opis, bo jeszcze nie do konca wiem jak by to mialo hulac wszystko i czy to ma sens.

Ostatnio myslalem nad czyms podobnym, a mianowicie jak zaimplementować obsługę, różnych bloków pobocznych (typu ankieta, reklama etc) w Symfony. Doszedłem do wniosku, że najlepiej będzie użyć do tego celu filtra przed akcją, który bierze konfigurację dla danej akcji i odpala odpowiednie bloki, a następnie wsadza je w jakiś obiekt/tablice.

Takie rozwiązanie jest w miarę ok, gdyby nie fakt, że dla każdej akcji musimy stosować konfigurację. I w mojej opinii tutaj wychodzi na jaw wada wzorca MVC w najbardziej popularnej konfiguracji flowu (przepływu danych). Ostatnio bawiłem się trochę Django, którym, jak twórcy mówią, implementuje MTV: Model-Template-View. Pozbyto się kontrolera i wyszło to na dobre - po prostu definiujesz jakie dane chcesz wrzucić do szablonu i wyciągasz je z modelu. Genialne w prostocie i bardzo użyteczne.

Ja rozwazalem jeszcze inne podejscie w ktorej front controler zajmuje sie jedynie inicjalizacja i udostepnianiem obiektow wspolnych dla calej aplikacji takich jak obiekt abstrakcji baz danych, templaty, request, dispatcher itp. Ostatni z wymienionych obiektow dyspozytor zajmuje sie oczywiscie wyszukiwaniem kontrolerow poszczegolnych modulow oraz wyborem odpowiedniej akcji. Roznica polega na tym, ze o ile w klasycznym ujeciu dyspozytora uruchamia tylko i wylacznie front controler o tyle u mnie dyspozytor moze byc wywolany niejako recznie i to wielokrotnie w czasie jednej "odslony". W praktyce sprowadza sie to do tego ze dyspozytor wywolywany jest w pliku konfiguracyjnym (inicjalizującym) danego modulu. W ten sposob mozna zdefiniowac reakcje danego modulu na dowolna akcje wywolana dla aplikacji. Dany modol moze reagowac tylko jesli zostanie wywolana ktoras z akcji jego kontrolera, moze tez uruchamiac akcje domyslana, albo reagowac wywolaniem ktorejs ze swoich akcji w odpowiedzi na wywolanie dowolnej akcji innego modulu.

Jest to rozwiazanie eleastyczne, ale ma swoje wady, a mianowicie koniecznosc kontrolowania zaleznosci. Przykladowo sa dwa moduly, ktore wymagaja do swego dzialania okreslonej biblioteki js. Jesli poszczegolne moduly dzialaja od siebie niezaleznie moze sie zdarzyc ze oba moduly dodadza do generowanego widoku kod biblioteki js.

Ja w swoim poprzednim frameworku zastsowalem bardzo proste rozwiazanie, chociaz moznaby dlugo dyskutowac, czy prawidlowe i czy wydajne

Wymyslilem sobie, ze do czegos takiego bede uzywal tzn Apletow. Przyjalem, ze taki aplet to samowystarczalny kod, ktory zadziala bez obslugi go przez framework. Ma dostep do wszystkich bibliotek - widokow, modeli, wiec co jeszcze?

Przyklad:

[PHP] pobierz, plaintext 
<?php
class UserApplet
{
  public static function execute()
  {
	$oController = Controller::getInstance();
 
	if(!$oController->getContext()->getUser()->getAttribute('userAuthenticated'))
	  return null;
 
	$oLanguage = $oController->getLanguage();
 
	$sAppletLanguageFileName = _DIR_APPLICATION_LANGUAGES . $oLanguage->getLanguageName() . '/' . __CLASS__ . '.php';
 
	$oLanguage->loadLanguage($sAppletLanguageFileName);
 
	$sUserFullName = $oController->getContext()->getUser()->getAttribute('userFullName');
	$aUserGroups = $oController->getContext()->getUser()->getAttribute('userGroups');
 
	$oView = $oController->getView('UserApplet');
 
	$oView->setAttribute('userFullName', $sUserFullName);
	$oView->setAttribute('userGroups', $aUserGroups);
 
	return $oView->fetch();
  }
}
?>
[PHP] pobierz, plaintext 

W szablonie dodaje taki kod:

[PHP] pobierz, plaintext 
<?php
require_once(_DIR_APPLICATION_APPLETS . 'UserApplet.class.php');
	  echo UserApplet::execute();
?>
[PHP] pobierz, plaintext 

Dziala i to bardzo ladnie. Aplet mozna dowolnie modyfikowac, zmieniajac widok jak nam sie tylko pdooba

Adrian.

Problem nie jest stworzenie takiego kodu (czy nazwanie :] ), ale konfiguracja ich i odpalenie w odpowiednim momencie, bo nie zawsze potrzebujemy wszystkie nasze bloki, aplety, etc.

Aha, jakby ktoś szukał to w Symfony to nazywa się Partial.

To są sloty, używanie w widokach przez $this->setSlot(slotname, modulename, actionname). W M4 jak i w Symfony jest coś takiego jak Layouty.

@splatch ale wydaje mi sie ze tu bardziej chodzilo o akcje.

Sloty w gruncie rzeczy to wywoływane akcje, z tym, że ich wynik trafia do widoku a nie od razu do klienta.