Aplikacje PHP - Pluginy Opcje

[Vengeance]

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.

[NuLL]

Co rozumiesz jako plugin ? Uniwersalnego API dla pluginów w całej aplikacji nie napisz

[Vengeance]

Dla przykładu Blog który pisze teraz...

Plugin, np:
Kalendarz,
Modyfikator BBCode dla tekstu
i inne bzdety :]

[ebe]

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.

[Ace]

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)

[treewood]

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.

[treewood]

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.

[mynio]

tutaj jest coś o pluginach
http://www.phpdeveloper.org/section/tutorials/55

co prawda mało profesjonalne, ale zawsze coś

pzdr

[ennics]

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.

hmm, myślę że dałoby się ten problem rozwiązać poprzez określenie interfejsu dla danych pluginów np. proste

[PHP] pobierz, plaintext 
<?php
 
class nowyPlugin implements pluginFactory { }
 
?>
[PHP] pobierz, plaintext 

interfejs pluginFactory określałby funkcje które użytkownik musi zaimplementować do swojego pluginu.
dodatkowo można ograniczyć ingerencję pluginów w nasz kod poprzez deklarację
metod które chcemy chronić jako private.

[Diwi]

Tak więc lekko odświeże temat. Czy komuś udało się już opracować jakiś system do obsługi wtyczek ?

Pozdrawiam

[Ociu]

Obejrz sobie wtyczki w dotclearze.
pozdrawiam

[evo]

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

Ten post edytował evo 14.11.2005, 22:52:04

[Ociu]

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] pobierz, plaintext 
<?php
$CORE->systemStart( new Application(), new HttpRouter(new HttpRequest, new HttpResponse) ); 
?>
[PHP] pobierz, plaintext 

.
Dlatego myśle, ze można coś zrobić tak:

[PHP] pobierz, plaintext 
<?php
class PluginManager {
private static $map = 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);
}
}
}
?>
[PHP] pobierz, plaintext 

Myśle, że to najprostrze rozwiązanie jakie może być i do tego dobre
pozdrawiam

[bela]

Ociu, ok, ale załadowałeś i co teraz zrobisz? Jak wpłyniesz na kształt czegoś?

[Ociu]

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.

[ActivePlayer]

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...

[Degregar]

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.

[seaquest]

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?

[Ace]

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

[Vengeance]

A co jeśli chcemy napisać plugin do pluginu będącego pluginem innego pluginu naszej aplikacji? rotfl!

[Ociu]

A co jeśli chcemy napisać plugin do pluginu będącego pluginem innego pluginu naszej aplikacji? rotfl!

To wtedy trudniamy sobie życie

Pisząc PluginManager stweirdziłem, że najlepiej będzie zrobić sam loader.

[PHP] pobierz, plaintext 
<?php
Class PluginLoader {
private $map = array();
public $loaded = 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 = array();
	}
}
}
?>
[PHP] pobierz, plaintext 

Można to użyć tak:

[PHP] pobierz, plaintext 
<?php
$PluginLoader = new PluginLoader();
$PluginLoader->add('Application');
$PluginLoader->load();
foreach($PluginLoader->loaded AS $name => $value) {
			$$name = $value;
}
?>
[PHP] pobierz, plaintext 

Kod troszke badziewny, pisany z palca. Jak anrazie działa, będe go przebudowywał.
PS. Pisząc ten post, pomyślałem o tym, że można by zamieszać w to iteratory

[LBO]

A co jeśli chcemy napisać plugin do pluginu będącego pluginem innego pluginu naszej aplikacji? rotfl!

wydaje mi sie ze trzeba stworzyc jeszcze klase (lub zaimplementowac w loaderze) kontrole zaleznosci... czyli np. plugin daje komunikat o braku potrzebnej mu do dzialania klasy stopuje skrypt... lub nie laduje sie wcale i wpisuje blad do logów.. no czy cos w tym rodzaju

[Ociu]

A co jeśli pluginem jest wybieraniem odpowiedniej bazy danych ? Stopujesz go i cały system pada.

pozdrawiam

[sztosz]

A co jeśli chcemy napisać plugin do pluginu będącego pluginem innego pluginu naszej aplikacji? rotfl!

Tutaj chyba taki pattern jak Decorator by dał radę.

