Głowię się już od pewnego czasu nad problemem modułowości aplikacji. Najlepiej będzie to wyjaśnić na przykładzie.
W aplikacji znajdują się dwa moduły - blog oraz rss. Jak wiadomo rss musi być stworzony na podstawie jakichś danych, więc sam moduł jest bezwartościowy. Jednak w przypadku bloga, może on istnieć bez rss.
I tutaj pojawia się problem.
Jeśli napiszę aplikację typu blog, która ma dostęp do rss, wówczas formularz do edycji wpisów musi w jakiś sposób uwzględniać istnienie rss (czy dodać do rss oraz do jakiego kanału dodać wpis). Jednak w przypadku aplikacji bez rss, formularz do edycji wpisów nie potrzebuje dodatkowych pól. Jak to rozwiązać?
Jedyny sensowny pomysł na jaki wpadłem jest taki, że w pliku z konfiguracją aplikacji mam zapisane jakie moduły są aktywne i na tej podstawie generuję (lub nie) odpowiednie elementy formularza oraz ich obsługę.
Rozwiązanie to ma jednak jedną poważną wadę. W przypadku dużej ilości zależnych od siebie modułów, powstanie mi kod spaghetti, w którym więcej jest if-ów niż kodu właściwego. Tyczy się to zarówno formularzy, jak i modeli.
Od razu napiszę, że odpada rozwiązanie, w którym to w module rss wybieram jakie wpisy mają zostać dodane do kanałów rss.

W sumie całkiem ciekawą funkcjonalność modułów można znaleźć w Drupalu (nie wnikam w implementację). Tam można nadpisać dowolny formularz poprzez wywołanie funkcji hook_form_alter - generalnie chodzi o wyzwolenie akcji przed wyświetleniem formularza. Dodatkowo formularz może wykonywać więcej niż jedną akcję. Można by coś podobnego spreparować w ZF. Poniższy schemat jest tylko szkicem i nie doczekał się implementacji:
1. Tworzymy rejestr formularzy. W trakcie ładowania modułu należy dodać do rejestru informacje o formularzach jakie dany moduł chce modyfikować.
2. Budujemy coś na kształt form dispatchera - jego zadaniem będzie wykonanie serii akcji na danym formularzu.
3. Rozszerzamy klasę Zend_Form o możliwość dodawania obserwatorów (byłyby ładowane z rejestru przy tworzeniu egzemplarza klasy a wyzwalane przed renderowaniem), dodatkowo tworzymy funkcję addAction (odpowiednio removeAction), która będzie dodawała (usuwała) akcję do już zdefiniowanej listy (dodatkowo można by ustawiać wagi akcji), funkcja setAction powinna kierować do form dispatchera (stały adres lub modyfikacja routingu).

No, to się zmieściłem w trzech groszach. Wszelkie komentarze mile widziane (implementacja jeszcze milej )