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

Pokaż, co czytałeś. Bo to, że sporo, to nie znaczy, że to, co powinieneś. Czytałeś wątek w dziale PHP Pro na forum?


Współczuję, naprawdę się zajeździsz. Jeśli szukasz przykładów, to strukturalnie napisany jest Drupal oraz Wordpress. Z czego ten pierwszy jest IMHO nieco lepiej przemyślany.

oh sporo tego było. Wymienianie wszystkiego wymaga odalezienia tego wszystkiego. To taki mały zbiór mojej lektury:
Temat: Aplikacje PHP Pluginy
Temat: jak pisac jadro <- na temat jądra
Temat: moduly
http://forum.php.pl/index.php?showtopic=25455
+ sporo stron z google - zbyt dużo by wymieniać.
Sama obiektówka choć idee ma świetną jest dla mnie chyba zbyt skomplikowana... Te wszystkie interfejsy i inne trudne słówka chyba mnie przerastają

No i czego nie rozumiesz?


IMHO najpierw poznaj obiektówkę, potem bierz się za pluginy...

No właśnie tego jak to zrobić strukturalnie Nigdy czegoś takiego nie pisałem, nie jestem pewny zasady na jakiej to powinno działać a zwłaszcza tego automatycznego "umieszczania się" w odpowiednim miejscu strony (bez mojego grzebania w kodzie aby umieścić to w odpowiednim miejscu).

Obiektówki się uczyłem i to dość długo. Po prostu prawdopodobnie jest dla mnie zbyt skomplikowana

Musisz w odpowiednich miejscach wrzucać tzw. hooki, w których będą uaktywniane odpowiednie wtyczki i ich metody. Tutaj przyda Ci się call_user_func albo funkcje lambda, ale obiektówką byłoby lepiej, choćby ze względu na wzorzec Proxy (łatwe podstawianie wtyczek do istniejących funkcjonalności).

A jak to jest wszystko strukturalnie zrealizowane, proponuję lekturę dokumentacji Drupala.

Z tego co rozumiem to z tymi hookami to musiał bym przewidzieć albo po prostu podstawić w kodzie docelowym właśnie taki hook i dzięki niemu plugin umieści się tam gdzie trzeba? A mnie właśnie chodzi o pełną automatyzację, bez mojej żadnej ingerencji poza:
- wrzuceniem pliku na serwer
- kliknięciem instaluj w panelu admina

Po prostu w każdej wtyczce, jako głównego wyzwalacza, używasz funkcji podpinającej do wybranego hooka. Tak działa większość systemów wtyczek.

Przykładowo, w Wordpressie (mogłem coś pokiełbasić, dawno tam grzebałem):

[PHP] pobierz, plaintext 
add_action('post_publish', 'moja_zajekrzywabista_wtyczka');
 
function moja_zajekrzywabista_wtyczka($parametry){
    echo 'dodales wlasnie: '.(string)$parametry;
}
[PHP] pobierz, plaintext 

A w kodzie Wordpressa jest dodana odpowiednia metoda, która zaraz po dodaniu posta, wywoła kod Twojej wtyczki.


I w tym tkwi szkopuł. Nie zdziw się, jeśli przy prostym CMS-ie tych haków będzie i kilkaset.

W takim razie tu gubię podstawowe pojęcie wtyczki, które ja rozumiem tak: wtyczka to coś co dodaje nową funkcję do serwisu www. A wychodzi na to, że projektując cały serwis muszę przewidzieć i niejako zdecydować w którym miejscu dać możliwość podpinania się wtyczek. To tak jakbym chciał po prostu dorobić parę innych funkcji tylko, że potem a puki co przygotowywuje im miejsce. A nie da się tego jakoś rozwiązać w sposób bardzo automatyczny? Aby wtyczki w jakiś tam sposób rozpoznawały co to za część strony a nie tak jak Wy mi proponujecie (a ja to rozumiem:) przygotowywania ewentualnych miejsc pod ewentualne wtyczki.

Zobacz, że w każdej aplikacji oferującej rozszerzenia/wtyczki jest tak samo - albo hooki, które są wykonywane w odpowiednich momentach, albo wstrzykiwanie kodu bezpośrednio w odpowiednie miejsca. Nie wiem na 100%, jak jest w np. w Firefoksie, ale podejrzewam, że bardzo podobnie.


Chcesz sobie aplikację wyklikać albo żeby sama to wymyśliła? To po co programować? Gdyby się tak dało, to wątpię, aby były rozwijane języki programowania/inżynieria tworzenia aplikacji.