Moim zdaniem nie da się zaimplentowac jakiegoś generalnego API dla pluginów.

Jeden moduł służący jako kontroller pluginów który nie pozwoli m.in używać dwóch różnyych pluginów robiących to samo ale w inny sposób.

+

Bardzo przejzysty kod (oczywiście wszystko obiektowo) z bardzo jasnym rozdzieleniem częsci protected od private każdej klasy.

+

Pluginy jako rozszerzenia danych klas (extends) zastepujące dane klasy (ichh funkcje w kodzie i wywołania)

ALBO (co jest chyba ciekawsze)

Plugin jako Decorator tylko że ttu z implentacją będzie bardzo trudno

[NuLL]

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

[LBO]

A co jeśli pluginem jest wybieraniem odpowiedniej bazy danych ? Stopujesz go i cały system pada.

heeh, zakladam podzial aplikacji na elementy CORE i dodatkowe (rozszerzenia funkcjonalnosci)... wtedy mozna sie pobawic w sposob dwojaki: dla elementow CORE zrobic dla pluginow API, dla rozszerzen loader'a... w sumie nie bawilem sie w pluginy (chociaz nagminnie stosuje loadery baz danych factory patternem, a to mozna juz nazwac pluginami)...

[em1X]

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..

[nasty]

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] pobierz, plaintext 
<?php
$classname =  // nazwa klasy plugina;
 
call_user_func(array($classname, 'Main'));
?>
[PHP] pobierz, plaintext 

w ten sposob mozna zrobic pluginy, aha i klasy w tym przypadku maja za zadanie wyruzniac pluginy, bo wszyskie beda wywolywac funckje Main.

Ten post edytował nasty_psycho 22.03.2007, 11:16:36

[Ociu]

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] pobierz, plaintext 
<?php
class PluginManager{
protected $pluginsMap = array();
 
public function __get( $sPluginName ) {
if(isset($this->pluginsMap[$sPluginName])) {
return $this->pluginsMap[$sPluginName];
} else {
throw new Exception('Plugin . ' $sPluginName ' . not found');
}
}
}
?>
[PHP] pobierz, plaintext 

Przez co możemy odwoływać się do pluginu w każdym miejscu w skrypcie.

[erix]

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.

Ten post edytował erix 28.05.2006, 21:20:49

[NuLL]

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 :|

Ten post edytował NuLL 29.05.2006, 00:05:36

[g00fy]

mi podoba sie polaczenie Visitora z Componentem. lub jesli ktos chce to Observator.

[NuLL]

mi podoba sie polaczenie Visitora z Componentem. lub jesli ktos chce to Observator.

Cokolwiek to znaczy.

A ktos moze przygladal api pluginowemu Wordpressa Wg mnie kawal dobrego kodu i pomyslu

[anas]

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

Ten post edytował anas 28.06.2006, 12:08:43

[UDAT]

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] pobierz, plaintext 
<?php
aspect Security{
	pointcut modelConstruction:new(IModel(*));
	pointcut modelExecution:exec(public IModel+::*(*));
 
	around(): (modelExecution || modelConstruction){
	//Przeprowadź autoryzację
	}
}
?>
[PHP] pobierz, plaintext 

Przykład1: Plugin BBCode do artykółów

[PHP] pobierz, plaintext 
<?php
aspect BBCodePlugin{
  pointcut setArticleBody:exec(public Article::setBody(2));
 
  after($body): setArticleBody{
	return BBCodeParser::parseText ( $body );
  }
}
?>
[PHP] pobierz, plaintext 

W ten sam sposób można dodać najprzeróżniejsze pluginy, a nawet pluginy pluginów pluginów....


Zalety:
+ można dodać prawie każdy możliwy plugin
+ zero przygotowań kodu / 0 nadmiarowych linii kodu
+ może współistnieć z innym systemem pluginów
+ odnosimy korzyści z użycia AOP ( poprawa modularności, itp. )
+ można dać pluginy/filtry na np. konstrukcję obiektów/ustawienie właściwości co w normalnym podejściu byłoby trudne
+ można połączyć łatwo z PicoContainer'em ( nałożyć pointcut'a na tworzenie obiektów )
Wady:
- pomocna jest dobrze zaplanowana architektura ( drobne, krótkie metody, używanie interfejsów, itp. )
- narazie AOP dla PHP jest w powijakach ( nie jest jednak fatalnie )
- dodatkowa faza wdrażania - weaving ( jedno zadanie Phing'a/Make'a itp. załatwia sprawę )
- wymaga zaznajomienia się z AOP

