Singleton-Instanz

Komponenten anmelden

Komponenten abmelden

Komponenten eines Komponenteninterfaces finden

Mitteilung an alle Komponenten eines Komponenteninterfaces

< Bestandteile von Plugins | Plugin-Spezifikation 2.0 | Plugin-Versionsschema >

< Bestandteile von Plugins | Plugin-Spezifikation 2.0 | Plugin-Versionsschema >

< Bestandteile von Plugins | Plugins.Spezifikation | Plugin-Versionsschema >

«|Plugins.Spezifikation|»

$manager = Studip_ComponentManager::instance();

$manager = Studip_ComponentManager::instance(); $manager->register('ExampleComponent');

$manager = Studip_ComponentManager::instance(); $manager->deregister('ExampleComponent');

$manager = Studip_ComponentManager::instance(); $components = $manager->components('ExampleComponent');

1. use those components

$result = array(); foreach ($components as $component) {

  $result[] = $component->exampleMethod(42);

} […]

$manager = Studip_ComponentManager::instance(); $manager->signal('TodoComponent', 'todoAdded', array($arg1, $arg2, $arg3));

Um alle Komponenten zu erhalten, die ein bestimmtes Komponenteninterface implementieren, sendet man #components an den Komponentenmanager:

  $manager = Studip_ComponentManager::instance();
  $components = $manager->components('ExampleComponent');

  # use those components
  $result = array();
  foreach ($components as $component) {
    $result[] = $component->exampleMethod(42);
  }
  [...]

Gelegentlich will man an allen Komponenten eines Komponenteninterfaces nur eine Methode aufrufen, ohne dass man deren Rückgabewert benötigen würde – wenn man den Komponenten also nur etwas "mitteilen" will. Für diesen Fall kann man #signal senden:

  $manager = Studip_ComponentManager::instance();
  $manager->signal('TodoComponent', 'todoAdded', array($arg1, $arg2, $arg3));

Der Komponentenmanager definiert u.a. folgende Methoden:

<?php

class Studip_ComponentManager {

  static function instance();

  function register($component);
  function unregister($class);

  function components($interface_name, $filter = NULL);
  function signal($interface_name, $method, $args = array());
}

Die Klassenmethode #instance liefert die Singleton-Instanz des Komponentenmanagers:

  $manager = Studip_ComponentManager::instance();

An dieser Instanz kann dann eine Komponente mittels ihres Namens registriert werden:

  $manager = Studip_ComponentManager::instance();
  $manager->register('ExampleComponent');

Achtung: Es muss sichergestellt werden, dass der Quellcode der benannten Komponente bereits geladen ist. Da der Komponentenmanager die Komponente nicht untersuchen kann.

Auf ähnliche Weise kann eine Komponente auch wieder beim Komponentenmanager abgemeldet werden:

  $manager = Studip_ComponentManager::instance();
  $manager->deregister('ExampleComponent');

Auch hier gilt, dass der Quellcode der Komponente geladen sein muss.

Um alle Komponenten zu erhalten, die ein bestimmtes Komponenteninterface implementieren,

Ein Komponenteninterface definiert eine Menge von Operationen, die eine Komponente ausführen können muss. (Beispiel: Einen Text für eine Box innerhalb der Stud.IP-Homepage liefern.)

Idealerweise werden Komponenteninterfaces eine feine Granularität aufweisen. Ein Gegenbeispiel ist das implizite Interface der alten Homepage-Plugins.

Komponenteninterfaces müssen ihrerseits das Markerinterface "Studip_Component" implementieren, damit der Komponentenmanager in die Lage versetzt wird, automatisch zwischen normalen Interfaces und Komponenteninterfaces unterscheiden zu können. Es ist ja immer möglich, dass eine Komponente auch Interfaces implementiert, die nichts mit der Komponentenarchitektur zu tun haben.

Komponenten

Komponenteninterfaces repräsentieren die "Steckdose", in die sich eine Komponente "einstöpseln" kann. Das "Einstöpseln" geschieht durch das Schreiben einer Klasse, die dieses Interfaces implementiert ("class ExampleComponent implements Studip_PortalComponent"). Ausserdem muss diese Klasse – die Komponente – beim weiter unten beschriebenen Komponentenmanager registriert werden.

