- Offizieller Beitrag
Eine gute Idee im Hinterkopf, ein wenig Freizeit und der Spaß an der
Sache: So beginnt bei den meisten Entwicklern die Realisierung ihres
ersten Plugins für Community Framework. Sei es nun primär für den
eigenen Einsatz gedacht oder direkt als Projekt für die Community,
spätestens bei der Erstellung eines komplexen Paketes trifft man einen
typischen Fallstrick an: Abhängigkeiten.
Wofür werden Abhängigkeiten benötigt?
Durch die Angabe verschiedener Abhängigkeiten wird gewährleistet, dass
alle Komponenten die durch dieses Paket benötigt werden, auch vorhanden
sind. Vor allem bei der Entwicklung von Plugins für Community Framework
ist es sehr wichtig diese korrekt zu setzen; nicht jede Endanwendung
gewährleistet den selben Umfang an bereits benötigten Plugins.
Mit Hilfe der Abhängigkeiten (engl. „requirements“)
teilt man Community Framework detailiert die benötigten Pakete mit.
Durch diesen Prozess werden z. B. die verfügbaren Optionen im ACP
erzeugt, die Menüeinträge gesetzt oder schlichtweg bestimmte Komponenten
zur Laufzeit geladen.
Ein exemplarisches Plugin
Als Beispiel nehme ich ein fiktives Plugin, das eine allgemeine API für
„FooServices“ bereit stellt und keine direkte Interaktion mit dem
Benutzer bereit stellt. Solch ein Paket kann dazu genutzt werden, oft
verwendete Komponenten zentral für alle Pakete bereit zu stellen, ohne
das berühmte Rad jedes mal neu zu erfinden.
Das Paket stellt an mehreren Stellen Komponente zur Verfügung:
- Allgemeine Schnittstelle zum Zugriff auf die Funktionalität von „FooServices“
- Integration in die Suchfunktion um spezielle Inhalte von „FooServices“ erfassen zu können
Es wird explizit nur die Suchfunktion benötigt, da alle anderen
Komponenten bereits durch Community Framework bereitgestellt werden.
Daraus folgt das Setzen von zwei Abhängigkeiten:
- com.woltlab.wcf (WoltLab Community Framework)
- com.woltlab.wcf.data.message.search (Message Search System)
Wie setze ich die Abhängigkeiten korrekt?
Die eigentliche Problematik entsteht erst, sobald der plugin-Tag verwendet wird, denn dieser definiert klar, dass ein bestehendes Paket direkt hierdurch erweitert wird. Ein fehlender plugin-Tag impliziert die Bereitstellung von Funktionen unabhängig von bereits existierenden Komponenten.
Das oben erläuterte Beispielplugin stellt eine Schnittstelle zur
Interaktion mit „FooServices“ bereit. Auf den ersten Blick erscheint das
Setzen eines plugin-Tags mit dem Inhalt „com.woltlab.wcf“
nur logisch, da wir Community Framework erweitern; Dies ist jedoch ein
typischer Irrtum, da keine bestehende Funktion erweitert wird, sondern
einzig und alleine zusätzliche Funktionen bereitgestellt werden.
Angenommen wir setzen die beiden Abhängigkeiten auf Community Framework
und Message Search System bei gleichzeitiger Setzung des plugin-Tags auf „com.woltlab.wcf“,
so wird Community Framework auf einmal von der Suchfunktion abhängig!
Dies ist technisch bedingt und vereinfacht die gesamte Entwicklung mit
Community Framework immens und ist explizit kein Fehler, sondern ein
gewolltes Verhalten.
Korrekterweise müsste in diesem Beispiel der plugin-Tag also komplett entfernt werden!
Tipps und typische Fallstricke bei der Setzung von Abhängigkeiten:
- Der plugin-Tag darf nicht gesetzt werden, wenn das Zielpaket selbst bereits ein Plugin ist (entsprechend selbst einen plugin-Tag aufweist)
- Plugins
für Community Framework dürfen niemals eine Abhängigkeit auf eine
Endanwendung setzen, wenn Funktionen der Endanwendung benötigt werden,
muss es als Plugin für diese deklariert werden - Abhängigkeiten sollten stets auf alle benötigten Komponenten gesetzt werden, auch wenn nur Teile davon verwendet werden
- Das Setzen eines plugin-Tags ist notwendig, wenn tatsächlich die Funktionalität erweitert wird, z. B. Plugin stellt einen neuen BBCode bereit: <plugin>com.woltlab.wcf.data.message.bbcode</plugin>