Linki:
* PHPAspect
* PHP AOP
* AspectJ ( pierwowzór wszystkich implementacji AOP )

Ten post edytował UDAT 24.03.2007, 19:33:51

[webik]

Witam

Myślę że tutaj z pomocą może przyjść Pico Container (Java) i port do php

Jestem takiego zamego zdania, tylko ja napisalem swoj wlasny Container... z wsparciem dla wzorca Decorator... Na razie go tetuje ale testy wpypadaja obiecujaco, moze nie ma takiego uniwersalizmu i takich mozliwosci jak Pico ale mysle ze w miare rozwoju to dogonie Pico ...

Wg mnie to najlepsze rozwiazanie....

Pozdrawiam

[darektbg]

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] pobierz, plaintext 
<?php
$oFront->registerPlugin(new Rapide_Controller_Front_Plugin_ACL);
?>
[PHP] pobierz, plaintext 

W tym przypadu akurat plugin ACL, korzysta z metody preExecution(wykonywana przed wywołanie konkretnej akcji):

[PHP] pobierz, plaintext 
<?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;
  }
}
?>
[PHP] pobierz, plaintext 

[Strzałek]

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

[Athlan]

Imho @nasty_psycho już dobrze kombinuje:
http://forum.php.pl/index.php?s=&showt...st&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).

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.

Strzałek, nie patrz teraz pod kątem co to jest i jak ładowane, ale jak to wykorzystujemy. Możemy zrobić sobie plugin, który będzie integrował w tablice $_GET i $_POST, który wykryje włączone/wyłączone magic quotes i wykona odpowiednie kroi przed executem jakiegokolwiek kontrolera.

Odbiegając od filozofii... pojawił się tutaj post, w którym został poruszony problem dajmy na to bbcode w odpowiednich miejscach aplikacji, np w treści newsa, ale w komentarzach już nie. Nie jestem pewnien, czy możliwy jest superelastyczny sposób, aby przefiltrować takie dane. Jeżeli chceilibyśmy sprawdzac czy istnieje ewentalny plugin do załóżmy obiektu newsa. Każdny news potraktujmy jako obiekt:

[PHP] pobierz, plaintext 
<?php
$oNews = new News('id');
$oNews->loadPlugins();
echo $oNews->data->title;
echo $oNews->data->text;
?>
[PHP] pobierz, plaintext 

sprawdzimy czy jest plugin do przefiltrowania tytułu newsa i podejmiemy odpowiednie ktoki, jednaże w treści bbcode by nie został użyty. Wydłuża się tutaj czas działania apliacji o więcej niż "troszkę". Tak jak to było powiediane wcześniej, nie ma uniwersalnego API do ładowania pluginów.

Moim zdaniem ZAWSZE będzie potrzebna ingerencja programisty, chociażmy tak:

[PHP] pobierz, plaintext 
<?php
$oBBCode = $oPlugin->load('bbcode');
$oBBCode->parse($oNews->title);
?>
[PHP] pobierz, plaintext 

[LBO]

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

W dodatku to jest jeszcze okrojona wersja filtrów z Zend Framework.

[Zeman]

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] pobierz, plaintext 
<?php
class TUser {
  function tryLogin() {
	 ... // logowanie
	 {$IFDEF "modul_sprawdzania_wiadomosci"}
		... // kod do sprawdzania wiadomości
	 {$ENDIF}
  }
}
?>
[PHP] pobierz, plaintext 

Pozwiodronka,
Zeman.

[Athlan]

Ale natłukłem tekstu, ciekawe czy komuś będzie sie chciało tyle czytac

Przeczytałem bardzo dokładnie i pozwolę sobie dokonać analizy.

W Twoim przypadku wykonujesz jakieś pluginy przed wykonaniem metody lub/i po niej. Np Login() => onLogin() (podobnie do JavaScriptu). Pomysł bardzo dobry, wręcz genialny, ale sprawdzanie, czy metoda istnieje za kazdym razem spowolni zleksza aplkiacje hm?