No a jak sobie wyobrażasz wtyczkę, która np. dodaje Ci funkcję formatowania treści stron przez markdown? Gdzie się wepnie? Albo - na chama - wstrzyknie swój kod do rdzenia skryptu (tak jest w SimpleMachines forum), albo doda odpowiedniego hooka, który da znać wtyczkom e, panowie formatujący tekst, wystąp, jest <TO I TO> do przeparsowania, czekam na wynik, zwracam go do skryptu.

O ile pierwsze rozwiązanie jest dużo wydajniejsze (nie ma konieczności odpytywania funkcji przechowującej odwołania do wtyczki), to jest bardziej problematyczne w utrzymaniu porządku i powoduje nieraz sporo konfliktów, czy uniemożliwia instalację innych wtyczek realizujących swoje funkcje w tym samym miejscu.

A jak masz odpowiednie hooki, to tak, jakbyś miał firmę przewozową i chciał kilkoma usługami oznaczać paczki. (koloryzując ) jeśli oferujesz każdemu klientowi możliwość znakowania wszystkich swoich paczek własnymi identyfikatorami, robisz dla nich miejsce przy taśmie, oni rozpoznają swoje i doklejają do przesyłki. Ale mają tam swoje miejsce - paczki będą jechały dalej nawet jeśli delikwenta nie ma.

Jeśli nie masz, no to jest problem - trzeba kombinować, bo nie wiadomo, gdzie postawić tego klienta, żeby mógł swobodnie i bezpiecznie znakować swoje przesyłki.

No to teraz mój post ;>
Prosty przykład - mały plugin dodający możliwość komentowania profilu:
Przed http://img811.imageshack.us/i/przed.png/
Po http://img683.imageshack.us/i/35321783.png/
Czy to oznacza, że aby umożliwić potem komuś zrobienie takiej wtyczki, która pokaże się w profilu użytkownika gdzie tylko chce (choćby jako pierwsza rzecz, nad awatarem itd.) muszę właśnie tam wstawić hooka? Czy to oznacza, że kolejne sekcje i skrypty muszę być przeplatane hookami? Teraz coś o mechanice strony - system template i języków. Opracowałem własne, banalne ale dla mnie wystarczające rozwiązanie.
Będziemy pracować na przykładzie środkowej części strony - tam gdzie jest treść itd.). Nie ważne czy jest wczytywana podstrona czy nie cały kod html i cała treść jest przypisywana zmiennej $tresc['srodek'] za pomocą ".=" (czyli jedno pod drugim co daje mi ogromną zmienną $tresc['srodek']). W takim razie jak wstawić kod html i treść modułu gdzieś w środek tej zmiennej? Pomiędzy treści? Razem z całym hookiem?

W skrócie - tak.


Zmień system szablonów. Marnujesz tylko pamięć, ciężko o optymalizację i dodawanie czegoś z zewnątrz.


Jw: wymagałoby to pisania w chorobę replace'ów i niepotrzebnych wyrażeń regularnych.

Puki co nic innego strukturalnie nie umiem napisać a skomplikowane klasy templatów to dla mnie za dużo. Odpadają też systemy typu smarty

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.

Rozwiązanie świetne, ale nie pasuje do mojego cms'a. Nastawiony on jest na jak najbardziej uproszczone korzystanie, bez ingerencji użytkownika w kod (w końcu korzystać mogą osoby, które z instalacją moda w ten sposób mogły by sobie nie poradzić). Najprawdopodobniej zostanę przy hookach Teraz tylko znów męczy mnie ta obiektówka :/ Sam wiem, że większość systemów cms jest w niej pisanych, i to naprawdę najlepsze rozwiązanie. Trzeba będzie zrobić podejście nr 4 do programowania obiektowego, a nóż widelec się uda

W np. Drupalu wszystko jest strukturalnie oprócz DB.

Ale napisanie obiektowo systemu bardzo ułatwi zadanie.

No to chyba mamy sprawę zamkniętą Zastosuję te hooki, ale najpierw wspomniana obiektówka, trochę ćwiczeń i może uda mi się coś wymłodzić

Ja osobiście myślę, że najwygodniejszy byłby dla usera właśnie system paneli. Coś włącza tu, coś tam - jest ok to zostawia a jeśli nie - wyłącza. Zależnie od potrzeby chwili. Problem z tym, że nie wszystko da się łatwo. przykładem może być choćby bbcode. Tak naprawdę może on wystąpić w wielu panelach i jakoś musi być przemycony transparentnie, a powinien być jednolity. Przecież każdy panel chyba nie będzie implementował własnego silnika do tego. Po prostu musisz przewidzieć, że gdzieś w każdym z nich zajdą określone zmiany, których nie przewidzisz. Ustawiasz jakieś wykonanie warunkowe funkcji trzecich wewnątrz Twojego kodu i możesz ewentualnie modlić, że autor plugina czegoś nie spaprze Wiele osób uznałoby to za czarną magię, ale po MPI taki system "rozgłoszeniowy" dla mnie już jest w miarę zrozumiały i potrafiłbym pod owym kątem sobie zaprojektować szkielet CMS oraz jego pluginy.

