Plugin-Entwicklung: Abhängigkeiten richtig setzen

Rating:

by Alexander Ebert, Tuesday, April 5th 2011, 2:52pm

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>

This article has been read 8,586 times.

Categories: Community Framework, Entwicklung, Plugin, Tipps

Go to the top of the page

Comments (4)

4

by Tr3kk3r (Monday, August 1st 2011, 7:31pm)

Was ist dir denn nun unklar?

Du schaust. wo du dich einklinken willst. Ist das ein Sonstiges paket => Wunderbar, das setzt du als plugin_tag und bist fertig.

Ist das bereits ein plugin, so schaust du, wodrauf dieses Plugin seinen plugin-tag gesetzt hat, und setzt den plugin-tag darauf, und requirest das plugin.

erweiterst du nur das wcf und kein anderes sonstiges paket, so setzt du das wcf in den plugintag.

wenn du ein sonstiges paket erstellen willst, brauchst du erst keinen plugin tag.
3

by Marcel Petzold (Saturday, July 30th 2011, 3:39pm)

Kannst du mir bitte einmal genauer erklären, wie man Abhängigkeiten nun korrekt setzt?

Ich kann daraus noch immer nicht erschließen, ab wann ich welche Abhängigkeit setzen muss. Am besten wäre es an einem direkten Beispiel einer package.xml, allerdings nicht aus einem WL Paket, da ich das dann auch nicht kapieren würde.
2

by Alexander Ebert (Saturday, April 16th 2011, 1:52pm)

Die Berechnung der Abhängigkeiten ist aktuell bereits sehr aufwendig und komplex. Um diesen Fall zuzulassen, müsste eine weitere Rekursionsstufe hinzukommen, wobei die Komplexität sich um n Schleifen erhöhen, wobei n die Anzahl der Plugins für Plugins darstellt.

Es ist hierbei möglich, sich als Plugin für dasselbe Paket zu registrieren, womit - unter Angabe der Abhängigkeit auf das Plugin-Paket - genau das gleiche erreichbar ist.
1

by Rudi (Wednesday, April 13th 2011, 8:48am)

"Der plugin-Tag darf nicht gesetzt werden, wenn das Zielpaket selbst bereits ein Plugin ist (entsprechend selbst einen plugin-Tag aufweist)"
Welchen technischen Hintergrund hat das eigentlich? Ich hatte bei meiner Blog Modification eben dieses Problem und wollte ursprünglich mein Paket als Plugin für com.woltlab.wcf.user.blog umsetzen - denn imho wäre das rein logisch richtig. Effekt war dann dass mein Plugin nie geladen wurde (konkret die Eventlistener). Warum? Also habe ich com.woltlab.wcf in die package.xml geschrieben und nach dem Upload im Plugin-Store sagte man mir, dass das falsch sei (der Artikel erklärt jetzt warum) und ich com.woltlab.wcf.page.user.profile nehmen soll.

Go to the top of the page

Blog navigation

by Alexander Ebert (Friday, February 17th 2012, 11:42pm)

WoltLab Community Forum

Profile of "Alexander Ebert"

You have to register first, to connect to this user.