Ok do rzeczy. Tak jak przedstawiłem w moim poprzednim poście, przyczepmy się tego naszego BBCode. Trzeba jakoś treść newsa przepóścić przez metodę BBCode::Parse() a jest to niezbędne albo w kontrolerze, albo w templacie. Nie chcemy tutaj ingerować w kod aplikacji. Dzięki rozwiązaniu Zeman'a możemy zrobić tak, że obiekt widoku jest trzymany jako argument kontrolera, przez co jest w stanie używalności przez cały czas. Do czego zmierzam. Kolejność wykonywania poszczególnych metod:

$oController->preLogin(metoda_pluginu_jakiegos); // wykonamy PRZED kontrolerem Login
$oController->outLogin(metoda_pluginu_jakiegos); // wykonamy tuż przed executem widoku w kontrolerze przez dispatcher, ale po wykonaniu wszelkich akcji wewnątrz kontrolera
$oView = $oController->Login(); // każdy kontroler zwraca obiekt widoku;
$oView->display(); // no i execute

W czym rzecz... metoda outLogin() wykonana zostanie po wszelkich działaniach kontrolera, ale jeszcze przed wyrzuceniem (return) widoku, co pozwoli nam na dowolną ingerencję w kontroler zaraz po wykonaniu operacji. W naszym przypadku (BBCode) filtrujemy sobie jeden argument z idoku przechowywanym jako argument kontrolera:

[PHP] pobierz, plaintext 
<?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
}
?>
[PHP] pobierz, plaintext 

To by było na tyle z mojej strony, ciekawe czy ktoś przeczyta

Pozwiodronka,
Zeman.

Zdraviam

[Zeman]

To by było na tyle z mojej strony, ciekawe czy ktoś przeczyta

Przeczytałem, ale wiele z tego nie rozumiem, może dlatego, że nie znam BBCode. W moim rozumowaniu pluginów bardziej to podchodzi pod "pluginy dedykowane" o których wspomniałem w podziale pluginów ale ich nie opisywałem. A może się pokuszę o napisanie mikro-artykułu Tylko czy ktoś to będzie czytał...

[faster]

Tylko czy ktoś to będzie czytał...

Witam,
... czytam, czytam ... dokładnie i sam się zastanawiam jak podejść do tematu.
Zgadzam się na pewno z jednym, pluginy to rozszerzenia funkcji systemu zatem trzeba najpierw zaplanować co chcemy aby było rozszerzane. Słyszałem o systemach które są ponoć całkowicie rozszerzalne i można pisać pluginy do wszystkiego ale czy to przypadkiem nie polega na przepisywaniu czy modyfikacji istniejącego już w systemie kodu? Bo nie potrafię sobie wyobrazić jak można rozszerzyć wszystko w aplikacji.
Zastanawia mnie natomiast jeszcze inna rzecz .... jak trzeba zaprojektować genialnie aplikację aby była tak rozszerzalna jak firefox co Wy na to?

Pozdrawiam
::faster

[Zeman]

Witam,
... czytam, czytam ... dokładnie i sam się zastanawiam jak podejść do tematu.
Zgadzam się na pewno z jednym, pluginy to rozszerzenia funkcji systemu zatem trzeba najpierw zaplanować co chcemy aby było rozszerzane. Słyszałem o systemach które są ponoć całkowicie rozszerzalne i można pisać pluginy do wszystkiego ale czy to przypadkiem nie polega na przepisywaniu czy modyfikacji istniejącego już w systemie kodu? Bo nie potrafię sobie wyobrazić jak można rozszerzyć wszystko w aplikacji.
Zastanawia mnie natomiast jeszcze inna rzecz .... jak trzeba zaprojektować genialnie aplikację aby była tak rozszerzalna jak firefox co Wy na to?

Pozdrawiam
::faster