Co ciekawe, to fakt, że wprowadzenie niemal pełnej równoległości procesów potomnych dla mnie osobiście byłoby całkiem fajnym dodatkiem, bo rozumiem ideę tego i przejście z sekwencyjnego wykonywania skryptu do równoległego nie było by trudne, choć zapewne starsi webmasterzy by ciężko mieli z przestawieniem się. W zasadzie gdyby nie SEO to wiele stron by można zrobić już teraz naprawdę bardzo dynamicznych przy użyciu AJAX + jquery. Zmiany paneli, drag& drop, pełna personalizacja serwisu (iGoogle jest czymś w tym stylu) i serwis żyje swoim życiem Ty tylko i jednocześnie aż udostępniasz pewne customizowalne opcje/elementy. Na etapie planowania/projektowania jest jazda pewna, ale potem użytkowanie byłoby o tyle fajne, że to osoba odwiedzająca ma całkowity wpływ na to co chce od naszego serwisu. Jedynie może złorzeczyć, że czegoś tam nie ma jako content lub nawigacja mniej wygodna, ale poza tym ma to czego dokładnie chce/co sobie ustawił.

Masz na myśli widgety?

Ale tu chodzi bardziej o wtyczki-filtry, więc muszą być hooki.

Otóż to, świetny przykład z tym BBCode, trudno to uznać za panel/moduł, bo ingeruje bezpośrednio w jądro systemu i zmienia jego funkcjonalność, dlatego to nie wchodzi w grę, jednak potraktowanie tego jako extension też ma ograniczenia, bo jak zapewnić elastyczność, integrację a jednocześnie wydajność przy prostym kodzie i procesie instalacji/deinstalacji? Dlatego lepiej to zrobić "na sztywno" z możliwością on/off w PA aplikacji, łatwiej wtedy zadbać także o wydajność, bo można bbcode wyłączyć po prostu globalnie.

Moim zdaniem dobrze byłoby ogarnąć temat na przykładzie dodatków do tak popularnych skryptów, jak forum phpbp by Przemo itp. Po zainstalowaniu wszystkich możliwych opcji skrypt osiąga masę krytyczną i imploduje pod własnym ciężarem, myślę, że najlepiej będzie zacząć właśnie od tego i poznać wady i ograniczenia różnych rozwiązań a potem opracować swoje.

Pilsener tak czytam Twój post i wpadłem na pomysł "kontry"
Uprę się przy tych hookach. Nie wiem jeszcze jak one działają (czekam na pewne rozwiązanie w tej sprawie - dopiero zacznę działać), ale zakładam, że każda wtyczka musiała by gdzieś na początku mieć ustalone do jakiego hooka "pasuję". Jądro wczytywało by sobie najpierw wszystkie modyfikacje a dopiero potem przypisywało do hooków. A jeśli takowy bbcode nie jest podpięty do żadnego to jądro po prostu go wczyta i on już będzie funkcjonował.Będzie wtedy poprostu wykonanym kodem (za pomocą inlcude). Więc jeszcze przed obsługą tekstu jądro powiększy się o ten jeden konkretny moduł. Całkiem możliwe, że nie zrozumiałem idei hooków a nawet tego co Wy mówicie ;D (przyznaje, część postów czytam z lekkim szperaniem po google ). Cały ten system wymaga gruntowenego zaplanowania raz jeszcze. Skłoniły mnie do tego słowa erix'a który skarcił mój system templatów, poza tym teraz czas na podejście obiektowe.

Uaktywniasz wtyczkę, sama zgłasza się sytemowi, co obsługuje. Podałem wcześniej przykład z Wordpressa - był to kod, który podpinał się pod konkretnego hooka.

[PHP] pobierz, plaintext 
add_action('post_publish', 'moja_zajekrzywabista_wtyczka');
[PHP] pobierz, plaintext 

jak rozumiem to jest właśnie odwołanie się do hooka post_publish i tam ma się "wpasować" metoda "moja_zajekrzywabista_wtyczka" ? No to w takim razie nie rozumiem co jest problemem

No ja tym bardziej, chyba że nie zrozumiałem, co chciałeś przekazać tym postem.

