Vă mulțumim pentru susținere

Cel mai bun mod de a permite plugin-uri pentru o aplicație PHP

Incep o noua aplicatie web in PHP si de data asta vreau sa creez ceva ce oamenii pot extinde folosind o interfata plugin.

Cum se face scrierea de "cârlige" în codul lor, astfel încât pluginurile să se poată atașa la anumite evenimente?

0
adăugat editat

8 răspunsuri

Ai putea folosi un model de Observer. O modalitate funcțională simplă de a realiza acest lucru:


Ieșire:

This is my CRAZY application
4 + 5 = 9
4 * 5 = 20

Note:

Pentru acest exemplu de cod sursă, trebuie să declarați toate pluginurile înainte de codul sursă propriu-zis pe care doriți să îl puteți extinde. Am inclus un exemplu de modul în care să se ocupe de valori unice sau multiple care sunt transmise pluginului. Cea mai dificilă parte a acestui lucru este scrierea documentației actuale, care afișează ce argumente sunt transmise fiecărui cârlig.

Aceasta este doar o metodă de realizare a unui sistem de pluginuri în PHP. Există alternative mai bune, vă sugerăm să verificați documentația WordPress pentru mai multe informații.

Ne pare rău, se pare că caracterele de subliniere sunt înlocuite de entitățile HTML de Markdown? Pot să trimit din nou acest cod atunci când acest bug se rezolvă.

Editați: Nevermind, apare numai atunci când editați

0
adăugat
Notă pedantică: acest lucru nu este un exemplu al modelului de observator. Este un exemplu al Model de mediator . Adevăratul observator este o notificare pură, nu există nici un mesaj de transmitere sau notificare condiționată (și nici un manager central pentru controlul notificărilor). Nu face răspunsul greșit , dar trebuie remarcat faptul că opriți-i pe oameni să cheme lucrurile prin numele greșit ...
adăugat autor ircmaxell
Rețineți că pentru PHP> = 5.0 puteți implementa acest lucru folosind interfețele Observer / Subiect definite în SPL: php.net/manual/ro/class.splobserver.php
adăugat autor John Carter
Rețineți că atunci când utilizați mai multe cârlige / ascultători, trebuie să returnați numai șiruri de caractere sau matrice, nu ambele. Am implementat ceva similar pentru Hound CMS - getbutterfly.com/hound .
adăugat autor Ciprian

Metodele cârlig și ascultător sunt cele mai frecvent utilizate, dar există și alte lucruri pe care le puteți face. În funcție de dimensiunea aplicației și de cine vă permiteți să vedeți codul (acesta va fi un script FOSS sau ceva în casă), veți influența foarte mult modul în care doriți să permiteți pluginurile.

kdeloach are un exemplu frumos, dar implementarea lui și funcția de cârlig este puțin nesigur. V-aș cere să furnizați mai multe informații despre natura aplicației php și scrisorii dvs. Și cum vedeți pluginurile care se potrivesc.

+1 la kdeloach de la mine.

0
adăugat

Cred că cea mai ușoară cale ar fi să-l urmați pe sfatul lui Jeff și să aruncați o privire în jurul codului existent. Încercați să căutați Wordpress, Drupal, Joomla și alte cunoscute CMS-uri bazate pe PHP pentru a vedea cum arată și simt cârligele API. În acest fel puteți obține chiar și idei pe care probabil că nu le-ați gândit înainte de a face lucrurile un pic mai mult rușine.

Un răspuns mai direct ar fi să scrieți fișierele generale pe care le-ar "include_once" în fișierul lor, care ar oferi utilitatea de care ar avea nevoie. Aceasta ar fi împărțită în categorii și NU este furnizată într-un fișier MASSIVE "hooks.php". Fiți atent, totuși, pentru că ceea ce se termină până se întâmplă este că fișierele pe care le includ în cele din urmă având tot mai multe dependențe și funcționalitate îmbunătățește. Încercați să păstrați scăderea dependențelor API. I. Mai puține fișiere pentru a le include.