Aplikacje typu FF sa serwerami COM'opodobnymi, które udostępniają na zewnątrz kupę interfejsów. Pisząc plugin pisze się tak naprawdę aplikację kliencką która wykorzystuje te uzewnętrznione interfejsy żeby coś na nich robić. Jak można się domyślać FF ma swoje wewnętrzne obiekty, te obiekty implementują interfejsy. Interfejsy są "przedefiniowane" na tzn język IDL, który stanowi jakby pomost pomiędzy różnymi językami - IDL stanowi standard opisywania interfejsów. Aplikacje - pluginy z grubsza powiedziawszy odczytują definicje interfejsów z tego IDLa i przedefiniowują je na język w którym jest pisany plugin. Najczęściej języki wspierają tworzenie tzw wrapperów. Z punktu widzenia autora pluginu wrapper to obiekt będący klonem obiektu w aplikacji serwera, czyli np jeśli FF ma obiekt powiedzmy Document, to w pluginie też istnieje obiekt Document o tych samych metodach, jednak w pluginie obiekt ten jest wrapperem na obiekt w FF - czyli jeśli plugin wywoła Document->metoda(), to tak naprawdę wywoła się metoda() ale w FF. FF z tego co mi wiadomo wykorzystuje XPCOM i jest to technologia podobna do COM i CORBA, tyle że cross-platform. COM nie jest cross-platform.
Suma sumarum wlaśnie tak się robi aplikacje typu FF - odrazu się zakłada że aplikacja będzie serwerem COM i wszystkim nowo tworzonym klasom nadaje się cechę bycia obiektem COM, co jest równoznaczne z tym, że klasa będzie udostępniała na zewnątrz interfejsy do języka IDL. Dalej się nie będę rozwodził na ten temat ale jest to dosyć trudne zagadnienie no i to forum jest o PHP a wątek dotyczy pluginów w PHP a nie pluginów w FF

[yaotzin]

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.

[Kasjan]

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

Kod

public newsAdd() {
plugins::before('newsAdd');
// tutaj kod wlasciwy funkcji
plugins::after('newsAdd');
}

skad brac pluginy? funkcja plugins::after i plugins::before automatycznie przechwyci nazwe uruchamianego modulu (news) i automatycznie includuje wszystkie pliki w katalogu:
/modules/news/plugins/

struktura pluginu - oczywiscie klasa, nazwijmy go sobie newsRestrictedIPs:
/modules/news/plugins/RestrictedIPs.php

Kod

class newsRestrictedIPs {
public function onNewsAdd() {
   if ($_SERVER['REMOTE_ADDR'] == '5.10.15.20') {
    ....
  }
}
}

kwestia dogrania jak do klasy news wyslac info ze ma nie wstawiac obiektu... proponuje przed plugins::before('newsAdd'); dodac $settigns = array(); a w newsRestrictedIPs::onNewsAdd dodac $settings['dontInsert'] = true;

jeszcze dwa slowa odnosnie funkcji plugins::before i plugins::after - biora katalog
modules/NAZWA_MODULU/plugins/
includuja kolejno pliki, jesli zaincluduje to sprawdza cz istnieje [mod][nazwapliku]->on[nazwaakcji] czyli np. newsRestrictedIPs->onNewsAdd i uruchamia.

oczywiscie aby to wszystko dzialalo poprawnie musimy ustalic sobie pewne regoly jak pisac - nazewnictwo klas, metod, plikow... ale sa tego plusy - mamy w aplikacji porzadek...

jakies to rozwiazanie jest - czy dobre, czy zle - wypowiedzcie sie sami.

[NuLL]

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.

[LBO]

W większości przypadków wystarczają filtry, poparte dobrymi nawykami programistycznymi (interfejsy, dobrym dobraniem strategii etc.)

[NuLL]

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 ?

Ten post edytował NuLL 14.10.2007, 18:46:36

[LBO]

Nie czepiaj się, chodziło mi o powszechną implementacje Intercepting Filters w wielu, wielu frameworkach. Przykro mi, że nie zrozumiałeś.

[Kasjan]

A co jesli chcesz operowac na jakis danych zawartych w akcji ?

mam globalne obiekty $get i $post (lub $request) i tylko przez nie (zgodnie z narzucona sobie specyfikacja cms) moge sie odwolywac do $_GET i $_POST (lub $_REQUEST) i moge je edytowac przez plugin.

poza tym plugins::before i plugins::after mozna sobie zautomatyzowac - od czego mamy extends / mozna zrobic dekoratory

[Cysiaczek]

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] pobierz, plaintext 
<?php
$this->post->zmienna;
?>
[PHP] pobierz, plaintext 

