Intranetsoftware für jedermann – Teil 4

Ein System kann zu keiner Zeit komplett fertig sein. Meist ändern sich die Bedürfnisse der Nutzer im Laufe der Zeit oder der Markt bringt neue Ideen hervor, die man gerne in seinem System nutzen möchte. Oftmals ist einem zu Beginn auch noch nicht klar, welche Funktionen unbedingt benötigt werden.

Aus diesem Grund schreibt man das System so, dass es jederzeit möglich ist, Erweiterungen hinzuzufügen.

Doch was sind Erweiterungen?

Definition

Ich definiere Erweiterungen als Zusatzmodule, die ein Komplettsystem um praktische Funktionen erweitern können.

Erweiterungen greifen auf das bestehende System zu, um dessen Module – wie die Authentifizierung – zu nutzen. Das eigentliche System greift nicht direkt auf die Erweiterung zu, sondern dient lediglich als Host.

Ein Vorteil dieser Architektur ist, dass dem System die Erweiterung nicht bekannt sein muss. Die Erweiterung selbst übernimmt alle Aufgaben, die es für das Funktionieren benötigt. Würde das System hingegen alle seine Erweiterungen kennen müssen, so müsste es lernen, sobald ein neues hinzugefügt wird. Alternativ müsste das komplette System ein Update machen, sobald ein neues Modul installiert werden soll. Bei Erweiterungen macht das jedoch meiner Meinung nach keinen Sinn, denn Erweiterungen sollen nur kleinere Aufgaben übernehmen und das System nicht um Hauptkomponenten erweitern. Außerdem stellt es einen sehr hohen Aufwand dar, was gerade für Anfänger durchaus schwer umzusetzen ist.

In meinem Fall muss lediglich das Menü des Intranets so aufgebaut sein, dass es automatisch einen bestimmten Ordner – beispielsweise Plugins – ausliest und für jeden Unterordner eine Verknüpfung erstellt. So kann man nach und nach neue Module hinein kopieren und das System sorgt für die Integration. Es ist lediglich wichtig – bzw. einfacher – wenn man in seinem Modul die GUI mit dem Namen index.php ablegt, so dass man direkt an diese Datei weitergeleitet wird, sobald der Ordner über das Menü aufgerufen wird.

Natürlich könnte man seine Startdatei im Modulordner anders nennen und diese entsprechend verknüpfen. Jedoch müsste man sich konsequent an diese Benennung halten, so dass alle Erweiterungen absolut gleich sind. Das System könnte diese sonst nicht (fehlerfrei) ansprechen.

Aufbau

Kurz und knackig: Ein Modul besteht aus zwei Dateien. Die erste Datei ist die GUI, welche später in das Intranet integriert wird. Die zweite Datei enthält den Code – bzw. die Klasse. Dort werden alle Daten verarbeitet und weitergereicht. Natürlich kann die GUI auch aus mehreren Dateien bestehen, wenn die Erweiterungen umfangreicher sind. Bei kleineren Erweiterungen kann man jedoch alles in eine Datei packen.

Natürlich könnte man nun auch die Dateien in den ursprünglichen Aufbau integrieren. Doch für die Nachlieferung von Erweiterungen ist es einfacher, wenn man ein komplettes Modul nicht einsortieren muss, sondern lediglich ein Ordner kopiert.

Jede meiner Erweiterungen liegt in einem eigenen Ordner. Dieser Ordner heißt wie die Erweiterung und enthält die GUI sowie einen weiteren Ordner. Diesen nennt man beispielsweise core oder logik. Die Namensgebung hängt auch ein wenig vom eigenen Geschmack ab. Man sollte sich jedoch an dieses Schema halten und sich bei der nächsten Erweiterung nicht wieder etwas neues einfallen lassen. Damit macht man es späteren Nutzern schwerer, sollten sie etwas ändern wollen. In diesem Unterordner liegt die Applikationslogik, die für die Verarbeitung zuständig ist. Diese Logik kommuniziert mit den Methoden der anderen Module des Systems und ist damit in der Lage, auf die Datenbank zuzugreifen und Funktionen zu beschränken.

Übrigens: Gerade bei Erweiterungen würde ich Verlinkungen genau ansehen. Sich per ../ durch die Verzeichnisse zu navigieren kann funktionieren, kann jedoch auch schnell schief gehen. Eventuell greift man hier auf PHP zurück und nutzt $_SERVER[„DOCUMENT_ROOT“].

Ausblick

Durch den gut strukturierten Aufbau des Gesamtsystems, lassen sich später Erweiterungen leicht an das bestehende System anknüpfen. Jeder Betreiber des Intranets oder einer Kopie kann später ohne viel Aufwand sein System erweitern und spezielle Funktionen, die er benötigt, einbauen. Sofern keine passenden Erweiterungen vorhanden sind, kann man sich diese auch selbst schreiben.

Natürlich eignet sich das Ganze nur, wenn man Zugriff auf den Server hat. Denn ohne Zugriff ist man nicht in der Lage Module in das bestehende System zu laden. Das Ganze stellt also keine API für Fremdsysteme dar. Eine API kann man natürlich auf die gleiche Art und Weise einbauen und somit fremden Systemen Zugriff auf Daten geben. Hierzu schreibe ich höchstwahrscheinlich nochmal einen eigenen Artikel.

Der Aufbau ist zukunftsorientiert, denn man kann auf Probleme der Zukunft schnell reagieren, ohne das Gesamtsystem verändern zu müssen. Benötigt eine Familie beispielsweise ein zusätzliches Modul, so kann es ein Freiwilliger programmieren und der Systemadministrator dieses prüfen und einbauen.