"Optionale" vs. "Erzwungene" Events?

[gn#36]

Ich dachte gerade über Kombinationen von Extensions nach. Hierbei habe ich mich gefragt, wie Events behandelt werden, wenn das jeweilige Gegenstück nicht existiert.

Ich kann ja beispielsweise in meine Extension A einen Listener einbauen, der sich in die Extension B einklinken soll. Was passiert nun, wenn Extension B aber gar nicht installiert ist, der Hook also gar nicht existiert? Führt das beim auslesen der services.yml zu einem Fehler? Oder wird der betreffende Listener einfach nur nicht ausgeführt? Sieht das bei den Template Events anders aus?

Unabhängig davon, wie sich phpBB nun in dem Fall konkret verhält, gibt es die Möglichkeit, das jeweils andere Verhalten zu bekommen? Kann ich also dafür sorgen, dass die Extension sich nicht installieren lässt, wenn Extension B nicht existiert, bzw. bewirken, dass bei Fehlen von Extension B (im anderen Fall) der Listener eben einfach ignoriert wird?

Spontan hätte ich eine migration erstellt, die von einer migration in der anderen Extension abhängt um einen Installationsfehler zu produzieren, oder lassen sich Abhängigkeiten von anderen Extensions in der composer.json definieren, analog zu den Abhängigkeiten, die dann unter vendor abgelegt werden? Wie würde sich phpBB in dem Fall verhalten? Installiert es einfach die andere Migration, obwohl die andere Extension möglicherweise nur hochgeladen, aber gar nicht aktiviert ist? Wie verhält sich das, wenn Extension B deaktiviert wird? Ich nehme nicht an, dass das auch Extension A deaktivieren würde, oder?

[Elsensee]

Hmm.. Interessante Fragen..

Ich kann ja beispielsweise in meine Extension A einen Listener einbauen, der sich in die Extension B einklinken soll. Was passiert nun, wenn Extension B aber gar nicht installiert ist, der Hook also gar nicht existiert? Führt das beim auslesen der services.yml zu einem Fehler? Oder wird der betreffende Listener einfach nur nicht ausgeführt? Sieht das bei den Template Events anders aus?

Wenn ein Event nicht existiert und du dennoch dem Event eine Methode zuweist, passiert nichts. (die services.yml hat damit auch nichts zu tun)
Das passiert aufgrund der internen Funktionsweise von Symfony. Die Zuordnung Event => Methode wird in Symfony in einem Array gespeichert mit der gleichen Zuordnung. Wird nun ein Event getriggert, guckt Symfony welche Funktionen im Array mit dem Key "Event" verfügbar sind.
Also einfach als würde es nie aufgerufen werden.

Bei Template-Events läut das ähnlich; hier wird bei einem Event im Template einfach nach einer Event-Datei in allen Extensions gesucht und wenn's diese nicht gibt, dann Pech.

Unabhängig davon, wie sich phpBB nun in dem Fall konkret verhält, gibt es die Möglichkeit, das jeweils andere Verhalten zu bekommen? Kann ich also dafür sorgen, dass die Extension sich nicht installieren lässt, wenn Extension B nicht existiert, bzw. bewirken, dass bei Fehlen von Extension B (im anderen Fall) der Listener eben einfach ignoriert wird?

Ja. Du kannst in der ext.php public function is_enableable() implementieren. Dort kannst du dann jegliche Checks durchlaufen lassen und true zurückgeben, wenn du sie zur Installation freigibst und false halt wenn nicht. Eine Fehlermeldung kann man an dieser Stelle glaube ich nicht ausgeben, aber vielleicht könnte hier auch ein einfaches trigger_error funktionieren. (Auch wenn das zu ungewünschten Ergebnisse mit der Konsolenschnittstelle führen könnte)

[D@ve]

Ja. Du kannst in der ext.php public function is_enableable() implementieren.

Hmmm ist vielleicht nicht die eleganteste Lösung

Theoretisch müsste man das über migrations lösen können

Code: Alles auswählen

    static public function depends_on()
    {
        return array('\dave\seo_url\migrations\release_1_0_0');
    }

Da könnte man ja theoretisch auch die migrationen von anderen Extensions angeben.

Gruß, Dave

[Elsensee]

Warum nicht?

Wenn du bei is_enableable() false zurückgibst, wird im ACP eine schöne Fehlermeldung á la "Die Extension kann nicht aktiviert werden" ausgegeben.
Klar kannst du auch bei den Migration Abhängigkeiten angeben, was ich zusätzlich noch tun würde - nur nicht alleine.

[D@ve]

Klar kannst du auch bei den Migration Abhängigkeiten angeben

Macht das nicht mehr Sinn? Da wird doch (hoffentlich) auch eine entsprechende Fehlermeldung ausgegeben. Vermutlich eine die mehrsagender ist. Nachteilhaft wäre hier nur, dass die andere Extension wohl automatisch mit-installiert würde, wenn sie vorhanden ist.

Vermutlich wird is_enabled() garnicht erst ausgeführt, wenn er die migration in depends_on() nicht findet.

[nickvergessen]

Klar kannst du auch bei den Migration Abhängigkeiten angeben

Macht das nicht mehr Sinn? Da wird doch (hoffentlich) auch eine entsprechende Fehlermeldung ausgegeben. Vermutlich eine die mehrsagender ist. Nachteilhaft wäre hier nur, dass die andere Extension wohl automatisch mit-installiert würde, wenn sie vorhanden ist.

Vermutlich wird is_enabled() garnicht erst ausgeführt, wenn er die migration in depends_on() nicht findet.

Der Migrator weiß aber nicht von welcher Extension die Migration ist, die fehlt.
Wenn die Ext A nicht ohne Ext B geht, sollte is_enableable() benutzt werden.
Wenn nur eine Anzeige dann nicht geht muss nichts getan werden.

[gn#36]

Naja, ich finde die Abhängigkeit von anderen Migrations eigentlich schon sinnvoll. Das erlaubt einem modulare Extensions zu bauen, die sicher zu einander kompatibel sind. Je nach dem was das für eine Extension ist reicht es ja auch, wenn von der anderen Extension die Daten in der Datenbank sind.

Zum Beispiel könnte man auf die Weise für eine Kalender Extension ein alternatives Interface bauen, das die Daten der anderen Kalender Extension nutzt und somit dem Admin erlaubt zwischen beiden umzuschalten. Der hat vielleicht festgestellt, dass er lieber die andere Extension weiternutzen will und den Funktionsumfang des Originals eigentlich gar nicht braucht. Er kann einfach die unerwünschte Extension deaktivieren und nutzt die Daten mit der anderen Extension weiter.

Einen Schritt weiter gedacht könnte man auch eine Meta-Extension bauen, die selbst überhaupt kein Interface mehr bereitstellt, sondern nur die Daten verwaltet. Analog zu den phpBB Styles kann man dann darauf aufbauend verschiedene weitere Extensions bauen, die alle kompatibel sind und sich leicht austauschen lassen, weil sie die selben Daten nutzen. Weil es von der Daten Extension dann aber logischerweise auch verschiedene Versionen geben kann wäre in meinen Augen die logische Vorgehensweise, das mit Abhängigkeiten von Migrations zu lösen.

[nickvergessen]

Naja da würdest du dann aber in der require section in der composer.json eintragen, dass deine Extension die Extension XYZ braucht.
Und nicht von einer einzelnen Datenbank Migration abhängen.

Das Feature das zu Überprüfen fehlt noch und wird hoffentlich mit 3.2 kommen, aber das ist eher, was du suchst.

[gn#36]

Das stimmt, das würde ich zusätzlich machen.