Jesteś w stanie przefiltrować zawartość danych POST pod kątem konkretnej akcji niejako z zewnątrz - bez jawnego wywołania kodu filtrujacego wewnątrz akcji, a zwyczajnie dodajac jakiś plik z informacją, co i jak ma zostać przefiltrowane.

Pozdrawiam.

[gamecreator]

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

[deirathe]

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.

[splatch]

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ł OSGi i Eclipse przepisany do PHP.

Definicja "paczki", części aplikacji

[PHP] pobierz, plaintext 
<?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 array();
	}
 
	/**
	 * Pobranie nagłówków z informacjami na temat paczki.
	 *
	 * @return Header Lista z unikalnymi nagłówkami.
	 */
	function getHeaders() {
		return array();
	}
 
	/**
	 * Pobranie informacji o stanie paczki.
	 *
	 * @return stan paczki (któraś z wartości stałych z IState).
	 */
	function getState();
}
 
?>
[PHP] pobierz, plaintext 

Informacje o nagłówkach trzymane np w pliku .ini

[PHP] pobierz, plaintext 
<?php
/**
 * Nagłówek z infomacjami na temat wymagań paczki.
 *
 * @author Łukasz Dywicki <luke@code-house.net>
 */
class 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] pobierz, plaintext 

Kontekst w jakim działa aplikacja, chodzi tu głównie o warstwę usług a nie request response etc.

[PHP] pobierz, plaintext 
<?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] pobierz, plaintext 

Definicja pluginu - jedyne co od niego wymagamy to start i stop, opcjonalnie install, uninstall.

[PHP] pobierz, plaintext 
<?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] pobierz, plaintext 

Warunki dla pluginów

[PHP] pobierz, plaintext 
<?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] pobierz, plaintext 

Hook = extension point - czyli miejsce, w którym ktoś się wpina przez pluginy

[PHP] pobierz, plaintext 
<?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] pobierz, plaintext 

Rejestr rozszerzeń - czyli coś, w czym wszystkie EP są dodawane, usuwane i przetrzymywane.

[PHP] pobierz, plaintext 
<?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] pobierz, plaintext 

Stany, w jakich może być paczka (paczka != plugin)

[PHP] pobierz, plaintext 
<?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;
 
}
 
?>
[PHP] pobierz, plaintext 

[Babcia@Stefa]

Moje rozwiązanie jest takie:

Archiwum (np. rar, zip itp.) {
- plik 1
- plik 2
- plik 3
- info.xml
}

Info.xml

[XML] pobierz, plaintext 
<?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>
[XML] pobierz, plaintext 

Jest ono bardzo proste ;]

Pozdrawiam, Babcia@Stefa

[NuLL]

@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

[specialplan]

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?:_)

Ten post edytował specialplan 11.03.2008, 16:55:36

[carbolymer]

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] pobierz, plaintext 
<?php
class foo extends Matrix  
{  
 
//metoda koniecznie protected lub private poprzedzone '_'  
protected function _test($val)  
{  
	echo '<br/>Test val:'.$val.'<br/>';  
}  
 
}
?>
[PHP] pobierz, plaintext 

Potem przy starcie aplikacji poprostu tworzymy obiekt klasy foo, ładujemy (dziedziczoną metodą z Matrix) plugin - można by zeskanować katalog lub konfig na starcie.

[PHP] pobierz, plaintext 
<?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
?>
[PHP] pobierz, plaintext 

Kod w całości:
http://carbolymer.ovh.org/wp/?p=18

[Sedziwoj]

@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.

[specialplan]

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.

[LBO]