Raczej to ja się pogubiłem, a to co Wy piszecie jest dla mnie jeszcze zbyt skomplikowane Pogubiłem się w Waszej rozmowie, wiem tylko, że Ty radzisz mi hooki a co do reszty to już bladego pojęcia nie mam To już chyba nie mój poziom wiedzy

Ja u siebie rozwiązałem ten problem bardzo prosto. Wyszło to nawet modalne.

W jednym folderze, udostępniam modułom skrypty które mogę one wykorzystać załadować lub nie. Np. funkcje bazy, albo jakieś obliczające.

Każdy moduł jest w osobnym folderze. Wykorzystuje on tylko to, co ja mu podam w folderze z funkcjami. W obrębie tego łączy się z bazą robi to co chce i coś zwraca lub nie.

Mam też plik, który korzysta z modułów i pokazuje to co one zwracają wstawiając w klasę która tworzy szablon panelu.

I ostatni plik, jakby jądro do którego wskazuje pliki które korzystają z modułów.

~thomson89, chyba nie zrozumiałeś.

Nie chodzi o API, które umożliwia wykorzystywanie funkcji. Chodzi o dynamiczne rozszerzanie funkcjonalności przez wtyczki BEZ ingerencji w kod aplikacji.

Jak dla mnie jedyne sensowne wyjście to w szkielecie aplikacji faktycznie haki. Ustala się haki przykładowo dla modyfikacji tekstu i potem system sam sobie sprawdza jaki włączony plugin to obsługuje. Żaden? Nic się nie dzieje. Jakikolwiek? Wykonać go. Można jeszcze określić hierarchię. Czyli przykładowo smileys wykonują się zawsze przed bbcode lub na odwrót (mogą się gryźć).

Zawsze też uśmieszki mogą rozszerzać bbcode... W końcu to też podmienianie tekstu więc nie wiele się różnią. Postawiłem na obiektówkę i hooki Ktoś coś chce jeszcze dodać?

Tak się zastanawiam... AOP mogłoby chyba być całkiem fajnym sposobem na rozwiązanie problemu pluginów, ale to nie dla PHP progi... - taka luźna myśl.

ZuyPan. Mylisz się... A co jeśli smileye wystąpią wewnątrz tagów lub parametrów? Przypuśćmy, że masz emoticona ") i po przejechaniu bbcode masz fragment
<a href="" title=")-(">
Co wtedy się stanie?

Czekaj czekaj. Nie do końca rozumiem Twojego przykładu. Po co ktoś ma wstawiać emota w środku linku ? A nawet jeśli ktoś napisze takie coś w bbcode to przecież funkcja preg_replace podmieni wszystkie bbcodowe wyrażenia na normalne i link powinien wyglądać normalnie

Adres URL może zawierać w sobie ciąg " : D " (pisane bez spacji oczywiście) - przykładowo: http://example.com/profile/1:Dawid.html . BBCode nie powinno wtedy akurat tego zwrotu zamienić na graficzną emotikonę, tylko pozostawić to jako fragment URLa.

Ok teraz rozumiem. To fakt, byłby problem. W takim razie trzeba oddzielić działanie emotek od bbcode i ustalić wspomnianą hierarchię. W takim wypdku bbcode powinno mieć pierwszeństwo (linki) ale cytowanie czyjejś wypowiedzi gdzie pojawia się emotka nie było by problematyczne?

Nie tylko hierarchię by trzeba ustawić, ale tak napisać konwerter, by nie pchał się gdzie nie powinien, czyli do wnętrz tagów.

To można to załatwić tak, że kod sprawdza czy są jakieś dodatkowe foldery w folderze moduły, szuka tam pliku index, lub pliku z wstawką <!-- PLIK GŁÓWNY --> i dodaje se do bazy co potrzebuje.

Jeśli chodzi o implementacje haków to ja bym to zrobił na zasadzie zdarzeń. Dobrze pasuje tutaj wzorzec obserwatora. Wtyczka przy włączaniu kojarzyła by się jako obserwator pewnych zdarzeń(np. dodania artykułu) i w przypadku ich wystąpienia odpowiednio reagowała.

Poddaje się. Albo nie umiem korzystać z google (bo tam właśnie szukałem), albo ... (sam nie wiem co). Szukam co to są te hooki, jak się tego używa itd. Puki co nie znalazłem nic co je opisuje i mówi jak się ich używa :F Pomóżcie bo pasowało by w końcu wystartować