Der Komponentenmanager ist für zwei Aufgaben zuständig. Zum einen können bei ihm Komponenten angemeldet und abgemeldet werden, zum anderen kann man über ihn alle Komponenten erhalten, die ein bestimmtes Komponenteninterface ("Steckdose") implementieren, um dann an diesen die im Komponenteninterface deklarieren Methoden aufzurufen. Da man nur Komponenten erhält, die dieses Komponenteninterface implementieren, kann man sicher sein, dass diese Methoden auch tatsächlich zur Verfügung stehen, da der Compiler dieses zusichert.

TODO

Der Komponentenmanager

Extension Points werden in PHP durch Interfaces abgebildet. Damit wird eine Schnittstelle sichergestellt, über die beide Seiten kommunizieren können. Ein solches Komponenteninterface sieht beispielweise so aus:

Dieses Komponenteninterface repräsentiert die "Steckdose", in die sich eine Komponente "einstöpseln" kann. Das "Einstöpseln" geschieht durch das Schreiben einer Klasse, die dieses Interfaces implementiert ("class ExampleComponent implements Studip_PortalComponent"). Diese Klasse muss noch beim im Folgenden beschriebenen Komponentenmanager registriert werden.

Dieses Interface repräsentiert die "Steckdose", in die sich eine Komponente "einstöpseln" kann. Das "Einstöpseln" geschieht durch das Schreiben einer Klasse, die dieses Interfaces implementiert ("class ExampleComponent implements Studip_PortalComponent"). Diese Klasse muss noch beim im Folgenden beschriebenen Komponentenmanager registriert werden.

Der Komponentenmanager

Der Komponentenmanager ist für zwei Aufgaben zuständig. Zum einen können bei ihm Komponenten angemeldet und abgemeldet werden, zum anderen kann man über ihn alle Komponenten erhalten, die ein bestimmtes Komponenteninterface ("Steckdose") implementieren, um dann an diesen die im Komponenteninterface deklarieren Methoden aufzurufen. Da man nur Komponenten erhält, die dieses Komponenteninterface implementieren, kann man sicher sein, dass diese Methoden auch tatsächlich zur Verfügung stehen, da der Compiler dieses zusichert — schliesslich muss eine Komponente ja das Komponenteninterface implementieren ("implements").

Jedes Plugin-Paket muss genau eine Plugin-Klasse enthalten (siehe Bestandteile). Diese Plugin-Klasse…

Dieses Interface repräsentiert die "Steckdose", in die sich eine Komponente "einstöpseln" kann. Das "Einstöpseln" geschieht durch das Schreiben einer Klasse, die dieses Interfaces implementiert ("class ExampleComponent implements Studip_PortalComponent"). Diese Klasse muss noch bei der Komponentenarchitektur registriert werden. (siehe TODO)

Integration/Komponentenarchitektur

(:toc anchors=visible:)

Um das Problem zu lösen, Stud.IP an bereits vorhandenen Stellen, also in seiner Kernfunktionalität, zu erweitern, kommt die im folgenden beschriebene Komponentenarchitektur zum Einsatz.

Diese Architektur kann sinnbildlich so erklärt werden, dass Stud.IP aus einer Menge an Komponenten besteht.

Eine Komponente ist ein funktionales Subsystem, dass einen Service im Kontext von Stud.IP anbietet. Beispiele: ein Fotoalbum für Benutzer, ein Newsfeed-Aggregator, ein Prüfungssystem usw. Der Stud.IP-Kern soll in diesem Zusammenhang der Einfachheit halber als eine einzelne Komponente gelten.

Jeder dieser Komponenten hat die Möglichkeit, "Steckdosen" (Extension Points) anzubieten, in die sich wiederum andere Komponenten "einstöpseln" können. Das erlaubt es einer Komponente, die Funktionalität einer anderen zu erweitern, ohne dass die erweiterte Komponente überhaupt wissen muss, dass es diese sie erweiternde Komponente überhaupt gibt. Erforderlich ist nur, dass die eine Komponente ihre "Steckdosen" (Extension Points) zur Verfügung stellt und nutzt und andere Komponenten sich in diese "Steckdosen" (Extension Points) einstöpseln können.

Grundsätzlich bietet zuallererst nur das Kernsystem solche Extension Points an. Jedes weitere installierte Plugin erhält aber die Möglichkeit, eigene Extension Points hinzuzufügen.