Framework FLOW3 (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.

Ten post edytował LBO 13.03.2008, 16:27:50

[tmgryf]

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?

[tuner]

Framework FLOW3 (który będzie służyć za bazę dla najnowszego TYPO3) poszedł o krok naprzód w "pluginizacji" aplikacji - używa aspektów.

Także polecam przyjrzenie się temu rozwiązaniu, niezwykle kompleksowo pozwala zarządzać komponentami aplikacji.

Na swoim blogu zamieściłem wpis poświęcony pluginizowaniu i jako, że jest bardzo w temacie z przyjemnością linkuję.

[wlamywacz]

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

[HTML] pobierz, plaintext 
{module name="gallery" action="index"}
[HTML] pobierz, plaintext 

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

[HTML] pobierz, plaintext 
{module name="gallery" action="index"}
[HTML] pobierz, plaintext 

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.

P.S. Możecie mi podpowiedzieć gdzie szukać informacji o zastosowaniu pluginów?

Ten post edytował wlamywacz 25.01.2010, 12:58:59

[marcio]

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

Po co bawic sie w kolejke jak mozna robic tak:

[PHP] pobierz, plaintext 
 
if($auth -> isLogged()) {
 
}
 
else {
 
$this -> forward('Authorization'); // lub $this -> forward('Authorization', 'Index');
 
}
 
[PHP] pobierz, plaintext 

ja tak to widze chyba ze o czyms nie wiem.

Możecie mi podpowiedzieć gdzie szukać informacji o zastosowaniu pluginów?

Zalezy co masz na mysli jako plugin ogolnie szukaj info na temat filtrow,pluginow,modulow,modularnosci,komponentow,widget'ow etc...

Co do reszty twojego dzialania pluginow to u mnie dziala to prawie tak samo mam glowny szablon(view) calej strony np lewe i prawe menu o do tego sordkowy kontent.

Potem mam klase ktora to glownego widoku "wstrzykuje" wynik komponentu/pluginu/widget'u.

Tyle ze w glownym widoku mam tylko:

[HTML] pobierz, plaintext 
 
<div>%lewemenu%</div>
 
[HTML] pobierz, plaintext 

Itp i tam wrzucam wszystko na podstawie url'a.

[wlamywacz]

Kolejka po to gdyż autoryzacja, logowanie itp. będzie również jako moduł który trzeba wywołać w odpowiednim momencie.

[marcio]

Moze ktos wytlumaczy jaka jest roznica pomiedzy kolejka zadan a robien forward() na dana akcje?

[XianN]

Moze ktos wytlumaczy jaka jest roznica pomiedzy kolejka zadan a robien forward() na dana akcje?

Taka jak miedzy (uporzadkowana) lista rzeczy do zrobienia, a dowiadywaniem sie o nastepnym zadaniu po wykonaniu poprzedniego:)

W przypadku forward() metoda, ktora jest aktualnie wykonywana musi znac nastepna.
Jesli jest to lista, wystarczy, ze sie zajmie swoja robota, a decydowanie o tym 'kto, kiedy i gdzie?' pozostawi komu innemu. Lista daje tez duzo wieksza wygode, np w zmienianiu kolejnosci wykonywania zadan, dodawaniu nowych, etc.

Ten post edytował XianN 26.01.2010, 12:00:39

[marcio]

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=&showt...st&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();

[PHP] pobierz, plaintext 
 
public function ShowLastNews() {
 
  //wszystkie operacje pobierania etc....
 
  return $txtNews;
 
 
 
 
}
 
[PHP] pobierz, plaintext 

Teraz by zalozyc filtr wystarczy w katalogu /plugins/filters/ utworzyc plik PFNews.php o takiej klasie:

[PHP] pobierz, plaintext 
 
<?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] pobierz, plaintext 

Jak dla mnie pomysl bomba chce zrobic jakis filtr nie musze ingerowac w kod jakiegos komponentu/pluginu tylko pisze do niego filtr.

Oczywiscie nie wszystkie metody musi implementowac filtr bo jego klasa nie uzywa interfejsu ani nic bo moze byc tylko tak ze filtr dla danego komponentu/pluginu bedzie potrzebowal tylko jedna funkcje.

Do tego mam glowny kontroler aplikacji ktora pobiera wszystkie komponentu/pluginy za pomoca modelu i wstawia caly wynik do glownego szablonu do tego jest klasa pomocnicza by sprawdzic filtry.
glowny Kontroler:

[PHP] pobierz, plaintext 
 
<?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 = (count($componentsAction) == 0) ? 'Index' : $componentsAction[0];
 
      $tab = $this -> plugins -> LoadPlugin($components, $componentsAction);
 
      $this -> view -> AddVars($tab); 
      echo $this -> view -> Layout('Home', 'view');
 
 
  }
 
}
 
?>
 
 
[PHP] pobierz, plaintext 

jesli ktos chce zobaczyc tez klase pomocnicza prosze mowic.

[wlamywacz]

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 ?

[marcio]