0
adăugat
Aș adăuga DokuWiki la lista sistemelor pe care ar putea să le aruncați o privire. Are un sistem de evenimente frumos care permite un ecosistem plugins bogat.
adăugat autor chiborg

Deci, să presupunem că nu doriți modelul Observer deoarece trebuie să vă schimbați metodele de clasă pentru a vă ocupa de sarcina de a asculta și doriți ceva generic. Și să presupunem că nu doriți să utilizați moștenire extinde , deoarece probabil ați moștenit deja în clasa dvs. din altă clasă. Nu ar fi grozav să existe o modalitate generică de a face orice clasă conectabilă fără prea mult efort ? Iată cum:

0
adăugat
Am citiți pe Wikipedia despre acest lucru și, whoa, ai dreptate! :)
adăugat autor Volomike
Nu este acesta un decorator?
adăugat autor MV.

Iată o abordare pe care am folosit-o, este o încercare de a copia din mecanismul Qt semnale / sloturi, un fel de model de Observer. Obiectele pot emite semnale. Fiecare semnal are un ID în sistem - este compus din numele id-ului și al obiectului expeditorului Fiecare semnal poate fi legat la receptoare, care pur și simplu este un "apelabil" Folosiți o clasă de autobuz pentru a transmite semnalele oricărei persoane interesate să le primească Când se întâmplă ceva, trimiteți un semnal. Mai jos este și exemplu de implementare

    login();

?>
0
adăugat

Sunt surprins că majoritatea răspunsurilor de aici par a fi orientate spre pluginurile care sunt locale aplicației web, adică plugin-uri care rulează pe serverul web local.

Dar dacă doriți ca pluginurile să ruleze pe un server diferit - de la distanță? Cel mai bun mod de a face acest lucru ar fi să furnizați un formular care vă permite să definiți diferite adrese URL care ar fi numite atunci când apar anumite evenimente în aplicația dvs.

Diferitele evenimente ar trimite informații diferite bazate pe evenimentul care tocmai a avut loc.

În acest fel, veți efectua un apel cURL la adresa URL furnizată aplicației dvs. (de exemplu, peste https) în cazul în care serverele la distanță pot efectua activități pe baza informațiilor trimise de aplicația dvs.

Acest lucru oferă două avantaje:

  1. Nu trebuie să găzduiți niciun cod pe serverul dvs. local (securitate)
  2. Codul poate fi pe servere la distanță (extensibilitate) în alte limbi decât PHP (portabilitate)
0
adăugat
Acesta este mai mult un "push API" decât un sistem "plugin" - oferiți o modalitate ca alte servicii să primească notificări despre evenimentele selectate. Ceea ce se înțelege în general prin "pluginuri" este că puteți instala aplicația și apoi adăugați funcționalități pentru a personaliza comportamentul în scopurile dvs., ceea ce presupune ca pluginul să fie difuzat la nivel local - sau cel puțin să aveți o comunicație sigură și eficientă pe 2 căi pentru a oferi informația pentru aplicația nu doar să o ia de la . Cele două caracteristici sunt oarecum distincte, iar pentru mu
adăugat autor IMSoP

Există un proiect elegant denumit Stickleback de Matt Zandstra de la Yahoo care gestionează o mare parte din munca pentru manipularea plugin-urilor în PHP.

Îmbunătățește interfața unei clase de pluginuri, acceptă o interfață de linie de comandă și nu este prea greu pentru a intra în funcțiune - mai ales dacă citiți povestea despre el în Revista arhitect PHP .

0
adăugat

Sfat util este să te uiți cum au făcut alte proiecte. Mulți solicită ca pluginurile să fie instalate și numele lor să fie înregistrate pentru servicii (cum ar fi wordpress), astfel încât să aveți "puncte" în codul dvs. unde apelați o funcție care identifică ascultătorii înregistrați și le execută. Un model standard de design OO este Modelul de observator , care ar fi o opțiune bună de implementat în un sistem PHP cu adevărat orientat spre obiect.

Zend Framework folosește multe metode de conectare și este foarte frumos arhitect. Ar fi un sistem bun la care să te uiți.

0
adăugat