Witajcie,
Były już długie dyskusje o MVC, jeszcze dłuższe o budowie jądra...
Proponuje by rozpocząc dyskusje na temat, jak w naszej aplikacji umożliwić programiście piasnie dowolnych rozszerzeń. Chodzi mi o Pluginy.
Niektóre skrypty (phpBB) rozwiązują to na zasadzie zwykłej edycji kodu,
inne (WordPress) udostępniają specjalne API. Jak Wy widzicie budowe takiego systemu?
Powiesz szczerze, że nigdy nad takim czymś nie myślałem i nie robiłem nic w tym rodzaju więc w pierwszym poscie nie opisze swojego sposobu, bo go po prostu nie mam. Licze na Waszą inwencję i na to iż temat się przyjmie :]
Czyli podsumowując:
Jak stworzyć dobre API dla Pluginów.
Co rozumiesz jako plugin ? Uniwersalnego API dla pluginów w całej aplikacji nie napisz
Dla przykładu Blog który pisze teraz...
Plugin, np:
Kalendarz,
Modyfikator BBCode dla tekstu
i inne bzdety :]
Albo w formie koszyka do cms'a przekształcający go w sklep. Tak aby user nie musiał nic robić (w sensie modyfikacji kodu) tylko kliknął sobie i doinstalował plugin. Innym przykładem jest plugin komentarzy umożliwiający komentowanie obiektów (np. artykułów, newsów) W tej chwili jeszcze nad tym nie myślę ale za kilka dni/tygodni będę miał z tym kłopot.
jedyne co mi przychodzi do glowy, to kolejka.
Dodajemy kolejne pluginy do jakiejs kolejki i uruchamiamy jeden po drugim na danych wejsciowych.
np:
wyswietlanie obiektow - plugin przechwytuje caly obiekt TRESC, i ma za zadanie zamienic bbcode na html...
chcesz uruchomic ten plugin wrzucasz odpowiadnia klase do odpowiedniego katalogu a konfigurator sprawdza czy plugin istnieje jesli tak to go automatycznie uruchamia.
Osobiscie nie korzystam z tego rozwiazania - wogole nie korzystam z pluginow, bo nie wiedzialem jak sie do tego zabrac, wiec tak tylko teoretyzuje. Mam nadizeje ze ktos przedstawi lepszy poglad na to.
lecz hm. plugin do np: komentarzy dla newsow, czy jakiegos innego typu contentu, to trzeba by bylo przechwycic zdarzenie ze wyswietla sie news, pozniej dodac do tej strony w jakis sposob formularz, a dane z formularza do jakiejs akcji trzeba przeslac po czym wrocic na poprzednia strone - trzeba by bylo stworzyc po prostu dobra klase do pluginow, ktora w sobie mialaby mozliwosc przechwycenia aktualnei uruchomionej akcji, dodania "czegos" do strony w tym wypadku formularza, oraz dodania akcji ktora ma zostac pozniej uruchomiona. Glownie caly system pluginow musialby sie opierac o funkcje dostepne w systemie, a kolejny plugin, to po prostu wykorzystanie tych funkcji.
(cala powyzsza tresc zostala napisana przed chwila, nie wdrazalem tego rozwiazania - teoria wymyslona na szybko)
W projekcie Quick.Cart wykorzystalismy takie myslenie iz pluginy powinna robic osoba, ktora sie zna na kodzie php. Ma to kilka waznych argumentow:
- aplikacja bedzie dzialac poprawnie
- aplikacja ma nie byc zwalniania zbytnio przez pluginy (czym wiecej wyjatkow itd tym gorzej)
- aplikacja ma zachowac prostote i przejzystosc kodu
- pelna automatyzacja przez (przycisniecie klawisza "instaluj plugin") nie jest najlepsza. zbyt duze ryzyko wczesniejszej zmiany kodu przez uzytkownikow
Co prawda system pluginow przemyslelismy na szybko to do tego czasu nie dokonalbym zbyt wielu jego modernizacji
U nas dziala to w taki sposob iz kazda funkcje mozna zastapic gdyz przed jej nazwa podajemy if( !function_exists( 'nazwaFunkcji' ) ).
By sprawdzic dzialanie takich pluginow wystarczy sciagnac Quick.Cart'a i popatrzec sie jak to wyglada.
W tym projekcie powstalo kilkadziesiat pluginow NIE NASZEGO autorstwa z ktorym wielu sobie bardzo dobrze radzi i nie ma wiekszych problemow z ich instalacja.
Gdybym mial gwarancje, ze kod php nie bedzie zmieniany przez innych to stworzylbym automaty, ktore same zmienialyby kod php tak by aplikacja byla jeszcze wydajniejsza bez zbednych dodatkowych wyjatkow.
dodam jeszcze to, ze gdzies tu na forum ktos kiedys pisal o wlasnym systemie pluginow. taki cos, ze w jednym pliku definiuje co sie zmienilo, co gdzie dodac, co gdzie usunac i skrypt analizujac dany plik robi zmiany.
tutaj jest coś o pluginach
http://www.phpdeveloper.org/section/tutorials/55
co prawda mało profesjonalne, ale zawsze coś
pzdr
<?php class nowyPlugin implements pluginFactory { } ?>
Tak więc lekko odświeże temat. Czy komuś udało się już opracować jakiś system do obsługi wtyczek ?
Pozdrawiam
Obejrz sobie wtyczki w http://www.dotclear.netze.
pozdrawiam
polecam system pluginow rozwiazany w eclipse. Przejzec i przeportowac na wlasne potrzeby do php
ja pisze wlasnie teraz cos takiego a wlasciwie content manager z API do pluginow dla specializowanej zawartosci.
O co w tym chodzi:
Daje do dyspozycji strukture podzialu zawartosci plus jadra systemu z outputem (html,pdf,xml,txt). Oczekuje od pluginu udostepnienia wszystkich plikow zawarty w specyfikacji pluginow takich jak templates,config files itd.. oraz laduje plugin poprzez instanciowanie klasy o taj samej nazwie co plugin w podkatalogu znajdujacym sie w katalogu pluginow danego pluginu.
Ta classa (ten objekt) musi byc dziedziczona od mojego Interfaceu CMPlugin ktory daje nam funkcje do operacji takich jak przeszukiwanie , edytowanie,usuwanie,dodawanie oraz wyswietlanie zawartosci.
Projekt musze napisac do 17 Stycznia, wiec mysle ze po tej dacie udostepnie go.
Pozdrawiam
evo
Ja myśle, że nie będe używał żadnych BBCode (taką przynajmniej mam nadzieje), dlatego u mnie wszystko działa metodą łańcuchową, a system uruchamia się poprzez:
.
<?php $CORE->systemStart( new Application(), new HttpRouter(new HttpRequest, new HttpResponse) ); ?>
<?php class PluginManager { private http://www.php.net/static $map = http://www.php.net/array(); public function add($plugin, $parametr = false) { self::$map[$plugin] = ($parametr === false) ? $plugin : $parametr; } public function loadAll() { foreach(self::$map AS $plugin => $parametr) { if($plugin == $parametr) { $pl = new $plugin(); } else { $pl = new $plugin($parametr); } } } ?>
Ociu, ok, ale załadowałeś i co teraz zrobisz? Jak wpłyniesz na kształt czegoś?
Przed chwilą prześmyślałem to co napisałem i stwierdzam, że kod działa, ale jako loader załadowanie. Aby plugin był użyteczny, trzeba ingerować w kod klas.
Jak narazie to nie mam pomysłu.
do tego dochodzą jeszcze zaleznosci... bo mamy np. plugin komentarzy obiektow, i plugin bb codu... ale jako 2 osobne... jesli plugin komentarzy nie jest zainstalowany, to nie pokazujemy bb code w komentarzach, w przeciwnym wypadku pokazujemy. do tego przydalo by sie jakos konfigurowac, bo przeciez ktos moze nie chcec bb code w komentach, tylko np. w samych newsach czy gdziekolwiek indziej...
Pracuję właśnie nad framework'iem, w którym mam zamiar uwzględnić system ładowania pluginów.
W poprzednim CMSie plugin'em była po prostu klasa w jakimś module. Ale teraz dochodzę do wniosku, że poszerzę system katalogów modułu (wcześniej module/action) do module/submodule/action i jeden moduł będzie nosił nazwę 'plugins', gdzie będę mógł załadować potrzebne mi pluginy.
Potem tylko w edytorze template'a wpisuję odpowiednią linijkę ( np. <plugin>kalendarz</plugin> ), zmiany zapisywane są w pliku konfiguracyjnym i poprzez filtry (w moim przypadku services) sprawdzam w configu, czy do danego template'a jest przypisany jakiś plugin, dodaję do łańcucha akcji i tyle.
PluginManager również można tutaj wykorzystać zamiast np. action chain.
Generalnie możliwości jest sporo, wszystko zależy od budowy aplikacji. Nie ma jakiegoś uniwersalnego sposobu.
Co do zmiany bbcode na html, to najlepiej na filtrach (jeśli mowa o MVC przede wszystkim) - przed wykonaniem akcji sprawdzamy w konfigu, czy dana akcja ma być filtrowana (bbcode na html), jeśli tak, to po wykonaniu akcji pobieramy wynik kodu i filtrujemy.
A ja myślę, że trzeba trochę połączyć wszystkie te rozwiązania. Bardzo dobrym pomysłem wydaje mi się kolejka. To bardzo dobre rozwiązanie. Problem pojawia się jednak, gdy kilka pluginów dotyczy jednego rodzaju treści.
Ja bym zrobił tak. Jedną obiekt klasy Content, który będzie przechowywał dane wyciągnięte z bazy. Później zakładamy kolejkę, w której umieszczamy najpierw klasę odpowiadającą za podstawowe interpretowanie treści, a następnie kolejne pluginy (powiedzmy według przypisanej im wagi, bo to też czasem ważne). Później kolejno wywołujemy jakąś metodę (tak samo nazwaną we wszystkich klasach).
Konkludując. Potraktujmy podstawowe opracowywanie treści jako plugin o najwyższej wadze!
Co wy na to?
hm, mysle ze to jest sensowne, ale w chwili obecnej rozmyslalismy o pluginie ktory bedzie pelnil funkcje filtru na jakis content.
Co w wypadku gdy chcemy dograc plugin do koszyka ktory nam umozliwi platnosci online, chodz moze ograniczmy problem do dodawania nowych form platnosci. Wiec - mamy w systemie powiedzmy cos co pelni funkcje platnosci i mamy mozliwosc dogrywania w bardzo prosty sposob nowych form platnosci.
Jak to zrealizowac? Tez kolejka w ktorej bedziemy mieli liste platnosci, wybierzemy jedna, to uruchomimy odpowiednia klase, a wniej odpowiednie metody? Jak to sobie wyobrazacie?
Mysle ze warto by bylo omowic kilka takich problemow.
Pozdrawiam
A co jeśli chcemy napisać plugin do pluginu będącego pluginem innego pluginu naszej aplikacji? rotfl!
<?php Class PluginLoader { private $map = http://www.php.net/array(); public $loaded = http://www.php.net/array(); public function add($plugin, $parametr = false) { if($parametr == false) { $this->map[$plugin] = $plugin; }else{ $this->map[$plugin] = $parametr; } } public function load() { foreach($this->map AS $plugin => $parametr) { if($plugin == $parametr) { $this->loaded[$plugin] = new $plugin(); } else { $this->loaded[$plugin] = new $plugin($parametr); } } $this->map = http://www.php.net/array(); } } } ?>
<?php $PluginLoader = new PluginLoader(); $PluginLoader->add('Application'); $PluginLoader->load(); foreach($PluginLoader->loaded AS $name => $value) { $$name = $value; } ?>
A co jeśli pluginem jest wybieraniem odpowiedniej bazy danych ? Stopujesz go i cały system pada.
pozdrawiam
Ja pluginy w swoich aplikacjach rozwiazuje w inny, okreslony sposob i ktory dziala, nie bedac abstrakcja programistyczna
Mam w kodzie aplikacji miejsca uruchamiajace pluginy owszem nie moge ich miec w dowolnym miejscu kodu. Ale np uruchamiajac plugin koszyka moge z katalogu produktow zrobic pseudosklep - w sam plugin jest uruchamiany w dwoch miejscach. Kod html jest umieszczony dzieki komentarzom zawartym w danym templacie i prostemu str_ireplace. Ot cała filozofia
Uniwersalnego sposobu mysle nie ma. Ostatnio robilem serwis, ktory w oryginale byl goły... jednak w miare dodawania pluginow jego funkcjonalnosc sie rozszerzala: dodaj zdjecie, wiadomosci prywatne, i tak dalej...
Za najprostsze rozwiazanie uznalem stworzenie abstrakcyjnej klasy Plugin, klasy PluginManager ładujacej pluginy.
Ogolnie rzecz biorac przydaly sie wzorce projektowe Factory oraz Strategy. Zabawa przednia po prostu super milo, gdy programowanie sprawia przyjemnosc programiscie..
Mi sie udalo napisac system do obsugi pluginow w moim programie nad ktorym kiedys pracowalem
Ale jest jedna sprawa, niema uniwersalnej metody obsugi pluginow, bo w kazdym systemie pluginy sa do czegos innego, ale tak bardzo ogulnie jest jedan metoda:
zrobic tabele w bazie danych ktura przechowuje adres guwnego pliku z pluginem (php), i gowne class pluginu
oraz funkecje Main()
w ten sposow program bedzie includowal plik z pluginem, (ale ten plik niczego nie robu przed wywolaniem funkcji Main()), i wykona :
<?php $classname = // nazwa klasy plugina; call_user_func(http://www.php.net/array($classname, 'Main')); ?>
Myślę, że ta metoda nadaje się lepiej do flitrów niż do pluginów.
IMHO, filtry, to klasy, które muszą mieć metodę o danej nazwie, main, execute, perform etc. która jest wykonywana. Można narzucić tą metodę ( interfejsy i te sprawy ). Działała to na zasadzie użyj i zapomnij.
Pluginy, to klasy, które nie są czymś ograniczone, to klasy (można oczywiście to zrobić, to zależy od piszącego), które poprostu są dodatkami, np. BlockController, mamy do nich dostęp cały czas.
<?php class PluginManager{ protected $pluginsMap = http://www.php.net/array(); public function __get( $sPluginName ) { if(http://www.php.net/isset($this->pluginsMap[$sPluginName])) { return $this->pluginsMap[$sPluginName]; } else { throw new Exception('Plugin . ' $sPluginName ' . not found'); } } } ?>
ja robie w ten sposob:
Dajmy na to jest klasa $module, ktora jest baza dla wszystkich wtyczek (wtyczki ja extendsuja).
Do tego jest cos takiego jak kontroler modulow. W pliku startowym jest on inicjowany, includuje wlaczone wtyczki (globalna tablica z nazwami), tworzy odwolania w tablicy (jedna wtyczka = jeden element). Potem jest ona odpytywana ($wtyczka->init()), zeby sobie mogla poustawiac zmienne itp. (moglem dodac sprawdzanie, czy wtyczka jest na 100% do mojego systemu, ale pisze wtyczki tylko ja, to mi nie trzeba bylo ).
Potem (po inicjowaniu) odpalam metody run(), aby mogly sie zainicjowac niejako na drugim etapie (gdy sa zaleznosci pomiedzy modulami, np. wtyczka od sql).
Na dobranoc jest shutdown(); zapisuje dane, itp.
Pisane pod PHP4, proste, niezawodne i () dzialajace.
Ktos korzysta z wlasnych silnikow pluginowych w waszych dzialajacych ( nie eksperymentalnych ) projektach Patrzac na to co piszesz tutaj jestescie bardzo pracowici i kazdy z pomyslow wymaga duzo kodu by cokolwiek wlaczyc :|
mi podoba sie polaczenie Visitora z Componentem. lub jesli ktos chce to Observator.
Hej.
Myślę że tutaj z pomocą może przyjść Pico Container (Java) i port do php. Chyba Paweł Kozłowski z Supermedia to pisał. Samo rozszerzanie może bez problemu odbywać się na zasadzie wykorzystania wzorca Decorator - problem był w centralizowaniu dodawania(wstrzykiwania) w łancuch tworzenia zależności między obiektami właśnie tego plugin'u który nam potrzebny i rozszerzenia obiektu powyżej - Pico może to rozwiązać, ale narazie poza przeczytaniem ogólników nic więcej nie mogę powiedzieć, będę to testował - jak dojde do czegoś logicznego to napiszę.
pozdrowka
Ostatnio zastanawiam nad użyciem AOP w celu uzyskania funckjonalności pluginów.
W ten sposób bardzo prosto można dodać/tworzyć dowolne pluginy.
Przykład1: Plugin autoryzacji
<?php aspect Security{ pointcut modelConstruction:new(IModel(*)); pointcut modelExecution:http://www.php.net/exec(public IModel+::*(*)); around(): (modelExecution || modelConstruction){ //Przeprowadź autoryzację } } ?>
<?php aspect BBCodePlugin{ pointcut setArticleBody:http://www.php.net/exec(public Article::setBody(2)); after($body): setArticleBody{ return BBCodeParser::parseText ( $body ); } } ?>
Witam
W Rapide jest to ciekawie zrobione, możliwe są cztery rodzaje pluginów:
1. Przed uruchomieniem procesu wykonywania akcji
2. Przed wykonaniem każdej akcji
3. Po wykonaniu każdej akcji
4. Po zakonczeniu uruchamiania akcji
Załodowanie konkretnego pluginu:
<?php $oFront->registerPlugin(new Rapide_Controller_Front_Plugin_ACL); ?>
<?php class Rapide_Controller_Front_Plugin_ACL extends Rapide_Controller_Front_Plugin { public function preExecution(Rapide_Dispatcher_Token_Interface $oToken) { // operacje wykonywane przez plugin return $oToken; } } ?>
Hola, hola, powoli. Ale to co pokazałeś z Rapide to raczej Filtry i implementacja Intercepting Filter. W temacie chodzi o coś innego, przeczytaj jeszcze raz od początku.
Za pomocą czegoś takiego nie da się zrobić pluginu tylko filtr!
To mała różnica
Imho @nasty_psycho już dobrze kombinuje:
http://forum.php.pl/index.php?s=&showtopic=34190&view=findpost&p=260817
NuLL podał dobry przykład Wordpressa, jednakże pluginy sa jedynie ładowane a przy większej organizacji danych trzeba funkcje do templata wstrzykiwac samemu. Drobna uwaga to to, że dobrze jest to zrobione, że opcje same dodają się do górnego menu (super).
<?php $oNews = new News('id'); $oNews->loadPlugins(); http://www.php.net/echo $oNews->data->title; http://www.php.net/echo $oNews->data->text; ?>
<?php $oBBCode = $oPlugin->load('bbcode'); $oBBCode->parse($oNews->title); ?>
To ja też wtrące swoje 0,03 PLN.
Na początek napiszę że moje rozumowanie pluginów wzięło się z pisania w Delphi aplikacji będących serwerami COM. Także moje poniższe rozważania trochę są ukierunkowane w stronę COM aniżeli w stronę PHP takie zboczenie zawodowe.
Przede wszystkim należy sobie zdać sprawę że są różne rodzaje pluginów - pluginy ogólnego przeznaczenia i pluginy dedykowane jakiejś funkcjonalności. Te pierwsze jest dużo trudniej wprowadzić w życie.
Projektując system pluginów najpierw sobie musimy zadać pytanie do czego mają być te pluginy. Powiedzmy, że zbudowaliśmy jakiś system i chcemy dać możliwość rozbudowy go poprzez pluginy. Po pierwsze, najlepiej zabronić grzebania w kodzie głównym, gdyż to będzie powodowało destabilizacje pozostałych pluginów. Możemy kod główny, np klasy opatrzeć np w interfejsy i nakazać, żeby plugin korzystał tylko z tychże interfejsów. Warto uzewnętrznić zdarzenia np. w klasie TUser zdarzenia onLogin(...) onLogout(...) onRegister itd. W projekcie niech będzie powiedzmy singleton manager pluginów i taki taki singleton ma mieć dostęp do wszelkich instancji klas kodu głównego, czyli np Manager ma mieć dostęp do obiektu $user klasy TUser. Ponadto, każda instancja pluginu ma się zgłaszać do managera że się powołuje do życia.
Należy też wymyśleć i zdefiniować czym jest plugin, przykładowo plugin to jest obiekt takiej klasy, która implementuje interfejs IPlugin. Interfejs ten niech ma metody pozwalające sterować się managerowi. Manager przyjmował będzie zgłoszenia tworzenia nowych pluginów i będzie je dodawał do swojej listy, jednocześnie będzie miał możliwość coś zrobienia z każdym takim pluginem dzięki interfejsowi IPlugin.
Przykład:
Memy manager będący singletonem TPManager,
mamy obiekt użytkownika typu TUser.
Obiekt użytkownika udostępnia zdarzenie onLogin(..).
Manager ma pole $user, czyli np. TPManager::instance()->user;
Niech interfejs IPlugin ma metodę doOnRegister(..)
Tworzony jest obiekt - plugin, mający na celu jakąś reakcję na zalogowanie się, powiedzmy sprawdza czy user ma nowe wiadomości i je wyrzuca na ekran. Taki tworzony plugin zgłasza się do managera, manager go rejestruje na swojej liście. Dodatkowo, manager po dodaniu pluginu na listę wywołuje jego metodę doOnRegister(...), a ta metoda, odwołuje się poprzez manager do obiektu usera i rejestruje w nim swoje zdarzenie onLogin.
Teraz powiedzmy, że użytkownik się loguje, zatem wywoływana zostaje metoda powiedzmy TPManager::instance()->user->tryLogin(..). W tej metodzie jest kod logujący i w przypadku udanego logowania wywołuje $this->onLogin(). $this->onLogin wywołuje wszystkie zarejestrowane u siebie zdarzenia, czyli wywołuje zdarzenie z podłączonego pluginu, a to już sprawdza czy są nowe wiadomości i w razie czego wali je na ekran.
Ale natłukłem tekstu, ciekawe czy komuś będzie sie chciało tyle czytac
Pozwiodronka,
Zeman.
Dodam że sam nie korzystam z tego co opisałem Pluginowość załatwia mi plugin dyrektyw w moim edytorze PHP, tylko sobie klikam checkboxy które pluginy a właściwie moduły chce mieć w danym projekcie i ten mi wypluwa kod PHP okrojony z pozostałych pluginów, coś w rodzaju (na podstawie poprzedniego przykładu):
<?php class TUser { function tryLogin() { ... // logowanie {$IFDEF "modul_sprawdzania_wiadomosci"} ... // kod do sprawdzania wiadomości {$ENDIF} } } ?>
<?php outLogin() { $this->LoadPlugin('BBcode'); $this->oView->news_content = BBCode::Parse($this->oView->news_content); // bbcode $this->oView->news_content_long = BBCode::Smileys($this->oView->news_content); // emotikony w dlugiej czesci newsa } ?>
Witam nie przeczytałem wszystkich postów bo nie mam czasu teraz i moze sie powtórzę Ale chciałbym zauważyć wiele stron internetowych jest postawionych na czymś takim jak joomla! W joomla aby rozszerzyć możliwości tego framework'a wystarczy doinstalować nowe moduły lub komponenty, jako że pierwsze rozszerzają tylko funkcjonalność serwisu i nie wnoszą nowych modyfikacji, to te drugie w oparciu o API Joomla w dużym stopniu zmieniają działanie seriwsu i to co widzi użytkownik na stronie. Działanie tego elementu w joomla jest niemalże niezawodne, i sprawuje się doskonale, zapewne ma jakieś ograniczenia, ale wydaje mi się że implementowanie czegoś takiego jak moduły w joomla! jest w sumie dosyć proste i chcę taką rzecz za jakiś czas robić (oczywiście przy wolnej chwili), mam nadzieję że się uda.
witam, przepraszam ze odkopuje stare tematy, ale ten byl akurat na pierwszej stronie, a jego temat jest bardzo interesujacy.
mysle ze mozna bez problemu zorganizowac pluginy jednak trzymajac sie pewnego zalozenia: tworzymy swoj wlasny cms, i odgornie narzucamy mu konkretna strukture. tak np. modul news bedzie dzialal na zasadzie klasy, bedzie posiadal metody
- newsEdit
- newsDelete
- newsAdd
- newsDisplay
i tak, wewnatrz kazdej metody
A co jesli chcesz operowac na jakis danych zawartych w akcji ? Pozatym pisanie za kazdym razen metod plugins::before i after to raczej marne rozwiazanie.
W większości przypadków wystarczają filtry, poparte dobrymi nawykami programistycznymi (interfejsy, dobrym dobraniem strategii etc.)
Filtry ? To ja myslalem ze filtry sluza do czego innego ( czyt. filtrowania ) a plugin nie zawsze tylko czysci... Pozatym nawet gdyby - jak wywolac filtr na zmiennej zawartej w akcji ?
Nie czepiaj się, chodziło mi o powszechną implementacje Intercepting Filters w wielu, wielu frameworkach. Przykro mi, że nie zrozumiałeś.
Z mojego punktu widzenia to sa po prostu akcje przed i akcje po - niezależnie jak mądrze je nazwać ;p.
Takie rzeczy rozwiązuje sie moim zdaniem na poziomie frameworka, a nie CMS.
@Null - da się nawet taki bajer zobić, że możesz filtrować zmienne w akcji. Oczywiście nie lokalne zmienne metody, tylko zmienne, do których akcja się odwołuje. Z tego, co pamiętam, bo w swoim FW masz.
<?php $this->post->zmienna; ?>
Najpierw trzeba by jedną rzecz doprecyzować:
Są wtyczki [plugins] i są rozszerzenia [extensions]. Rozszerzenia to rzecz trochę bardziej ogólna, bo pozwalają na różne sposoby rozszerzać kod główny: np. dodając nowe inlcudy, dziedzicząc klasy interfejsów, dodając pliki językowe, szablony, filtry itp. Wtyczki to pewien podzbiór rozszerzeń.
Pluginy to inaczej wtyczki.
A jeśli jest wtyczka, musi też być i gniazdko
Gniazdkiem są tzw. "hooki" [haki? miejsca zaczepienia?], czyli przewidziane wcześniej miejsca w kodzie głównym, do których można podczepiać kod wtyczek. Tak więc jeśli chcemy mieć możliwość dołączania pluginów w skrypcie, to musimy od począku pisać skrypt pod tym kątem i zostawiać "hooki" dla wywołań pluginów w miejscach, gdzie przewidujemy jakieś możliwości rozszerzania. Jeśli piszemy w taki sposób, możemy łatwo dodawać pluginy, które podczepią się do tych miejsc i coś zrobią. Jednak kod główny [core] pozostanie niezmieniony.
@faster: Dobrze kombinujesz. Co do Twoich wątpliwości, jak można rozszerzyć działanie kodu głównego bez zmieniania go, odpowiedź jest prosta: polimorfizm. Jeśli kod główny jest napisany w taki sposób, by działał na ogólnych interfejsach, zamiast na konkretnych obiektach, można bardzo łatwo rozszerzyć system o nowe klasy, które będą pasować do wywołań tego głównego kodu i będą nadpisywać [nie dosłownie, lecz poprzez polimorfizm] jego funkcje. Hooki w stylu before() i after() to najprostszy przykład czegoś takiego. Większe możliwości daje jednak dziedziczenie i nadpisywanie metod interfejsów w klasach pochodnych [w innych językach zwie się to "funkcje wirtualne" lub "polimorficzne"].
Jeśli jednak chcemy zmieniać każdą możliwą część systemu, to system od podstaw musi być w taki sposób napisany, by wszystkie jego składniki były pluginami, a główny kod zajmowałby się jedynie ich ładowaniem i rejestrowaniem powiązań między nimi. To jest już trudniejsze do zrobienia [choć nie niemożliwe ] i wymaga dobrego przemyślenia. Może też być mniej wydajne, bo praktycznie wszelkie wywołania musiałyby być dispatchowane w tablicy zarejestrowanych usług.
I tu przyszedł mi do głowy jeszcze jeden problem: baza danych. Często jest tak, że pluginy także potrzebują przechowywać jakieś informacje w bazie danych. O ile dodanie dodatkowej tabeli z kluczami obcymi jeszcze jakoś da się w miarę łatwo zrobić z poziomu pluginu, o tyle już np. modyfikacja struktury istniejących tabel może być trudna, o ile wogóle ma to jakiś sens. Wie ktoś może, jak rozwiązywane jest dodawanie pluginów z rozszerzaniem struktury bazy danych? Bo aktualnie istniejące bazy danych są raczej mało "polimorficzne" ;J
P.S.: @nasty, @Athlan: Ale robicie byki, kupcie sobie słowniki ;P
skoro mowa o rozszerzeniach to czy widzicie jakieś bezpieczne sposoby na instalacje takowych rozszerzeń z poziomu użytkownika. Powiedzmy np że wchodzi do panelu w opcje rozszerzenia i sobie wyklikuje co mu tam potrzeba i voila.
Pokusiłem się o wklepanie odrobiny kodu. Jest on niekompletny, aczkolwiek daje pogląd na całą sprawę od strony źródeł. Całość oparta mniej więcej stanowi wyciąg ze źródeł http://www.osgi.org/ i http://eclipse.org przepisany do PHP.
Definicja "paczki", części aplikacji
<?php /** * Paczka działająca w otoczeniu aplikacji. Obiekty tej klasy są tworzone * przez framework a nie przez użytkownika. Nie musi on rozszeżać tej klasy * jest ona tylko zestawem informacji co się dzieje w runtime. * * @author Łukasz Dywicki <luke@code-house.net> */ class Bundle { /** * Pobranie usług jakie chce używać i udostępniać paczka. * * @return object[] Lista usług, bez określonego interfejsu. */ function getRegisteredServices() { return http://www.php.net/array(); } /** * Pobranie nagłówków z informacjami na temat paczki. * * @return Header Lista z unikalnymi nagłówkami. */ function getHeaders() { return http://www.php.net/array(); } /** * Pobranie informacji o stanie paczki. * * @return stan paczki (któraś z wartości stałych z IState). */ function getState(); } ?>
<?php /** * Nagłówek z infomacjami na temat wymagań paczki. * * @author Łukasz Dywicki <luke@code-house.net> */ class http://www.php.net/header { /** * Nazwa nagłówka. * * @return string Najlepiej z zakresu stałych ISupportedHeaders. */ function getName() {} /** * Wartość nagłówka. * * @return string */ function getValue() {} } /** * Lista domyślnych nagłówków, jakie są domyślnie wspierane. * * @author Łukasz Dywicki <luke@code-house.net> */ interface ISupportedHeaders { /** * Nazwa nagłówka z informacjami o zależnościach paczki. * W wymaganiach można podać również wersję w jakiej paczka * powinna występować. Brak informacji o wersji oznacza, że * paczka współpracuje z dowolną wersją. * * require-bundle = pl.dywicki.db: 0.5, pl.dywicki.view: 1.1 */ const REQUIRE_BUNDLES = "require-bundle"; /** * Informacje o dostawcy paczki. * * vendor-name = Łukasz Dywicki * vendor-url = <a href=\"http://dywicki.pl\" target=\"_blank\">http://dywicki.pl</a> * vendor-organization = Code-House.org */ const VENDOR_NAME = "vendor-name"; const VENDOR_URL = "vendor-url"; const VENDOR_ORGANIZATION = "vendor-organization"; /** * Informacje o paczce. * * bundle-name = pl.dywicki.view.explorer * bundle-version = 0.5.13 */ const BUNDLE_NAME = "bundle-name"; const BUNDLE_VERSION = "bundle-version"; } ?>
<?php /** * Kontekst działania rozszeżenia. * * @author Łukasz Dywicki <luke@code-house.net> */ interface IBundleContext { /** * Pobranie jakiejś usługi. * * @return object Interfejs nie jest określony */ function getServices(); // Fragment z listenerami do propagacji informacji. function addFrameworkListener(IFrameworkListener $listener); function removeFrameworkListener(IFrameworkListener $listener); function addBundleListener(IBundleListener $listener); function removeBundleListener(IBundleListener $listener); } ?>
<?php /** * Rozszeżenie jakiegoś extension pointa. * * @author Łukasz Dywicki <luke@code-house.net> */ interface IPlugin { /** * Uruchomienie pluginu. * * @param $context Kontekst w jakim działa plugin. */ function start(IBundleContext $context); /** * Zatrzymanie pluginu * * @param $context Kontekts, w którym działał plugin. */ function stop(IBundleContext $context); } ?>
<?php /** * Interfejs reprezentujący warunek, jaki powinien spełniać plugin. * * @author Łukasz Dywicki <luke@code-house.net> */ interface ICriteria { /** * Sprawdzenie czy plugin jest "ok". * * @param $plugin Implementacja rozszeżenia. */ function isValid(IPlugin $plugin); } // przykładowa implementacja class InstanceOfCriteria implements ICriteria { public function __construct(string $name) { $this->interfaceName = $name; } function isValid(IPlugin $plugin) { return ($plugin instanceof $this->interfaceName); } } ?>
<?php /** * Definicja nowego EP. * * @author Łukasz Dywicki <luke@code-house.net> */ interface IExtensionPoint { /** * Nazwa EP (opcjonalna). * * @return string. */ function getName(); /** * Identyfikator EP (obowiązkowy) * * @return Unikalny identyfikator EP. */ function getExtensionPointId(); /** * Warunki, jakie muszą spełnić pluginy, by być uznane * za poprawne rozszeżenia danego EP. * * @return ICriteria[] Lista warunków. */ function getCriteria(); } ?>
<?php /** * Centralny rejestr trzymający listę extension pointów. * * @author Łukasz Dywicki <luke@code-house.net> */ interface IExtensionRegistry { /** * Dodanie nowej definicji EP do rejestru. * * @param $point */ function registerExtensionPoint(IExtensionPoint $point); /** * Pobranie EP o danym identyfikatorze. * * @param $namespace Przestrzeń nazw rozszeżenia (np. pl.dywicki.content) * @return IExtensionPoint */ function getExtensionPoint(string $namespace); /** * Pobranie listy wszystkich EP. * * @return IExtensionPoint[] Tablica zawierająca EP. */ function getExtensionPoints(); /** * Dodanie listenera nasłuchującego zmian. * * @param $listener Ktoś, kto chce dużo wiedzieć. */ function addRegistryListener(IRegistryListener $listener); /** * Usunięcie listenera, który obserwuje zmiany w rejestrze. * * @param $listener Ktoś, kto już nie chce chce dużo wiedzieć. */ function removeRegistryListener(IRegistryListener $listener); } ?>
<?php /** * Interfejs reprezentujący stan paczki. * * @author Łukasz Dywicki <luke@code-house.net> */ interface IState { /** * Paczka zainstalowana. */ const INSTALLED = 0x01; /** * Paczka niezainstalowana. */ const UNINSTALLED = 0x02; /** * Paczka w fazie uruchamiania. */ const ACTIVATING = 1; /** * Paczka uruchomiona. */ const ACTIVE = 2; /** * Paczka zatrzymana. */ const STOPED = 3; /** * Paczka podczas zatrzymywania. */ const STOPPING = 4; } ?>
Moje rozwiązanie jest takie:
Archiwum (np. rar, zip itp.) {
- plik 1
- plik 2
- plik 3
- info.xml
}
Info.xml
<?xml version="1.0"?> <plugin> <folders> <create folder="nazwa folderu"/> </folders> <menu> <menu key="xD" link="page,testplugin"/> </menu> <files> <file unpack="ścieżka wyjściowa" name="nazwa z archiwum"/> </files> </files> </plugin>
@splatch - myslisz ze daloby sie to wykorzystac w PHP ? Zastanawiam sie jaki narzut kodu i czasu wynikalby z takiego rozwiazania Dzieki za ten kod - mi ciezko by bylo to wyciagnac a myslalem o tym ostatnio. Zastanawiam sie nad napisaniem jakies prostej aplikacji z tego korzystajacej - ale zobaczymy jak z czasem i czy wogole sie uda
Podepne sie, by nie zakladac nowego tematu.
Od jakiegos czasu pracuje nad systemem pluginow. W CMS, nad ktorym obecnie spedzam wiele godzin w pracy, poprzez plugin rozumie sie klase (lub ich zbior) odpowiedzialna za jakies dodatkowe, doinstalowalne funkcje (np system newsow, ktory mozna doinstalowac do zrodla i jego funkcjonalnosci beda dostepne w calym silniku). Mam juz dzialajacy instalator i ogolna obsluge takich paczek (usuwanie, aktywowanie, deaktywowanie, startowanie, restartowanie itd). Nie bede sie w to teraz zaglebial...
Stanalem jednak na rozdrozu, jesli chodzi o rejestr funkcjonalnosci. Zalozmy, ze klasa news zawiera kilka metod publicznych, jak np addNews, deleteNews, modifyNews, displayNews itd itp. Jednym z rozwiazan, na jakie wpadlem jest stworzenie z pomoca Reflection API rejestru metod publicznych, ktore dany plugin udostepnia i operowanie na nich w dowolnym miejscu systemu (Factory, Autoloading itd). Czyli rejestruje sobie moje funkcjonalnosci i pozniej, np w warstwie widoku tylko odwoluje sie do danej metody, np PluginManager::dispatch(nazwaPluginu, zarejestrowanaFunkcjonalnosc, argumenty) (to taki luzny bardzo przyklad). Mysle, ze to calkiem wygodne.
Moj PM wpadl jednak na karkolomny pomysl zdynamizowania zarejestrowanych uslug. Chodzi mu po glowie, by w panelu administracyjnym, gdzie wylistowane sa dostepne w rejestrze uslugi, po kliknieciu na dana nazwe metody dla danego pluginu od razu mozna bylo z tego miejsca go obsluzyc. Nie za bardzo wiem jak sie do tego dobrac, poniewaz musialoby to byc super-uniwersalne, jako ze dodawanie newsow rozni sie, powiedzmy od wyswietlenia lokacji na wtyczce Google Maps;] Spedzam drugi dzien na probie rozplanowania jakiegos Buildera formularzy, jednak co chwila wychodza jakies problemy zwiazane z uniwersalizacja takiego systemu.
Probowalem jakies diagramy UML na Decoratorze rozrysowywac, jednak jak dla mnie to ciagle za ogolne dzialanie, by to objac jakos sensownie bez miliona linijek kodu ;]
Jesli ktos rozumie, o co mi chodzi, to moze jakies pomysly wpadna do glowy?:_)
Jakiś czas temu naskrobałem sobie nawet dobry plugin system. Jego mechanika działania wygląda tak:
Jest aplikacja PHP zbudowana z kilku-kilkunastu klas.
Jest klasa Matrix - klasa bazowa, z której powinny dziedziczyć te klasy, w których mogły by się wczepiać pluginy.
Jej działanie jest takie: przed (on[nazwaklasy]_pre_[nazwafunkcji]) i po (on[nazwaklasy]_post_[nazwafunkcji]) wywołaniem metody jednej z klas aplikacji jest wywoływana metoda pluginu (metoda pre musi mieć zgodną liczbę argumentów co do funkcjiobsługiwanej - metoda post przyjmuje tylko 1 argument, wartość zwracaną przez funkcję obsługiwaną) o odpowiedniej nazwie która ma możliwość modyfikowania argumentów i wyniku funkcji.
Każda metoda która "chce" być obsługiwana przez pluginy powinna być protected lub private i zaczynać się od _ np.:
<?php class foo extends Matrix { //metoda koniecznie protected lub private poprzedzone '_' protected function _test($val) { http://www.php.net/echo '<br/>Test val:'.$val.'<br/>'; } } ?>
<?php $bar = new foo(); $bar->loadPlugin('test'); // ładujemy plugin, można załadować tylko raz! $bar->test(123); // wywołanie metody klasy foo, a zarazem odpowiednich metod pluginu ?>
@specialplan
A dlaczego interfejsu plugin'u nie dasz w jakimś pliku konfiguracyjnym, po co bawić się w Reflection API, niech plugin sam powie co oferuje.
Wtedy obsługa każdej funkcjonalności też jest zawarta w plugin'ie, bo tak na prawdę tylko ten plugin wie co ma zrobić.
Czyli system news'ów wie jak ma dodać nowego, jak wyświetlić lokalizację też sam plugin wie. System nie powinien zajmować się niczym więcej jak umieszczeniem danych z plugin'a w odpowiednim miejscu i przekazywaniu mu tego czego potrzebuje.
Klasa dziedziczaca po ReflectionClass sluzy jedynie do pobrania metod publicznych z danej klasy pluginu w celach wylistowania ich w panelu administracyjnym, by mozna bylo z poziomu formularza przypisywac dane funkcjonalnosci pluginu do, chociazby, konkretnych stron widoku. W zasadzie mozna by umiescic te same dane w pliku konfiguracyjnym, ale zdecydowalem sie na tworzenie ich "w locie". W zasadzie system "robi" wszystko, co napisales, wiec chyba przekonam mojego PM, ze nie ma sensu sie bawic w dynamizowanie rejestru.
Framework http://flow3.typo3.org/ (który będzie służyć za bazę dla najnowszego TYPO3) poszedł o krok naprzód w "pluginizacji" aplikacji - używa aspektów.
Wydaje mi się, że warto na niego spojrzeć w kontekście tego tematu.
Pozdrawiam.
edit:
Dodam tylko, że FLOW3 nie używa zewnętrznych bibliotek AOP (Aspect Oriented Programming) - wszystko jest oparte o czystą implementację w PHP.
Troszke bardzo odkopię
Może zle to wszystko zrozumialem, ale wiekszosc opisanych sposobow wtyczkowania mozna by prosto zastapic prostym wstawieniem include przed wyświetleniem odpowiedniej trsci...
myslalem sobie zeby podzielic strone na minisekcje (w gruncie rzeczy calkiem sporo ich by musialobyc) - np 'htmlheader', 'pageheader', 'menu', 'leftcolumn', leftcolumncontent' 'rightcolumn'.... 'gallerylist' 'galleryimagelist'... itd i trzymanie ich w zmiennych. Dalej wykorzystujac "hooki" (http://stackoverflow.com/questions/42/best-way-to-allow-plugins-for-a-php-application) dla kazdego z elementow wykonywac odpowiedniego hooka lekko go modyfikujac wzgledem tego artykulu.
I tak mamy atrzymalibysmy tablice sekcji sekcje[sekcja] oraz dwuwymiarowa tablice hookow w postaci plugin[sekcja][funkcja z hooka1,funkcja z hooka2...] no i pozniej cos w rodzaju:
foreach (sekcje => element)
if isset plugin[element]
foreach plugin[element] => funkcja)
funkcja();
Zastanawialem sie rowniez jakby mozna bylo to zoptymalizowac - konieczne byloby "cachowanie kodu wtyczek php" tzn - wtyczki mozna byloby wlaczac i wylaczac - po wlaczeniu wtyczki tworzony bylby plik cacheplugin.php zawierajacy "body" plikow wlaczonych wtyczek - ograniczyloby to zbedne przeszukiwanie katalogow w poszukiwaniu wtyczek do inicjowania i otwierania tych calych mas plikow.
A zeby wtyczki staly sie naprawde wtyczkami uzytkownik dostalby narzedzie do tworzenia wlasnych minisekcji poprzez np dodanie odpowedniego kodu cos ala template {#zrobmigalerie#} i tutaj pojawi sie problem rekurencji bo należałoby po kazdym odpaleniu wtyczki dla danej minisekcji odpalic cala liste od nowa bo moze sie okazac ze ostatnia wtyczka doda sekcje do ktorej dedykowana byla pierwsza opalona funkcja... ale mysle ze to juz bardziej problem implementacji calosci
Chcę to napisac i dla tego sie chcialem spytac co o tym sadzicie?
Witam!
Chciałbym zasięgnąć waszej rady odnośnie pluginów. Aktualnie tworze własnego cms i mam zamiar oprzeć go o pluginy. W moim systemie występują szablony, moduły i pluginy. Szablony jest to ogólny widok, w odpowiednie miejsca umieszczamy zmienne (zastosowanie smarty). Ważniejszą rolę odgrywają moduły, jest to treść przekazana do szablonu w jedną ze zmiennych. W modułach jest możliwość ustawienia "zaczepu" do plugina
W pluginie zwracam treść która ma być wstawiona w to miejsce oraz sam plugin posiada uchwyt do szablony dzięki czemu mogę go dowolnie zmieniać z poziomu pluginu. Wywołanie pluginu następuje przed pasowaniem smarty a sam kod
{module name="gallery" action="index"}
zamieniany jest na zmienną w której jest wynik działania modułu. Czy taki schemat jest dobry, czy macie jakieś porady? Poza tym myślę nad wprowadzeniem kolejki, dzięki czemu mógłbym wykorzystać takie moduły jak autoryzacja wybranych modułów czy pluginów. Z góry dziękuje z pomoc.
{module name="gallery" action="index"}
if($auth -> isLogged()) { } else { $this -> forward('Authorization'); // lub $this -> forward('Authorization', 'Index'); }
<http://december.com/html/4/element/div.html>%lewemenu%</http://december.com/html/4/element/div.html>
Kolejka po to gdyż autoryzacja, logowanie itp. będzie również jako moduł który trzeba wywołać w odpowiednim momencie.
Moze ktos wytlumaczy jaka jest roznica pomiedzy kolejka zadan a robien forward() na dana akcje?
Musialbym to widziec w praktyce bo tak zabardzo nie jestem przekonany.
CHcialem jeszcze poruszyc temat o plugin'ach jako filtry.
Dokladnie do postu: http://forum.php.pl/index.php?s=&showtopic=34190&view=findpost&p=347026 ktory wydaje sie najbardziej rozwiniety z tego teamtu jesli chodzi o filtry.
Tak jak mowilem wczesniej mam jeden glowny szablon gdzie sa wstrzykiwane wszystkie komponenty/pluginy/widgety i do tego mam klase ktora sprawdza czy dla danego komponentu/pluginu jest jaki filtr powiedzmy ze mamy komponent News a w nim metode ShowLastNews();
public function ShowLastNews() { //wszystkie operacje pobierania etc.... return $txtNews; }
<?php class PFNews { public $ReturnTrueFunction = false; // wyswietlamy wynik zwracany poprzez metode komponnetu/klasy lub false gdy wynik filtru public function onLoad() { // Przed zaladowanie komponentu/pluginy return 'Poczatek<Br>'; } public function on_News_pre_ShowLastNews() { // przed funckja Index komponentu/pluginy News return 'Przed funckja index<Br>'; } public function on_News_post_ShowLastNews($html) { // po wykonaniu funckji Index komponentu/pluginu News tutaj robimy nasz bbcode dla prawdziwej zawartosci news'a return '<Br><b style="color:#FF0000;">'.$html.'</b>'; } public function onUnload() { // Przed zakonczeniem dzialania filtru return '<Br>Koniec<Br>'; } } ?>
<?php class Home extends Controller implements IController { public function __construct() { parent::__construct(); } public function Index() { $components = $this -> Home_Model -> getComponents($this -> routing -> getController()); $componentsAction = $this -> routing -> getParams(); $componentsAction = (http://www.php.net/count($componentsAction) == 0) ? 'Index' : $componentsAction[0]; $tab = $this -> plugins -> LoadPlugin($components, $componentsAction); $this -> view -> AddVars($tab); http://www.php.net/echo $this -> view -> Layout('Home', 'view'); } } ?>
W serwisie istnieje akcja X oraz plugin Y,Z. Plugin Y odpowiada za autoryzacje (logowanie itp. sprawy), Z odpowiada za wyświetlanie formularza kontaktowe. W pluginie Y ustawiam aby został wywołany przed akcją X. Czy muszę przed każdym wywołaniem akcji ładować kolejki wszystkich pluginów aby sprawdzić czy któryś nie powinien zostać wywołany, oraz jak wygląda sprawa kolejności ich wywoływania ?
EDIT:
Zle zrozumialem o ta kolejke chodzi o to: http://forum.php.pl/index.php?s=&showtopic=34190&view=findpost&p=194058 czyli lancuchy akcji u mnie dziala to wlasnie mniej wiecej tak sorki ale na poczatu chyba przeczytalem bez zrozumienia.
Dziala to u mnie tak kolejka + filtry dla komponentow/pluginow:
<?php require_once('libraries/PluginFilter.php'); class Plugin { private $cfg; public function __construct() { $this -> cfg = Loader::load('Cfg'); } public function LoadPlugin($plugins, $action) { foreach($plugins as $key => $PluginName) { if(http://www.php.net/file_exists(DIR_PLUGINS_CTRL.$PluginName.'.php')) { require_once(DIR_PLUGINS_CTRL.$PluginName.'.php'); } else if(http://www.php.net/file_exists(DIR_COMPONENTS_CTRL.$PluginName.'.php')) { require_once(DIR_COMPONENTS_CTRL.$PluginName.'.php'); } else { Controller::Error(405); } $obj = new $PluginName(); if(PluginFilter::CheckFilter($PluginName)) { $html[$key] = $obj -> LoadFilter($PluginName); $PluginAction = (method_exists($obj, $action)) ? '_'.$action : '_'.$this -> cfg -> action; $html[$key] .= $obj -> $PluginAction(); $html[$key] .= $obj -> RemoveFilter($PluginName); } else { $PluginAction = (method_exists($obj, $action)) ? $action : $this -> cfg -> action; $html[$key] = $obj -> $PluginAction(); } } return $html; } } ?>
Wzorzec obserwatora i wszystko jasne
Temat, pluginów zależy od struktury systemu do którego chcemy go zastosować.
Po pierwsze trzeba określić strukturę naszego systemu, i wydzielić obszary na które mogą mieć wpływ pluginy.
Trzeba stworzyć abstrakcyjne klasy (dziedziczącę po abstrakcyjnej klasię np. Plugin), które będą miały wpływ na poszczególne sekcje w naszej aplikacji.
abstract class Plugin { }
abstract class PluginUsers extends Plugin { public function showUser(UserModel $user, View $view) {} public function showUserList(UserModel $user, UserList $list, View $view) {} public function preSaveUser(UserModel $user) {} public function postSaveUser(UserModel $user) {} public function preLoginUser(UserModel $user) {} public function postLoginUser(UserModel $user) {} public function preLogoutUser(UserModel $user) {} public function postLogoutUser(UserModel $user) {} // ... itd }
Cos takiego jest sprytne, moze nie jest to porzadny system pluginow, ale moze ulatwiac sprawe przy pisaniu dodatków.
public function loadInjections($name) { if(http://www.php.net/is_dir("injections/$name")) foreach (http://www.php.net/glob("injections/$name/*.php") as $injection) { include_once($injection); } else throw new exception("Could not load injections! Event Folder not found. ErrCode: 172610032010"); }
Ja robię to nieco inaczej. Dodatki dzielę na "Language Pack", "Blocks" i "Modules".
Sprawa z "Language Pack" jest jasna (includuje plik z tłumaczeniem, które jest zawarte w tablicy).
"Blocks" to w moim przypadku bloki w menu, wygląda to tak, że folder z blokiem zawiera jeden plik z "kodem", a drugi, co ma wypisywać na stronie, to coś w stylu np: code.php zawiera klasę kalendarza, a index.php (w katalogu z blokiem ją inicjuję. Cały system jest bardzo prosty, funkcja obsługująca po prostu za każdym razem robi funkcję blockopen($tytuł_bloku_podany_w_PA), potem następuje zincludowanie index.php, a na końcu blockclose(). W panelu admina można dowolnie tworzyć bloki, nawet takie, które nie mają pliku code.php, bo zawierają np tylko informację typu "Dziś jest głosowanie...". Każdemu blokowi przydziela się id na podstawie którego jest pozycjonowany wyżej lub niżej innych bloków. Z poziomu panelu jest też możliwość dowolnej edycji kodu, jakby ktoś nie chciał się bawić w wrzucanie przez ftpa.
Z "Modules" sprawa jest troche bardziej skomplikowana. W kodzie modułu określone jest jakiego "typu" on jest, czy to plik zincludowany, który wykonuje tylko jakiś kod (np tworzenie logów i statystyk), czy też np. skrypt, który ma być umieszczony np nad stroną główną (pod logo strony, np losowanie cytatów), pod stroną, czy też jako strona inicjowana zmienną "modid", który po wpisaniu index.php?modid=3 przejdzie na wybraną stronę. Linki typu "modid" trzeba dodać samodzielnie, ale myślę, że jak się już dokończę moje wstępne kodzenie core.php to zrobię jakąś większą klasę z mini-api, które będzie mogło też dodawać linki do menu, a może nawet ingerować w inne bloki i moduły.
Witam czy ktos z was na dzien dzisiejszy zaimplementowal w pelni dzialajace pluginy w swoim systemie?
Poki co mam zaimplementowane komponenty i widget'y w pelni dzialajace razem z obsluga gosci czy cache'm calych ich ackji/blokow.
Zastanawiam sie nad pluginami(jako wtyczki do komponentow) czyli taki plugin komentarzy ktory mozna podpiac pod komponent News/Article/ForumPost o ile tego typu plugin nie sprawia mi raczej klopotow w jego implementacji to mam problem np z plugin'em Ankiety np.
Jak podpiac taki plugin ankiety pod news podczas pisania/edytowania danego wpisu?
Na jakiej zasadzie mam obsluzyc 2 formularze(1 do napisania/edycji news, 2 do ankiety)?
Samo "wstrzykniecie" takiego formualrza tez nie sprawia mi klopotu jednak nie wiem zbytnio jak obsluzyc 2 akcje naraz.
W przypadku komentarzy nie ma takiego problemu bo czytajac news dodajemy sam komentarz do niego i jest ok, jednak dodac news'a jak do niego dodac ankiete lub inny plugin?
Dla kazdego pluginu wydzieliłbym przestrzeń danych (tak żeby dane z POST/REQUEST nie nachodził na siebie).
np żeby plugin "a" miał nienachodzące się nazwy z pluginem "b" czy też samym głównym procesem -> $_POST['plugin_a']['nazwa_ankiety'], $_POST['main']['nazwa_newsa']
Dodać akcje przygotowawcze (pre) i wykończeniowe (post) tak, aby wywalić błędy i przerwać główny proces (jw. dodać newsa/komentarz), a potem przesłać pełny kontekst głównego procesu do pluginu aby dalej obsłużyć żądania (post).
Problemem jest sam moment uruchomienia pluginu, czy ma być wczytywany zawsze (z konfiguracji), czy też doczytany w pewnym konkretnym momencie (uzupełnienie strony przez XHR?)
W tym wypadku, główny proces nawet nie musi wiedzieć że będą uruchamiane jakieś pluginy, bo będą to akcje poboczne (tak jak w obserwatorze, podpiętym do danego typu zdażenia).
<?php /** *Volta framework *@author marcio <opi14@op.pl>, <polishvodka7@gmail.com> *@copyright Copyright (c) 2012, marcio *@version 1.0 */ $configs['guest'] = 1;//1 - on / 0 - off $configs['cache'] = 0;// 1 - on / 0 - off $configs['cached_action'] = http://www.php.net/array('Index'); $configs['lifetime'] = 10800;//time in sec $configs['admin_panel'] = 1;//1 - on / 0 - off $configs['plugins_settings'] = http://www.php.net/array( 'after' => http://www.php.net/array('readNews' => http://www.php.net/array( 'comment' => http://www.php.net/array( 'segment_ref' => 0, 'actions' => http://www.php.net/array('submit', 'delete') ) ) ) ); return $configs; ?>
generalnie pluginy opiera się na tzw hookach (tak mi się zdaje), ale jak rozwiązać problem zapytań sql, np jakiś plugin chce pobrać dodatkowe dwa pola w zapytaniu, bo nie zawsze używa się SELECT * tylko zamiast * daje się wyliczenie pól
Hooki/Eventy uzywam do innych czynnosci, choc np 4programmers stoi na coyote mam jego kod zrodlowy i tam uzywaja hooki do odpalania wszystkiego o ile sie nie myle.
Moj blog ktory mam w stopce ma zaimplementowane widget-y, komponenty i plugin-y dla nich.
Sa one wpelni dzialajace, z powodu braku czasu bo teraz mam praktyki w firmie jako programista projekt porzucilem jednak mam napisanych kilka komponentow i 2 plugin-y dla nich.
I rozwiazanie dziala.Moze na dniach tam to do oceny tez jestem ciekawy co inni powiedza na moje rozwiazanie, nawet ze mam liste ToDo co jest do zmiany/poprawy jednak wiekszosc funkcjonalnosci juz jest wiec mysle ze pokazac mozna.
Chętnie bym zobaczył
Poczekaj jeszcze miesiac, postaram sie dokonczyc projekt jesli chodzi o backend i funkcjonalnosc.
a jak wpływać na metody klas, np załóżmy, że mamy model User, w nim metodę addUser, jak zaprojektować pluginizację i modele tak aby plugin mógł wpływać na dane wpisywane do bazy, np podczas dodawania użytkownika dopisać jakieś do zapytanie INSERT
@mrWodoo: to chyba tylko przez hooki, i przed wrzuceniem do bazy, wywołać wszystkie podpięte akcje podpięte do zdarzenia dodania użytkownika, i tak obrobione dane dopiero zapisać
function addUser($dane) { foreach($this->_AutomatyczniePobaranListaAkcjiDoDodaniaUsera as $akcja) $dane = call_user_func($akcja,$dane); return $this->insert($dane); }
@mrWodoo: Zdarzenia i jakiś sensowny event dispatcher z obsługą priorytetów:
public function addUser(UserInterface $user) { ... $event = new Event($user); $this->eventDispatcher->dispatch('costam.pre_add_user', $event); $user = $event->getData(); ... $event = new Event($user); $this->eventDispatcher->dispatch('costam.post_add_user', $event); ... }
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)