EDIT:
Zle zrozumialem o ta kolejke chodzi o to: http://forum.php.pl/index.php?s=&showt...st&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] pobierz, plaintext 
<?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(file_exists(DIR_PLUGINS_CTRL.$PluginName.'.php')) {
 
      require_once(DIR_PLUGINS_CTRL.$PluginName.'.php');  
 
    }
 
    else if(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;    
 
  }
 
 
}
 
 
?>
[PHP] pobierz, plaintext 

Co o tym myslicie?

Ten post edytował marcio 26.01.2010, 16:47:36

[Ormin]

Wzorzec obserwatora i wszystko jasne

[eai]

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.

[PHP] pobierz, plaintext 
abstract class Plugin { }
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
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
}
[PHP] pobierz, plaintext 

Następnie w naszym systemie musi istnieć rejestr, w którym dane pluginy będą dodawane.
Podczas wywołania określonych operacji, system pobierałby odpowiedni plugin np. podczas edycji użytkownika, pobierałby wszystkie pluginy dziedziczące po PluginUsers, i wywoływał kolejno metody z tego pluginu odpowiadające obecnie wykonywanej akcji. np po zapisie zmian wywoływana byłaby metoda postSaveUser.

Tak naprawdę trzeba się zastanowić, co w naszym systemie będzie można za pomocą pluginów wykonać. Kolejny krok to napisanie odpowiednich metod w abstakcyjnym modelu a na końcu wywołanie tych metod i przekazanie odpowiednich argumentów, które dany plugin może miec dostęp.

[paxton]

Cos takiego jest sprytne, moze nie jest to porzadny system pluginow, ale moze ulatwiac sprawe przy pisaniu dodatków.

[PHP] pobierz, plaintext 
public function loadInjections($name) {
		if(is_dir("injections/$name"))
			foreach (glob("injections/$name/*.php") as $injection) {
				include_once($injection);
			}
		else
			throw new exception("Could not load injections! Event Folder not found. ErrCode: 172610032010");
	}
[PHP] pobierz, plaintext 

Używam tego w mojej aplikacji, domyślam się ze szybkość skanownia nie jest najlepsza, ale nie narzekam. Tam gdzie chce aby były wprowadzane pluginy tam używam tej metody.

Innym rozwiązaniem są hooki.

[Psychopath]

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.

[marcio]

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?

[hind]

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).

[marcio]

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']

Stosuje konwencje ze w pluginach przed nazwami zmiennych daje "p" zeby nie kolidowaly ze soba.

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?)

Ja to robie tak ze plugin moze byc ladowany przed lub po komponencie, gdzie do akcji komponentu dolaczam akcje pluginu.
Np majac akcje "readNews" do ktorej chce podczepic plugin comment mam taki config komponentu News, aktywuje plugin w bazie a config sprawdza tylko czy w ogole obiekt(w tym przypadku news) moze posiadac w ogole plugin comment:

[PHP] pobierz, plaintext 
<?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'] = array('Index');
$configs['lifetime'] = 10800;//time in sec
$configs['admin_panel'] = 1;//1 - on / 0 - off
 
$configs['plugins_settings'] = array(
									'after' => array('readNews' => array(
																		'comment' => array(
																							'segment_ref' => 0,
																							'actions' => array('submit', 'delete')
																						  )
																		)
													  )
								  );
 
return $configs;
 
?>
[PHP] pobierz, plaintext 

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)

Dokladnie akcje pluginu sa podpinane pod akcje komponentu i komponent do ktorego sa podpinane nie ma z plugin'em nic wspolnego

[mrWodoo]

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

[marcio]

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.

[mrWodoo]

Chętnie bym zobaczył

[marcio]

Poczekaj jeszcze miesiac, postaram sie dokonczyc projekt jesli chodzi o backend i funkcjonalnosc.

[mrWodoo]

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

[hind]

@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ć

[PHP] pobierz, plaintext 
function addUser($dane) {
foreach($this->_AutomatyczniePobaranListaAkcjiDoDodaniaUsera as $akcja)
$dane = call_user_func($akcja,$dane);
return $this->insert($dane);
}
[PHP] pobierz, plaintext 

[Crozin]

@mrWodoo: Zdarzenia i jakiś sensowny event dispatcher z obsługą priorytetów:

[PHP] pobierz, plaintext 
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);
 
     ...
}
[PHP] pobierz, plaintext