PHP-Projekte mit Arbit managen
Kommentare

Pattern: Signal Slot
Zum Verteilen der Signale in Arbit kommt das Pattern Signal Slot zum Einsatz. Dabei geht es darum, dass Komponenten Signale emittieren können und beliebige andere Komponenten auf

Pattern: Signal Slot

Zum Verteilen der Signale in Arbit kommt das Pattern Signal Slot zum Einsatz. Dabei geht es darum, dass Komponenten Signale emittieren können und beliebige andere Komponenten auf diese Signale reagieren können. Dazu braucht man zuerst einen so genannten Signal Slot Handler, bei dem man sich für Signale registrieren kann. Dies könnte zum Beispiel wie in Listing 1 aussehen.

Listing 1
$signalSlotHandler = new MySignalSlotHandler();
$signalSlotHandler->handle(
    "newIssue",
    array( $myModule, "newIssueAction" )
);
$signalSlotHandler->handle(
    "newIssue",
    array( $yourModule, "notificationAction" )
);

SignalSlotHandler ist nur für die Verteilung der Signale zuständig. Damit ein Signal in Empfang genommen werden kann, muss man sich dafür registrieren, was hier über die handle()-Methode passiert. Dieser Methode wird üblicherweise ein String übergeben, der das Signal identifiziert, sowie ein Callback um zu definieren, welche Methode wo aufgerufen wird, wenn das Signal emittiert wird. Es ist möglich, dass sich beliebig viele Komponenten für ein solches Signal registrieren oder eventuell auch gar keine. Solange das Signal nicht emittiert wird, passiert allerdings auch nichts, und die Callbacks werden nicht aufgerufen. Um ein Signal zu emittieren wird SignalSlotHandler erneut gebraucht:

$signalSlotHandler->emit("newIssue", $someData );

Bei dem Emittieren des Signals wird erneut der Signalname als Identifikator angegeben und je nach Implementierung können noch zusätzliche Daten übergeben werden. Intern wird der Signal Slot Handler nun alle Komponenten, die sich für das Signal registriert haben, aufrufen. Eine definierte Reihenfolge gibt es hierbei normalerweise nicht. Dadurch, dass beliebig viele Komponenten durch ein Signal getriggert werden können, kann es natürlich auch keine sinnvollen Rückgabewerte geben. Wenn eine bidirektionale Kommunikation notwendig ist, lässt sich das üblicherweise durch ein erneutes Emittieren eines Signals in der getriggerten Komponente umsetzen.

Sourcecode-Integration

Interessant wird die Modulinteraktion erst richtig, wenn es um die Integration von Sourcecode in das Projekt-Tracking geht. Denn logischerweise ist der Sourcecode der zentrale, aber in Projekt-Tracking-Lösungen oft vernachlässigte Bestandteil des Projekts. Nicht umsonst etablieren sich Continuous-Integration-Lösungen wie Jenkins mittlerweile in immer mehr Unternehmen. Dazu kommen noch Full-Stack-Project-Tracker, wie der Atlassian Stack mit Jira, Bamboo & FishEye. Genau in die gleiche Richtung stößt auch Arbit und bietet letztendlich ein Open-Source-Framework um genau das umzusetzen. Wobei gerade fokussiert auf PHP schon vieles funktioniert. Grundsätzlich funktionieren Module etwa für Build oder CI aber auch für Software in beliebigen anderen Sprachen.

Wie schon zuvor erwähnt, implementiert Arbit ein Sourcecode-Modul, das mithilfe des VCS-Wrappers [2] mit verschiedenen Versionsverwaltungssystemen umgehen kann. Der VCS Wrapper ist eines der aus Arbit extrahierten Subprojekte, das mittlerweile auch in anderer Software eingesetzt wird, und bietet eine Abstraktion zum Auslesen von Informationen aus verschiedenen Versionsverwaltungssystem an. Mithilfe eines Cronjobs kann der Sourcecode eines Projekts regelmäßig auf Aktualisierungen überprüft werden. Im Falle einer Aktualisierung des Sourcecodes wird dann entsprechend durch das Source-Modul ein Signal emittiert, das zusätzlich auch alle relevanten Informationen zu dem Sourcecode enthält. Auf dieses Signal können dann andere Module reagieren und ihre Arbeit verrichten.

Das Issue-Tracking-Modul kann zum Beispiel auf Basis der Commit Message den Status von Issues verändern und das PHPDoc-Modul kann die API-Dokumentation neu generieren. In dem Moment der Neugenerierung der API-Dokumentation werden Dokumentationsfehler auffallen, sofern welche existieren. Dies ist der Moment, in dem Module wie das PHPDoc-Modul mit Signalen antworten können (Abschnitt: „Pattern: Signal Slot).

Für sämtliche Dokumentationsfehler, die dem PHPDoc-Modul auffallen, oder auch sämtliche Überschreitungen von Metrikgrenzen, die dem PHPDepend-Modul auffallen, werden zusammen mit Datei und Zeilennummer Signale emittiert, die von dem Source-Modul anschließend verwendet werden um den Sourcecode zu annotieren. Wie in Abbildung 1 zu sehen ist, werden in der Sourcecode-View diese Informationen eingeblendet, sodass man sie beim Betrachten oder Code-Review direkt verfügbar hat. Grundsätzlich kann durch den Signal-Slot-Mechanismus jedes Modul solche Annotationen vornehmen. Dies betrifft insbesondere auch mögliche Kommentare durch ein Code-Review-Modul, das bislang aber noch niemand entwickelt hat.

Abb. 1: Metrikannotationen im Source-Modul

Themen der nächsten Seiten

  • Kontinuierliche Integration
  • Grafische Aufbereitung
  • Status
  • Informationen zum Autoren
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -