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.

[ivanhoe]

bez event sistema pluginovi nemaju pravu moc, jer su ograniceni na to da ih sistem poziva pri ucitavanju, ili da cisto sluze kao externe biblioteke funkcija (ali onda je pitanje kako te funkcije pozivati ? )

Mislim da nasledjivanje abstraktnog plugina nije neophodno u varijanti gde je plugin zaduzen da se registruje, cak je tako flexibilnije jer autor plugina ima vecu slobodu da hakuje sistem bez izmena core fajlova. S druge strane ako zelis da aplikacija inicijalizuje pluginove, onda abstraktna klasa treba da propise interfejs koji ce svaki plugin naslediti, obicno su to 2 funkcije, jedna za inicijalizaciju plugina (koja prosledi objekat sa metodama za registraciju) i jedna koja vraca informacije o pluginu (tipa min. verziji aplikacije sa kojom radi, description i podatke o autoru).

Sto se dozvola tice to je vec vrlo komplikovano pitanje, jer ne znam kako mozes da sprecis plugin da pozove koju god zeli funkciju. Obicno se pluginovima veruje, to jest instaliras ih na sopstvenu odgvornost.

[Ilija Studen]

Slažem se da je event sistem killer mogućnost koja daje ogromnu fleksibilnost. Par problema:

- red izvršavanja plugina koji su se subscribeovali na isti događaj
- da li dopustiti da plugin može da kaže: ja sam final, prekini izvršavanje bez obzira koliko još plugina je subscribeovano u redu
- šta se dešava kada se plugini pokolju? tj. kada jedan plugin ne očekuje izmene koje drugi odradi

[zira]

Mnogo je dobro kada redosljed nije bitan Ako jeste bitan, onda taj plugin koji zavisi od rezultata nekog drugog plugina ne bi mozda morao da reaguje na glavni event, vec na event da je ovaj uslovni zavrsio. U suprotnom se stvari zakomplikuju prilicno.

Recimo, moze se desiti da jedan plugin zavisi od drugog, pa onda mozes odrzavati informaciju za taj event koji plugini su uspjesno obavili posao za taj event, a koji nisu, i tu informaciju koristiti u njima. Tako bi mogao da rijesis i problem sa prioritetom, pa ako slucajno naidje na red plugin koji zavisi od nekog drugog, on moze zahtijevati da se taj prvo izvrsi (i zapamti da se izvrsio), pa onda tek on da zavrsi svoj posao. Onda se onaj uslovni ne bi trrebao ni izvrsavati jer je zapamceno da je on obavio posao vec.

U svakom slucaju, komplikacije na koje dosta aplikacija i ne obraca paznju

[ivanhoe]

Originalno napisao zira

Mnogo je dobro kada redosljed nije bitan Ako jeste bitan, onda taj plugin koji zavisi od rezultata nekog drugog plugina ne bi mozda morao da reaguje na glavni event, vec na event da je ovaj uslovni zavrsio. U suprotnom se stvari zakomplikuju prilicno.

Pa jeste, ali onda taj "uslovni" plugin mora da zna da postoji neki plugin koji od njega zavisi, sto obicno nije slucaj (cesto nisu ni isti autori). Po meni su takve stvari problem autora pluginova, a ne autora aplikacije. A i u 99% slucajeva moze da se zaobidje takva logika, tipa registruje se plugin za neki kasniji event, proverti da li postoji funkcija koja mu treba i slicno, a ne da se komplikuje logika glavne aplikacije sa milion mehanizama i provera..

Sto se tice pluginova mnogo jaka fora je i mogucnost da plugin redefinise core funkcije, u WP-u je to reseno kao pluggable funkcije. Sve biblioteke takvih funkcija se inkluduju nakon pluginova i kod svake funkcije se prvo proveri da li vec postoji funkcija sa takvim imenom, pa tek ako ne postoji sledi definicija. Tako mozes lako da izmenis ponasanje neke osnovne funkcije, a da posle upgrade aplikacije i dalje funkcionise skroz normalno..