Jest chyba rozwiązanie pośrednie, między hookami a klikaniem. Za pomocą, php spróbuj zrobić kod który z panelu admina pozwoli tobie dodać hooka do jakiegoś elementu strony. Pokaże tobie on kod odpowiedniego modułu, pliku lub tekstu który ty podasz np. to textarea ty dodasz hooka i po sprawie.

Brawo.


A przeglądałeś źródła tych skryptów, o których pisałem?


Super rozwiązanie, zwłaszcza dla ludzi, którzy na słowo kod robią wielkie oczy.

Przemyślenie architektury, to zadanie projektanta aplikacji, a nie jej użytkownika, leniu.

Erix liczyłem raczej na jakiś kurs albo coś. Przyznam, że myszkowanie po całym kodzie jakiegoś systemu tylko po to aby znaleźć jak coś działa mi się nie uśmiecha (w obcym kodzie się gubię, często jest tyle "dziwnych" dla mnie rzeczy, że wyłączam zrezygnowany . Poza tym jak mam rozpoznać w gotowym kodzie, ze to coś akurat jest jakimś hookiem skoro nawet nie wiem czego szukać? )

Kursów nt. stosowania pluginów w aplikacjach jest nie za wiele, a już na pewno nie po polsku.

I understand many of sentences in english
Ale z tego co rozumiem z Twojego postu to:

[PHP] pobierz, plaintext 
add_action('jakis_hook', 'jakas_wtyczka');
function jakas_wtyczka(){
echo 'To jest wtyczka.';
}
[PHP] pobierz, plaintext 

Doda gdzieś w skrypcie w hooku napis: to jest wtyczka. W takim razie jak się deklaruje hooki i gdzie to robić?

Hook to określone miejsce w kodzie aplikacji/klasy/funkcji, które wykorzystujesz jako miejsce dołączenia zewnętrznych funkcji choćby. Tutaj właśnie się przydaje call_user_* Sprawdzasz czy jakaś funkcja nie jest przydzielona do tego określonego. Jeśli jest robisz ją, jeśli nie, lecisz dalej.

Dawniej przy pisaniu aplikacji obsługującej PITy wymyśliliśmy inny sposób na implementację pluginów. Zamiast zastanawiać się jak i gdzie podczepić plugin do kodu, można użyć pluginu jako koordynatora dla modułu. Wystarczy moduł rozbić na atomy(funkcje) i jeżeli plugin istnieje pokierować atomami tak jak chce.

np.

plugin nie istnieje kontrole przejmuje moduł
Moduł wykonuje:
1. a();
2. b();
3. c();

plugin istnieje i przejmuje kontrole:
Moduł wykonuje:
1. c();
2. b();
3. a();
4. d();
5. e();

Zasadniczo męczące i strasznie czasochłonne jest samo pisanie modułów ale potem zwraca się to z nawiązką

Modularnosc HMVC poczytajcie kto nie wie o co kaman
Tak ogolnie mam moduly kazdy jest zbudowany na bazie MVC i jest podpinany w glowne miejsce poprzez front controller do glownego widoku, czyli mamy block controller(modul,plugin,widget) i front controller glowny kontroler aplikacji.
Plugin'y u mnie dzialaja na prostej zasadzie dziedzicza po kontrolerze od danego modulu rozszerzajac jego dzialanie z mozliwoscia zmiany widoku(wygladu) itp...itd...poprostu w jadrze najpierw patrze czy dane moduly napierw znajduja sie w folderze plugin czy modules i potem wlaczam.
Sa tez widget'y niczym sie nie roznia oprocz tego ze wyswietlaja statyczne tresci: kalendarz,zegar...

Ja mam to wlasnie za pomoca zdarzen proste przeladowanie metod __call() i call_user_* poprostu w core mojego fw przed odpaleniem modulu/pluginy sprawdzam czy nie istenieje jakis filtr na niego jesli tak mamy metody loading/pre/zwykla metoda/post/destroy i zwracamy kod html/xml czy jaki chcemy do glonej aplikacji

Zamotalem..?

@marcio: Twój sposób nie sprawdzi się w momencie gdy będziemy chcieli mieć dwa lub więcej pluginów dla danego "modułu".

No, czyli wzorzec proxy.


Niby tak, ale wystarczy handlery wrzucić do tablicy i ją pętlą każdorazowo sprawdzać. (cały czas mam na myśli proxy)

No ja wiem tylko u mnie plugin to nie dodanie nowej funkcjonalnosci tylko zmodyfikowanie starej i kazdy modul moze miec plugin.

tzn pod jeden modul nie podpina sie komentarzy i ocen tylko modyfikuje sie istniejacy modul i tyle az tak kombinowac mi sie nie chcialo nad srodowiskiem rozproszonym!Moze kiedys....