Plugin sistem

[bluesman]

Koji su metodi implementacije plugin sistema, imam neku ideju posto se u dosta aplikacija ponavljaju skoro isti elementi, pa cak i to da ubrzam, neke stvari kao sto je recimo "news" da napravim kao plugin koji se dodaje. Interesuje me, oni koji su radili to do sada ili su imali prilike da prostudiraju kako to drugi rade, koji su najcesce i najpouzdanije metode.

Smarty to radi na nivou funkcija, kada se plugin koristi u template-u, on proverava da li takav postoji u plugin direktorijumu, i izvrsi tu php funkciju. On pravi razliku u odnosu na output, neke zove modifiers, neke fuctions, neke block....

Moja ideja je da plugin bude jedna klasa, koja ce da nasledjuje abstraktnu klasu "plugin", a u configu moraju rucno da se inicijalizuju.

Recimo imam klasu plugin:

PHP kôd:

abstract class Plugin 


a onda svaki plugin mora da bude

PHP kôd:

class MojPlugin extends Plugin 


onda imam klasu Plugins koja sadrzi sve registrovane pluginove koji se dodaju kao

PHP kôd:

$plugins->register('MojPlugin') 


I onda se moze koristiti ta klasa.

Kasnije, neki drugi plugin moze da nasledi cak i postojeci plugin i ponasa se normalno kao bilo koji.

Kako to resavaju drugi?

Off Topic: sada se pokazuje da ipak ponekad treba da pogledas tudji kod da ne izmisljas toplu vodu

[dinke]

Nisam se nikada bakcao ali i meni ce trebati. Pogledaj aprilski broj phparch-a, tamo ima interesantan tekst na ovu temu (doduse, pretezno je proceduralno orijentisan, sto mi se nije svidelo).

[Pedja]

Sve se svodi na to da uvedes standardizovan nacin komunikacije aplikacije sa plugin-om. Mozes tako kako si zamislio sa klasama, a mozes i preko procedura.

Tesko je ulaziti u detalje, jer to sve zavisi od konkretne implementacije i uopstenosti koju zelis da postignes.

U principu potrebno je da core aplikacije zna da primi zahtev za odredjeni plugin (modul), da moze da prosledi informaciju koja tacno opcija modula treba da se pokrene, da toj opciji prosledi custom parametre i naravno da moze da proveri da li korisnik ima dovoljne privilegije da pristupi opciji plugin-a.

Kada sam razvijao takav sistem isao sam prilicno siroko tako da svaka opcija u pluginu moze da definise sadrzaj za title, keywords, description, i druge sadrzaje koji idu cak i u HTTP header, sve kroz standardizovan mehanizam.

Dobra stvar koju valja da uradis to je da svaku opciji plugina podelis na dva dela: apliativni i vizuelni deo. Apliaktivni izvrsis pre nego sto uopste pocnes kreiranje HTML strane, a vizuelni u toku genersianja dokumenta. Tako dobijas velike mogucnosti da uradis prakticno bilo kakvu apliakciju, a pre svega to da opcija plugina moze da utice na celu aplikaciju, bas zato sto se njen aplikativni deo izvrsi pre nego sto pocne generisanje HTML-a, kada uvek imas prostora da promenis ponasanje bilo kog dela aplikacije.

Takodje, treba da ozbedis mehanizam da jedna opcija plugina moze da inkluduje bilo koju drugu opciju bilo kog plugina u aplikaciji.

[ivanhoe]

meni se svidja kako je u Wordpressu to reseno, oni su pluginove radili u bliskoj saradnji sa call-back sistemom koji je ugradjen u WP. Pluginovi se naprosto inkluduju kao obicne php skripte (koji pluginovi se inkluduju kontrolise se u konfiguraciji) i oni se izvrse kao obican php skript, a njihov je zadatak da se registruju za akcije koje ih zanimaju koristeci WP-ove ugradjene funkcije. Kad se neka od tih akcija izvrsava WP pogleda niz registrovanih funkcija za callback za tu akciju i onda ih redom pozove, i tako pluginovi mogu da se ubace u razne delove sistema. Vrlo elegantan i flexibilan interfejs.

[MorenoArdohain]

^^ I agree, dokaz je na hiljade napisanih pluginova

[Ilija Studen]

Dodati event sistem u skriptu je jako obiman posao i uglavnom za postojeće stvari podrazumeva prolazak kroz većinu koda. Originalna ideja za plugine kod activeCollaba je bila baš to - event sistem gde se pluginima daje mogućnost da se subscribuju na određeni event i obrade ga kad isti bude "okinut".

Ono što mene najviše brine ovde su performanse. Koliki to stvarno overhead donosi? Mislim, activeCollab sam po sebi jeste trom (će da bude sređeno!) i bojim se da bi ga ovako nešto podosta usporilo koda bi se išlo u previše detalja.

Primeri: onCommentDisplay(Comment $comment). Recimo, plugin može da se subscribuje na ovaj događaj i u određenim uslovima spreči prikaz komentara ili promeni način na koji se isti renderuje. Ovo ne donosi samo novi nivo fleksibilnosti sistema, već i novi način kako da praviš sam sistem. Uvrnuto... Plaši me!

Btw, događaji su samo jedan od delova plugin sistema. Mislim da su jedan od najtežih za rešiti jer se protežu kroz kompletan sistem, ali osnovne stvari kao nasleđivanje abstraktnog plugina, struktura direktorijuma, rukovanje client side fajlovima (assets), dozvole, enable / disable - sve takođe važne stvari.