Extension Points werden in PHP durch Interfaces abgebildet. Damit wird eine Schnittstelle sichergestellt, über die beide Seiten kommunizieren können. Ein solches Interface sieht beispielweise so aus:

<?php

interface Studip_PortalComponent extends Studip_Component {

  function showOverview($unauthorizedview = TRUE);

  function hasAdministration();

  function hasUnauthorizedView();

  function hasAuthorizedView();
}

Jedes Plugin-Paket muss genau eine Plugin-Klasse enthalten (siehe Bestandteile). Diese Plugin-Klasse…

Extension Points werden in PHP durch Interfaces abgebildet. Damit wird eine Schnittstelle sichergestellt, über die beide Seiten kommunizieren können. Ein solches Interface sieht beispielweise so aus:

<?php

interface Studip_PortalComponent extends Studip_Component {

  function showOverview($unauthorizedview = TRUE);

  function hasAdministration();

  function hasUnauthorizedView();

  function hasAuthorizedView();
}

Integration/Komponentenarchitektur

(:toc anchors=visible:)

Um das Problem zu lösen, Stud.IP an bereits vorhandenen Stellen, also in seiner Kernfunktionalität, zu erweitern, kommt die im folgenden beschriebene Komponentenarchitektur zum Einsatz.

Diese Architektur kann sinnbildlich so erklärt werden, dass Stud.IP aus einer Menge an Komponenten besteht.

Eine Komponente ist ein funktionales Subsystem, dass einen Service im Kontext von Stud.IP anbietet. Beispiele: ein Fotoalbum für Benutzer, ein Newsfeed-Aggregator, ein Prüfungssystem usw. Der Stud.IP-Kern soll in diesem Zusammenhang der Einfachheit halber als eine einzelne Komponente gelten.

Jeder dieser Komponenten hat die Möglichkeit, "Steckdosen" (Extension Points) anzubieten, in die sich wiederum andere Komponenten "einstöpseln" können. Das erlaubt es einer Komponente, die Funktionalität einer anderen zu erweitern, ohne dass die erweiterte Komponente überhaupt wissen muss, dass es diese sie erweiternde Komponente überhaupt gibt. Erforderlich ist nur, dass die eine Komponente ihre "Steckdosen" (Extension Points) zur Verfügung stellt und nutzt und andere Komponenten sich in diese "Steckdosen" (Extension Points) einstöpseln können.

Grundsätzlich bietet zuallererst nur das Kernsystem solche Extension Points an. Jedes weitere installierte Plugin erhält aber die Möglichkeit, eigene Extension Points hinzuzufügen.

Extension Points werden in PHP durch Interfaces abgebildet. Damit wird

Jedes Plugin-Paket muss genau eine Plugin-Klasse enthalten (siehe Bestandteile). Diese Plugin-Klasse…

< Bestandteile von Plugins | Plugins.Spezifikation | Plugin-Versionsschema >

<< Bestandteile von Plugins | Plugins.Spezifikation | Plugin-Versionsschema >>

• Wir brauchen ein Interface (Studip_Component) zur Kennzeichnung von Komponenteninterfaces.
• Ein Komponenteninterface definiert eine Menge von Operationen, die ein Plugin ausführen können muss, wenn es eine solche Komponente sein möchte. (Beispiel: Einen Text für eine Box innerhalb der Stud.IP-Homepage liefern.)
• Diese Komponenteninterfaces sollten eher feingranular sein (Gegenbeispiel: Homepage-Plugin mit seinen zahlreichen Konfigurationsmöglichkeiten.).
• Die abstrakten Legacy-Plugins müssen diese implementieren. Vorteilhafterweise würde man dann nicht nur ein Komponenteninterface pro Legacy-Plugintyp haben, sondern viele. (Beispiel: Das Homepage-Plugin könnte und sollte >3 von solchen Komponenteninterfaces implementieren.)
• Derzeit enthalten die Legacy-Plugins Zustand, über den Punkt, an dem sie eingebunden werden. So existieren zum Beispiel für das AbstractStudipStandardPlugin die Methoden #getId und #setId, die wohl die Veranstaltungs- bzw- Einrichtungs-ID enthalten. Dieser Zustand sollte - sofern nötig (vielleicht sollte man das immer machen?) - explizit als Parameter in den Methoden, die in den Komponenteninterfaces deklariert werden, vorgesehen sein.