phpDocumentor i MVC, dokumentacja dla kontrolera Opcje

[Xathloc]

Podczas dokumentowania projektow mam niedomiennie ten sam problem. PHPDocumentor generuje z założenia dokumentację dla klas. Kontroler klasą nie jest i co za tym idzie jest ignorowany podczas tworzenia dokumentacji. Dla mnie kontroler, jako element spinający całość, jest najlepszym miejszcem do zawarcia najobszerniejszego opisu.
Jak wy rozwiązujecie problem dokumentacji kontrolera i całości aplikacji/modułu? Czy korzystacie z innych narzędzi?
Jak dla mnie PHPDocumentor jest najwygodniejszy, bo znajduje się w ZDE, którego używam.

[dr_bonzo]

Switch jest najbeznadziejniejszym rozwiazaniem.

Juz lepiej wrzucic mapowanie nazyw akcji do pliku.
np:
include( $mapa_akcji[ oczysc_nazwe_akcji_z_niebezpiecznych_znakow( $_GET['akcja' ] ) ] );
(gdy dodajesz kolejna akcje to wystarczy dodac kolejny element tablicy:
$mapa_akcji[ 'new_action' ] = "../sciezka/plik.php" + utworzyc plik z akcja

Idac dalej: nazwapliku moze byc identyczna jak nazwa akcji
include( oczysc_nazwe_akcji_z_niebezpiecznych_znakow( $_GET['akcja' ] ) ] . 'php' );
+ sprawdzenie czy plik istnieje
dodanie nowej akcji to tylko dodanie pliku z akcja

Lub jeszcze (jak pisal marast78):
kazda akcja to osobna klasa (jak w Agavi/Mojavi), lub metoda kontrolera (Symfony, RoR , ZF)
dodanie nowej akcji to tylko dodanie pliku z klasa akcji, no i masz wieksze mozliwosci niz przy zwyklym includowaniu


A w switchu? Musisz edytowac KOD skryptu i dodac nowe pliki. Po co to robic gdy wystarczy tylko utworzyc plik z akcja?

[Xathloc]

A w switchu? Musisz edytowac KOD skryptu i dodac nowe pliki. Po co to robic gdy wystarczy tylko utworzyc plik z akcja?

Zaraz, jako to?
A czym się różni utworzenie nowego pliku z akcją od dodania akcji do switch'a?
Tak czy inaczej muszę nauczyć odbiornik, że pojawiła się nowa akcja i utworzyć dla niej kod. Przy niezbyt rozbudowanych projektach zaczyna się pojawiać więcej kodu obsługującego framework niż wykonującego czynności wymagane z punktu widzenia modułu.
Zgadzam się, że switch'e dla dużych projektów są niewygodne (ale nie najbeznadziejniejsze).