Pluginy i moduły po raz n. Opcje

[ZuyPan]

Witam wszystkich.
Od razu zaznaczę - sporo czytałem na temat mojego problemu zarówno na tym forum jak i po różnych wygoglowanych stronach, jednak nie znalazłem czegoś co pasuję do mojego problemu. Przyszedł moment na mój własny CMS i pojawił się znany Wam problem - pluginy i moduły. Zacznijmy od podstaw - rozumienie przeze mnie tych dwóch pojęć aby nie było nieporozumień:
plugin - mała zmiana w działaniu strony jak np. dodanie możliwości komentowania profilu innej osoby na portalu lub oceniania go, kalendarz, bbcode.
moduł - to coś "większego" jak np. moduł sklepu lub moduł forum.
Ważne jest aby pluginy umiały się wpasować w odpowiednie miejsce tam gdzie powinny się wyświetlać - boczny panel (oczywiście możliwość ustawienia czy dajmy na to pod menu a może nad nim - wszystko to z poziomu panelu administratora) lub środek profilu użytkownika (wspomniane komentarze lub oceny).
Sporo czytałem o jądrze systemu i wydaje mi się, że to właśnie w tym miejscu powinno się odbywać wczytywanie ewentualnych pluginów i modułów. Wszystko wsparte było by bazą danych w której przechowywany by był stan pluginu/modułu (zainstalowany/nie zainstalowany, włączony/wyłączony). Jakieś pomysły jak to rozwiązać? Jeśli to jakoś pomoże lub naprowadzi Was na odpowiedni tor myślenia to przedstawię zarys projektu jądra:
1. Wczytanie pliku konfiguracyjnego
2. Wczytanie ustawień z mysql
3. Język strony
4. Ewentualne pluginy, moduły
5. Wczytanie ewentualnej podstrony, treści etc.
6. Wczytanie templatu

Nie mam pojęcia jak to rozwiązać dlatego zwracam się do Was. Po raz kolejny przypominam, że czytałem sporo na ten temat, ale tam wszystko rozwiązane jest obiektowo, a ja pomimo nauki jednak chyba nadal wolę strukturalny sposób. Proszę o rady (IMG:style_emoticons/default/smile.gif)

[Pilsener]

Ja stosuję np. nie pluginy i moduły, ale moduły i panele, moduły generują treść dynamiczną a panele to treść statyczna (by łatwo coś gdzieś umieścić). Radziłbym Ci zacząć od decentralizacji, czyli każdy moduł:
- ma własne modele danych
- własny silnik
- własne widoki

Nawet za cenę powielania znacznych ilości kodu z CMSa. Potem wystarczy przechwycić zmienną/zmienne, które ten moduł generuje i umieścić w swoim widoku/szablonie/szablonach etc:

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

Integracja odbywa się poprzez PA CMSa, gdzie dodaje się informacje o module, podaje link do pliku php z kodem tego modułu, nazwę zmiennej (która będzie dostępna w naszych szablonach) oraz link do PA tego modułu.

Decentralizacja ułatwia install/deinstall i wpływa dobrze na wydajność (moduł jest includowany tylko wtedy, kiedy jest wymagany na danej stronie), ma to też tą zaletę, że jako moduł mogę wrzucić niemal każdy skrypt albo użyć swojego modułu w innym silniku lub jako samodzielnego skryptu.

Inna sprawa to tak zwane rozszerzenia (ang. extensions), które po prostu rozszerzają funkcjonalność systemu o nowe bzdety i są z nim ściśle zintegrowane, tutaj wszystko zależy od głównego silnika i praktycznych przykładów, bo rozszerzenia mogą się np. uzupełniać lub wykluczać. Często integracja i instalacja tych rozszerzeń jest tak skomplikowana, że czyni je praktycznie bezużytecznymi (np. nowa wersja głównego silnika powoduje jego zatarcie po instalowaniu rozszerzenia, który tego nie uwzględniał).

Jak sobie zrobisz, tak będziesz miał, w wypadku rozszerzeń odradzam jakąś sztywną koncepcję a zamiast tego zalecam pełną integrację z opcją on/off danego bzdetu, jeśli klient chce nowej funkcji to mu ją napiszemy a system zmieniamy na dedykowany, inaczej nasz silnik nie udźwignie ogromu pluginów.