39.3 Architektur 
Wie Sie gesehen haben, ist es generell nicht sehr schwer, ein Modul zu schreiben. Trotzdem ist das eben besprochene Beispiel nur eine Minimalvariante und softwaretechnisch nicht sehr schön gelöst. Stellen Sie sich vor, Sie haben ein komplexes Modul erstellt, das über viele hundert Zeilen hinweg eine HTML-Ausgabe erzeugt. Garantiert tritt der Fall ein, dass sich die Ausgabe irgendwann verändern muss, sei es, weil Sie ein Redesign der Webseite vornehmen, sei es, dass bestimmte HTML-Tags nicht Ihren Wünschen entsprechen. Sie müssen sich nun durch den kompletten Code wühlen, um die entsprechende Stelle zu finden und zu verändern. Das ist sehr aufwendig und gegebenenfalls auch fehleranfällig. Sinnvoller wäre es, die Ausgabe an einem zentralen Ort zu verwalten und im Zweifelsfall nur in diesem Bereich Änderungen vornehmen zu müssen.
39.3.1 Model-View-Controller 
Aus zahlreichen Praxis-Erfahrungen hat sich in der Softwareentwicklung eine Architektur herausgebildet, die es Ihnen erlaubt, die Ausgaben und die Speicherung der Daten von der eigentlichen Programmlogik zu trennen. Damit gewinnen Sie enorm an Flexibilität. Diese Architektur nennt man Model-View-Controller-Architektur (MVC). Sie besteht, wie der Name schon sagt, aus drei Komponenten:
- Model: Hier wird alles gesammelt, was mit den Daten zu tun hat, die ein Programm verwaltet. Insbesondere finden sich dort Routinen, die die Speicherung, Änderung und das Lesen dieser Daten betreffen. Damit wird es sehr einfach, beispielsweise von einer Ablage der Daten im Dateisystem auf eine Ablage in der Datenbank zu wechseln. Sie müssen nur den Code ändern, der das Model beschreibt.
- View: Dieser Bereich ist für die Ausgabe zuständig. Hier werden die nötigen Variablen gesammelt und in eine Vorlage (Template) an den entsprechenden Stellen eingebaut. Die Daten kommen in der Regel vom Model und werden im View-Bereich nicht mehr verändert.
- Controller: Dieser ist für die Programmlogik zuständig. Das ist in unserem Fall vor allem eine Reaktion auf Benutzereingaben, beispielsweise das Aufrufen einer URL. Der Controller legt fest, wie Daten verändert werden sollen, und gibt diese Daten dann an die View-Komponente weiter.
Die drei Bereiche sollten auch physikalisch in (mindestens) drei separaten Dateien liegen. Das erleichtert die Wartbarkeit und ermöglicht es zudem, eine Aufteilung der Aufgaben an verschiedene Personen vorzunehmen. So ist denkbar, dass der View-Programmteil von einem Designer bearbeitet wird.
Sehen wir uns das Ganze einmal für Joomla!-Module an. Hier ist es etwas einfacher, da Module in der Regel keine eigenen Daten verwalten. Wir benötigen daher nur eine Datei für den generellen Programmablauf und eine Datei für das Template. Wir wollen das Modul ein wenig umschreiben und über eine Zufallsfunktion festlegen, in welcher Farbe die Schrift ausgegeben wird. Unser Modul hat daher die folgenden Dateien:
- mod_hallojoomla_vc.php enthält ein Gerüst des Moduls.
- helper.php führt die Aufgaben des Controllers durch.
- mod_hallojoomla_vc.xml wird für die Installation und eventuelle Parameter auf der Einstellungsseite benötigt.
- index.html dient zur Vorbeugung gegen unberechtigten Zugriff.
- tmpl/default.php stellt das Template und somit den View-Part dar.
- tmpl/index.html dient wiederum als Sicherheitsmaßnahme.
Zwei Dinge fallen auf: Erstens gibt es neben dem eigentlichen Modul-Code noch eine Datei helper.php. Warum wird der Controller nicht direkt in der Modul-Datei ausgeführt? Auch das wäre möglich. Der Grund ist, dass die Datei mod_hallojoomla_vc.php sozusagen nur die Klammer darstellt und zwischen Controller und View vermittelt, wohingegen die Programmlogik aus Gründen der Übersichtlichkeit in helper.php ausgelagert wird. Zweitens liegt das Template in einem eigenen Verzeichnis. Der Grund dafür ist der Mechanismus der Template-Overwrites (vgl. Kapitel 14, »Barrierefreiheit«), der diese Struktur voraussetzt. Wenn Sie der vorgegebenen Struktur folgen, ist Ihr Modul auf alle Fälle konform mit dem Aufbau der Module, die Joomla! bereits mitliefert.
39.3.2 Die Beschreibungsdatei
Die Index-Dateien wurden bereits in Listing 39.2 vorgestellt. In der Datei mod_hallojoomla_vc.xml müssen ein paar Änderungen vorgenommen werden. Ergänzen Sie die Zeilen, die fett hervorgehoben sind:
1 <?xml version="1.0" encoding="utf-8"?> 2 <install type="module" version="1.5.0"> 3 <name>Hallo Joomla VC</name> … 12 <files> 13 <filename module="mod_hallojoomla_vc">14 mod_hallojoomla_vc.php
Listing 39.4 mod_hallojoomla_vc.xml
Sie sehen, dass in den Zeilen 17 mit 19 die Einträge für die neuen Dateien vorgenommen wurden. Unterverzeichnisse können Sie hier bedenkenlos angeben, diese werden beim Installationsvorgang angelegt.
39.3.3 Der Controller
Die zufällige Bestimmung der Schriftfarbe ist ein Fall für den Controller, der sich in der Datei helper.php befindet:
1 <?php
2 defined( '_JEXEC' ) or die( 'Restricted Access' );
3 class ModHalloJoomlaVCHelper
4 {
5 public function getRandomColor()
6 {
7 $r = rand(0,255);
8 $g = rand(0,255);
9 $b = rand(0,255);
10 $col = sprintf("#%02X%02X%02X",$r,$g,$b);
11 return $col;
12 }
13 }
14 ?>Listing 39.5 helper.php
Die Codebasis von Joomla! ist seit der Version 1.5 komplett objektorientiert.
| Exkurs: Objektorientierte Programmierung (OOP) |
|
Obwohl sich in der Programmierwelt das objektorientierte Paradigma schon lange entwickelt hat, scheint es sich erst langsam auch in der PHP-Welt durchzusetzen. Hier ein kleiner Crash-Kurs, der Ihnen die wichtigsten Konzepte und Formalismen zeigen soll. Die große Änderung gegenüber der prozeduralen Programmierung besteht darin, dass in der OOP Funktionen und die Daten, die verwendet werden, innerhalb eines Objekts verwaltet werden. Ein Objekt besteht also aus Methoden (Funktionen) und Eigenschaften (Daten). Um ein Objekt zu programmieren, muss zunächst eine Art Bauplan erstellt werden, die Klasse. Das geht so: class meinObjekt {
var $daten;
public function ausgabe()
{
echo "Ausgabe: ".$daten;
}
}Die Funktion kann nun direkt aufgerufen werden. Das nennt man einen statischen Aufruf: meinObjekt::ausgabe(); Diese Variante unterscheidet nicht sehr von der bisherigen prozeduralen Programmierweise, bis auf die Tatsache, dass in einem Objekt mehrere Methoden gebündelt werden können, die zusammengehören. Das Wort public gibt an, wer die Methode verwenden darf. In diesem Fall ist es jedem Programmteil erlaubt, auf sie zuzugreifen. Ist eine Methode hingegen protected oder private, darf sie nur innerhalb der Klasse verwendet werden. Statische Objekte werden dann verwendet, wenn man die Daten für das gesamte Programm nur einmal benötigt. Anders sieht die Sache aus, wenn die Objekte mehrfach verwendet werden. Ein Beispiel ist das Modul. Hiervon gibt es auf der Joomla!-Seite mehrere, die jeweils eigene Daten besitzen. In diesem Fall wird von der Klasse jeweils eine sogenannte Instanz erzeugt. Um bei der Metapher zu bleiben – aus dem Bauplan wird nun ein »Ding« erstellt: $obj = new meinObjekt(); $obj2 = new meinObjekt(); Die Elemente von diesen Instanzen werden mithilfe des Pfeil-Operators angesprochen: $obj1->daten = 'Erstes Objekt'; $obj2->daten = 'Zweites Objekt'; Wenn Sie jetzt die beiden Objekte zur Ausgabe bewegen, wird das mit den jeweiligen Daten gemacht: $obj1->ausgabe(); $obj2->ausgabe(); ergibt: Ausgabe: Erstes Objekt Ausgabe: Zweites Objekt Das ist nicht spektakulär, aber effektiv: Die Daten sind fest zugeordnet und die Verwechslungsgefahr ist stark verringert. |
Wir tun also gut daran, unsere Programme ebenfalls, so weit es möglich ist, in Objekte zu packen. Das geschieht in Zeile 3. Hier wird eine Klasse ModHalloJoomlaVCHelper definiert, die die Funktionen unseres Moduls kapselt. Innerhalb der Klasse beschreiben wir eine Funktion getRandomColor, deren Aufgabe es ist, einen zufälligen Farbwert zu erzeugen. Dieser Wert ist in HTML üblicherweise eine Hexadezimalzahl (z. B. #CAFE01), die die Stärke der Rot-, Grün- und Blaukomponenten der Farbe festlegt, und zwar als Zahl zwischen 0 und 255. In den Zeilen 7–9 werden also die einzelnen Werte über eine Zufallsfunktion (rand) erzeugt. Jetzt müssen sie noch in Hexadezimalwerte konvertiert werden. Das geschieht in Zeile 10, wo sie auch aneinandergesetzt werden. In Zeile 11 wird der Wert zurück an das aufrufende Programm übergeben.
39.3.4 Der Rahmen
Das ist in unserem Fall die Datei mod_hallojoomla_vc.php, die folgendermaßen aussieht:
1 <?php
2 defined( '_JEXEC' ) or die( 'Restricted Access' );
3 require_once(dirname(__FILE__).DS.'helper.php');
4 $color = ModHalloJoomlaVCHelper::getRandomColor();
5 require_once(
6 JModuleHelper::getLayoutPath('mod_hallojoomla_vc'));
7 ?>Listing 39.6 mod_hallojoomla_vc.php
In Zeile 3 wird die Verbindung zum Controller hergestellt, indem die Datei helper.php eingebunden wird. Die Funktion dirname bestimmt dabei den Pfad der aktuellen Datei (hier mod_hallojoomla_vc.php). In der Konstante DS ist das Zeichen gespeichert, das im jeweiligen Betriebssystem als Pfadtrennzeichen fungiert (unter Windows ist das der Backslash \, unter Linux/Mac der Slash /). Danach wird in Zeile 4 der Farbwert vom Controller abgeholt. In den Zeilen 5 und 6 wird die Model-Datei eingebunden. Der Pfad wird hier über eine Funktion festgelegt, die Joomla! bereits mitbringt und die normiert ist: ein weiterer Grund dafür, sich an die Konvention zu halten, die Template-Dateien im Verzeichnis tmpl abzulegen.
39.3.5 Die View
Jetzt fehlt nur noch die Ausgabe, die in der Datei default.php erzeugt wird:
1 <?php 2 defined( '_JEXEC' ) or die( 'Restricted Access' ); 3 ?> 4 <font color="<?php echo $color; ?>"> 5 Hallo Welt! 6 </font>
Listing 39.7 default.php
PHP-Templates machen sich die Möglichkeit der Programmiersprache zunutze, dass alles, was nicht innerhalb von <?php ... ?> steht, einfach ausgegeben wird. Daher wird die erste PHP-Klammer auch schon in Zeile 3 geschlossen. In Zeile 4 wird das font-Tag zunächst einfach ausgegeben. Aber innerhalb der Anführungszeichen des color-Attributs wird PHP noch einmal aktiviert, um den Farbwert auszugeben, den wir zuvor vom Controller abgeholt haben. Der Wert dieser Variablen ist gesetzt, weil die Datei default.php ja einfach in die mod_hallojoomla_vc.php eingebunden wird und daher auch in deren Kontext ausgeführt wird. Die Zeilen 5 und 6 sind wieder reine HTML-Ausgaben.
Wenn Sie die Änderungen in der Modulstruktur vorgenommen haben, rufen Sie das Modul im Frontend mehrfach auf. Sie werden sehen, dass sich die Farbe der Ausgabe jedes Mal ändert.
