3.3 Der Haupt-Controller

Die Haupt-Controller-Klasse des Galileo-Press-Blogs trägt den Namen gpBlogController und wird im Unterverzeichnis classes/ abgelegt. Die Action-Controller werden später unter classes/actions/ angelegt. Damit innerhalb der Applikation auf diese Klassen zugegriffen werden kann, werden zwei Autoload-Dateien angelegt: blog_autoload.php und blog_action_autoload.php.

In der ersten Autoload-Datei wird zu Anfang nur der Haupt-Controller definiert, weitere Klassen folgen später. Wir werden dies von jetzt an nicht mehr explizit erwähnen, da der Autoload-Mechanismus in Abschnitt 2.2, »Autoload konfigurieren«, bereits ausführlich vorgestellt wurde. Weshalb an dieser Stelle zwei Autoload-Dateien eingeführt werden, wo doch auch die Aktions-Klassen in blog_autoload.php untergebracht werden könnten, wird in Kürze ersichtlich, wenn wir uns im Haupt-Controller eines kleinen Tricks bedienen.

3.3.1 Grundstruktur

Das Grundgerüst der Klasse gpBlogController hat die folgende Gestalt:

class gpBlogController
{
    protected static $instance;
    protected $actionSignals;
    protected $mainSignals;
    public static function getInstance()
    {
    }
    protected function __construct()
    {
    }
    protected function init()
    {
    }
    public function run()
    {
    }
    public function redirect( ezcUrl $url )
    {
    }
    public function display( $template, array $params )
    {
    }
    public function __get( $propertyName )
    {
    }
}

Listing 3.1 Controller-Grundgerüst

In weiten Teilen des GP-Blogs muss des Öfteren auf den Haupt-Controller zugegriffen werden. Außerdem soll sichergestellt sein, dass nur eine einzige Instanz der Klasse existiert. Mehrere Instanzen wären nicht nur unsinnig, sondern würden sich eventuell auch gegenseitig beeinflussen und stören. Beispielsweise könnte es passieren, dass beide Instanzen auf ein gesendetes Signal reagieren und somit Daten doppelt ausgegeben werden. Daher bedienen wir uns an dieser Stelle des objektorientierten Entwurfsmusters Singleton, welches Sie bereits in Abschnitt 2.3.4, »Lazy-Initialization«, kennengelernt haben. Zur Implementierung des Singletons gehören die statische Methode getInstance() sowie das statische Attribut $instance. Passend dazu ist der Konstruktor der Klasse als protected markiert; diese kann somit nicht direkt instanziiert werden. Um auf die einzige Instanz der Klasse zuzugreifen, muss die Methode getInstance() benutzt werden. Neben dem Konstruktor selbst gibt es noch die Methode init(), welche erweiterte Initialisierungen vornimmt.

Mit Hilfe der Methode run() wird die Applikation aus der Datei index.php heraus gestartet, denn diese Methode stößt den gesamten Programmablauf an und steuert ihn. Dies geschieht, indem sie unter anderem Signale, zu denen in den Attributen $mainSignals und $actionSignals die Slots gesammelt sind, sendet. Außerdem lauscht der Controller selbst an den Slots display und redirect mit Hilfe der entsprechend benannten Methoden und verarbeitet eintreffende Signale der Action-Controller.

Die magische Methode __get() stellt sicher, dass andere Komponenten nur lesend auf dafür freigegebene Attribute des Controllers zugreifen, diese jedoch nicht mit neuen Werten belegen können. Einen solchen Mechanismus kennen Sie bereits aus dem vorhergehenden Kapitel, da er innerhalb der eZ Components häufig verwendet wird (Stichwort Virtual Properties, Abschnitt 2.3.1, »Optionen-Klassen«).

3.3.2 Initialisierung

Die Datei index.php im Verzeichnis htdocs ist die einzige Programmdatei, die durch den Webserver erreichbar ist. Hier wird der Haupt-Controller zum ersten Mal angesprochen und die Methode run() aufgerufen. Der folgende Codeschnipsel muss also in der Datei index.php auftauchen:

$blog = gpBlogController::getInstance();
$blog->run();

Sobald dieser Aufruf erfolgt, wird die Klasse gpBlogController instanziiert, denn dies ist der allererste Aufruf von getInstance() im gesamten Programmablauf. Die Initialisierung erfolgt also direkt aus der Methode getInstance() heraus:

public static function getInstance()
{
    if ( self::$instance === null )
    {
        self::$instance = new gpBlogController();
        self::$instance->init();
    }
    return self::$instance;
}

Listing 3.2 Controller-Singleton

Es soll nur eine einzige Instanz des Controllers im gesamten Programm existieren. Daher wird innerhalb von getInstance() zunächst überprüft, ob dies bereits der Fall ist. Falls nicht, wird eine neue Instanz erzeugt und im entsprechenden Attribut abgelegt. Nach der Erzeugung des Objekts wird init() aufgerufen. Dieser zusätzliche Aufruf ist notwendig, da während der Initialisierung des Controllers Instanzen weiterer Klassen erzeugt werden, die ihrerseits Zugriff auf die Singleton-Instanz des Haupt-Controllers benötigen. Der eigentliche Konstruktor des Controllers muss also an diesem Punkt bereits abgeschlossen sein, um zu gewährleisten, dass $instance nicht mehr unbelegt ist. Andernfalls würde die Initialisierung in einer Endlosschleife enden, denn bei jedem Zugriff auf getInstance() während der Ausführung des Konstruktors würde sie erneut angestoßen. Nach der Ausführung des Konstruktors ist im Attribut $instance garantiert eine entsprechende Instanz vorhanden. Diese wird beim nächsten Aufruf von getInstance() zurückgegeben.

Innerhalb des Konstruktors werden lediglich die beiden benötigten Instanzen von ezcSignalCollection erzeugt, mit deren Hilfe alle benötigten Slots verwaltet werden:

protected function __construct()
{
    $this->actionSignals = new ezcSignalCollection();
    $this->mainSignals   = new ezcSignalCollection();
}

Listing 3.3 Controller-Singleton

Die Signale zu den im Attribut $actionSignals gespeicherten Slots werden vom Controller anhand der URL gesendet und von Action-Controllern empfangen und verarbeitet. $mainSignals hingegen enthält Slots, die nicht durch die URL angesprochen werden dürfen, sondern nur intern verwendet werden. Es wäre ungeschickt, wenn zum Beispiel der Slot zum Ansprechen der View-Komponente des GP-Blogs oder der zum Auslösen einer Fehlermeldung von außen benachrichtigt werden könnten.

Innerhalb der init()-Methode wird die eigentliche Initialisierung des Controllers vorgenommen:

protected function init()
{
    $classes = include dirname( __FILE__ ) .
        "/../autoload/blog_action_autoload.php";
    foreach ( $classes as $actionClass => $path )
    {
        call_user_func(
            array( $actionClass, "registerSlots" ),
            $this->mainSignals,
            $this->actionSignals
        );
    }
    $this->mainSignals->connect(
        "redirect",
        array( $this, "redirect" )
    );
    $this->mainSignals->connect(
        "display",
        array( $this, "display" )
    );
}

Listing 3.4 Initialisierung des Controllers

Zunächst muss bestimmt werden, welche Klassen als Action-Controller bereitstehen. Zu diesem Zweck werden sie in einer speziellen Autoload-Datei gehalten, die bereits vorher kurz erwähnt wurde: blog_action_autoload.php. Als kleinen Trick werten wir hier das in der Autoload-Datei enthaltene Array manuell aus und erhalten somit alle verfügbaren Aktionsklassen. Auf jeder Klasse wird die statische Methode registerSlots() aufgerufen, über die der Action-Controller die von ihm bereitgestellten Signale registriert. Da PHP den variablen Aufruf statischer Methoden nicht direkt unterstützt, wird die PHP-Funktion call_user_func() verwendet.

Zuletzt registriert die Methode init()alle Slots, die der Controller selbst zur Verfügung stellt. Die Registrierung geschieht mit Hilfe der Methode connect() auf der Instanz von ezcSignalCollection im Attribut $mainSignals, ganz im Gegensatz zu den meisten Action-Controllern, welche ihre Slots auf dem $actionSignals-Attribut registrieren. Sie erinnern sich, dass die Signale in $actionSignals später über die URL angesprochen werden, wohingegen Signale in $mainSignals nur für applikationsinterne Signale gedacht sind, die nicht von außen erreichbar sein dürfen. Der Slot mit dem Namen redirect wird mit der gleichnamigen Methode auf dem Controller-Objekt verbunden. Wird nun an irgendeiner Stelle in der Applikation das Signal redirect gesendet, führt dies zu einem Aufruf der Methode. Gleiches gilt für den Slot display. Der Sender des Signals muss lediglich wissen, welche Parameter der entsprechende Slot erwartet, nicht jedoch, welches Objekt sich um die Behandlung des Signals kümmert. Es ist also möglich, die Behandlung eines Slots beliebig innerhalb der Applikation zu verschieben und völlig anders zu lösen, ohne dass die sendenden Objekte dies bemerken. Voraussetzung ist natürlich, dass die Signatur der Slot-Methode nicht geändert wird.

Beim zweiten Parameter der Methode connect() handelt es sich um den speziellen PHP-Datentyp callback [http://php.net/callback ] , mit dessen Hilfe der Aufruf einer Funktion oder Methode beschrieben wird. Aus anderen Sprachen sind ähnliche Mechanismen unter dem Namen Delegation bekannt. An dieser Stelle im Code wird eine Methode auf einem konkreten Objekt referenziert. Es ist ebenfalls möglich, statische Methoden zu verwenden, wobei dann das erste Array-Element der Name der referenzierten Klasse ist. Auch die Verwendung von Funktionen alleine ist möglich, wobei Sie in diesem Fall kein Array benötigen, sondern nur den Namen der aufzurufenden Funktion als String übergeben müssen.

3.3.3 Signale verarbeiten

Die beiden im Controller registrierten Slots display und redirect werden mit Hilfe der folgenden Methoden verarbeitet:

public function redirect( ezcUrl $url )
{
    header( "Location: " . $url->buildUrl );
}

Listing 3.5 Weiterleitung durch den Controller

Der redirect-Slot erwartet als Parameter ein Objekt vom Typ ezcUrl, welches Sie in den folgenden Abschnitten genauer kennenlernen werden. An dieser Stelle wird aus dem Objekt lediglich die darin gekapselte URL als String extrahiert und ein Location-Header gesendet, der den Browser veranlasst, die neue URL mit der aktuellen zu ersetzen. Action-Controller haben so die Möglichkeit, auf eine andere Aktion weiterzuleiten.

public function display( $template, array $params )
{
    header( "Content-Type: text/html; charset=utf-8" );
    echo "Template $template would receive the following data:";
    echo "<br />";
    echo "<pre>";
    var_dump( $params );
    echo "</pre>";
}

Listing 3.6 Einfache Ausgabe im Controller

Der display-Slot hingegen erwartet zwei Parameter:

Im aktuellen Stadium verwendet das Galileo-Press-Blog noch keine Templates, weshalb die erhaltenen Daten zu Testzwecken einfach ausgegeben werden. In Kapitel 8, »Template«, werden Sie sehen, wie in dieser Methode der View-Teil des MVC-Patterns implementiert wird. Durch das Versenden eines Signals zum Auslösen der Ansicht, ist die View-Komponente der Applikation bereits gegenüber der Business-Logik und den Modellen abgegrenzt und kann autonom implementiert werden.

Beachten Sie an dieser Stelle, dass explizit ein Header gesendet wird, der den Inhaltstyp text/html und vor allem den Zeichensatz zur Anzeige mit utf-8 definiert. Alle Quellcode-Dateien des GP-Blogs sind im Unicode-Zeichensatz UTF-8 codiert, ebenso die Datenbank und deren Inhalte. Auch wenn auf Ihrem System in der Datei php.ini ein anderer Zeichensatz eingestellt ist, sollten mit diesem Header keine Darstellungsfehler im Browser auftreten. UTF-8 wird verwendet, da dieser Zeichensatz die Darstellung von Zeichen in allen Sprachen – auch asiatischer und arabischer Herkunft – zulässt.

3.3.4 Read-only-Attribute

Auf beide Slot-Sammlungen, die in den Attributen $mainSignals und $actionSignals gehalten werden, muss aus den Action-Controllern heraus zugegriffen werden. Allerdings soll nicht erlaubt sein, dass diese den Inhalt der Attribute ändern, weshalb der __get()-Interzeptor (siehe auch Abschnitt 2.3.1, »Optionen-Klassen«) verwendet wird, um den Zugriff zu regulieren. Die Implementierung von __get() gestaltet sich hier wie folgt:

public function __get( $propertyName )
{
    switch ( $propertyName )
    {
        case "mainSignals":
        case "actionSignals":
            return $this->$propertyName;
        default:
            throw new gpBlogPropertyNotFoundException(
               $propertyName
            );
    }
}

Listing 3.7 Ausschließlich lesender Zugriff auf die Signale

Der __get()-Methode wird als Parameter der Name des angefragten Attributs übergeben. Innerhalb der Methode überprüft ein switch-Statement, ob das Attribut im Objekt existiert und bestimmt, ob es zum Lesen von außerhalb freigegeben ist. Nur die Attribute $mainSignals und $actionSignals dürfen gelesen werden. Handelt es sich um eines dieser beiden Attribute, wird dessen Wert aus der Methode zurückgegeben, in allen anderen Fällen wird eine gpBlogNoSuchPropertyException geworfen.

Der Name dieser Exception lässt bereits darauf schließen, dass sie der ezcBasePropertyNotFoundException (siehe Abschnitt 2.3.2, »Exceptions«) ähnelt, in Wirklichkeit handelt es sich sogar um genau diese Exception, die lediglich einen neuen Namen bekommen hat. Der Sourcecode, den Sie unter exceptions/property_not_found.php finden, hat folgende Gestalt:

class gpBlogPropertyNotFoundException
    extends ezcBasePropertyNotFoundException
    implements gpBlogException
{
}

Listing 3.8 Definition der eigenen Property-not-found-Exception

Die ezcBasePropertyNotFoundException wird lediglich erweitert, ohne eine Änderung an den Attributen oder Methoden vorzunehmen. Allerdings wird ein komplett leeres Interface namens gpBlogException (interfaces/exception.php) implementiert. Was auf den ersten Blick nutzlos aussieht, erlaubt Ihnen eine wichtige Eigenschaft von Exceptions auszunutzen: Verschiedene Exceptions können unterschiedlich behandelt werden. Würde in __get() einfach eine ezcBasePropertyNotFoundException geworfen, könnte beim Fangen der Exception nicht unterschieden werden, ob diese aus den eZ Components oder aus GP-Blog-Code resultiert. Durch die Implementierung des neuen Interfaces ist es möglich, schon im catch-Block verschiedene Behandlungen vorzunehmen.

3.3.5 Laufen lassen

Mit Hilfe der run()-Methode wird der Haupt-Controller in Gang gesetzt. In dieser Methode wird die URL des aktuellen Requests verarbeitet und die daraus resultierende Aktion als Signal gesendet:

public function run()
{
    $urlConfig = new ezcUrlConfiguration();
    $urlConfig->basedir = BASEDIR;
    $urlConfig->script  = SCRIPT;
    $urlConfig->addOrderedParameter( "action" );
    $url = new ezcUrl(
         "http://" . $_SERVER["SERVER_NAME"] .
             $_SERVER["REQUEST_URI"]
    );
    $url->applyConfiguration( $urlConfig );
         $action = ( $url->getParam( "action" ) !== null )
             ? $url->getParam( "action" )
             : DEFAULT_ACTION;
    if ( !$this->actionSignals->isConnected( $action ) )
    {
         $this->mainSignals->emit(
             "error",
             "Action does not exist: '" .
                  htmlspecialchars( $action ) .
                  "'"
         );
         return;
    }

    try
    {
        $this->actionSignals->emit(
            $action,
            $url,
            $urlConfig
        );
    }
    catch ( gpBlogException $e )
    {
        $this->mainSignals->emit(
            "error",
            "An error occured in the blog application."
        );
    }
    catch ( ezcBaseException $e )
    {
        $this->mainSignals->emit(
            "error",
            "An error occured in eZ Components."
        );
    }
    catch ( Exception $e )
    {
        $this->mainSignals->emit(
            "error",
            "An unknown error occured."
        );
    }
}

Listing 3.9 Hauptmethode im Controller

Zunächst erzeugt die Methode eine neue Instanz von ezcUrlConfiguration. Mit Hilfe dieses Objekts können Sie das Verhalten eines ezcUrl-Objekts konfigurieren. Zum Beispiel dafür, welches Trennzeichen für Parameter verwendet wird und welche Parameter eine URL in welcher Form enthalten kann.

Die Url-Komponente unterstützt zwei Arten von Parametern: ungeordnete Parameter und geordnete Parameter. Bei ungeordneten Parametern ist die Reihenfolge, in der sie in der URL vorkommen, irrelevant. Aus diesem Grund muss für jeden Parameterwert ebenfalls der Parametername in der URL angegeben werden, sodass eine solche URL standardmäßig ungefähr so aussieht:

http://gpblog/(action)/my_action/(id)/23

Zum Ende dieses Kapitels finden Sie einige weitere Informationen zu ungeordneten Parametern; für das GP-Blog wird allerdings der Mechanismus geordneter Parameter verwendet. Da hierbei die Reihenfolge der Parameter in der URL signifikant ist, muss der Name eines Parameters nicht mit übergeben werden, und die URL fällt wesentlich kürzer aus:

http://gpblog/my_action/23

Das Konfigurationsobjekt muss zunächst wissen, wie das Basisverzeichnis und der Name des aufgerufenen Skripts heißen, um die URL entsprechend zerlegen und später neue URLs generieren zu können. Um eine einfache Anpassung an Ihre Testumgebung zu ermöglichen, werden hierfür zunächst zwei Konstanten in der Datei index.php definiert:

define( "BASEDIR", "" );
define( "SCRIPT",  "index.php" );

In Kapitel 5, »Konfiguration«, werden diese Konstanten in echte Konfigurationsdateien verschoben, welche mit Hilfe der Configuration-Komponente verarbeitet werden. Der Aufruf des Controllers würde also mit den aktuellen Einstellungen über eine URL wie http://gpblog/index.php erfolgen, wobei die Datei index.php durch das eingerichtete Rewriting, welches Sie in Abschnitt 1.3.4, »Rewriting einrichten«, kennengelernt haben, weggelassen werden kann. Der Hostname wird von der Applikation automatisch bestimmt.

Der erste Parameter bei jeder URL des GP-Blogs ist der Name der auszuführenden Aktion. Damit das Objekt ezcUrl diesen Parameter erkennt, müssen Sie ihn dem Konfigurationsobjekt mit Hilfe der Methode addOrderedParameter() mitteilen. Ein geordneter sowie ein ungeordneter Parameter erhält einen Namen, mit dessen Hilfe Sie später auf seinen Wert zugreifen können. Für den Augenblick ist die Aktion der einzige benötigte Parameter. Action-Controller können der URL später für eigene Zwecke weitere Parameter hinzufügen. Die Vorbereitung der Konfiguration für das ezcUrl-Objekt ist somit abgeschlossen und ein neues Objekt der Klasse wird erzeugt, auf das die erzeugte Konfiguration angewendet wird. Das ezcUrl-Objekt verarbeitet beim Aufruf von applyConfiguration() die gegebene URL und stellt Ihnen die Werte der vorher konfigurierten Parameter zur Verfügung.

Schließlich wird getestet, ob das in der URL angegebene Signal auch wirklich existiert. Der Name der entsprechenden Aktion wird aus dem soeben konfigurierten ezcUrl-Objekt mit Hilfe der Methode getParam() bezogen. Wird innerhalb der URL keine Aktion übergeben, was zum Beispiel beim einfachen Aufruf der Basis-URL der Fall ist, so wird eine Standardaktion aufgerufen. Diese Standardaktion wird wiederum in einer Konstanten gehalten, welche ebenfalls in der Datei index.php definiert wird:

define( "DEFAULT_ACTION", "list_entries" );

Sie können diese Aktion beliebig auf eine bekannte (oder testweise auch unbekannte) Aktion ändern, um eine andere Startseite für das GP-Blog festzulegen.

Gibt die Methode isConnected() den Wert false zurück, so hat kein Action-Controller das entsprechende Signal registriert und es wird ein Fehlersignal gesendet. Der letzte Teil der run()-Methode besteht daraus, das Signal zum Ansprechen der gewünschten Aktion zu senden. Für den Fall, dass innerhalb der Aktion eine Exception auftritt, ist der Signalaufruf in einem try-catch-Block gekapselt. Für verschiedene Exceptions werden verschiedene Behandlungen vorbereitet: Exceptions, die im GP-Blog auftreten, und eZ Components-Exceptions werden speziell, alle weiteren Exceptions gesammelt behandelt.

Signale senden Sie über die Methode emit() auf dem entsprechenden ezcSignalCollection-Objekt. Der erste Parameter zu emit() ist der Name des zu sendenden Signals. Alle weiteren Parameter der emit()-Methode werden an den oder die behandelnden Slot-Methoden weitergegeben, womit sich zusätzliche Informationen transferieren lassen. Ein Aktionsaufruf bekommt sowohl die aktuelle URL als auch die verwendete Konfiguration übergeben, somit wird es dem Aktions-Slot ermöglicht, eigene Parameter aus der URL zu extrahieren, ohne zu wissen, welche Parameter bereits vom Controller registriert und ausgewertet wurden. Es wäre also möglich, später noch weitere Parameter durch den Controller hinzufügen zu lassen, ohne die Aktionen anpassen zu müssen.

Innerhalb der einzelnen catch-Blöcke werden wiederum Signale versendet. Allerdings haben Sie den hier verwendeten error-Slot noch nicht kennengelernt, da dieser nicht vom Haupt-Controller registriert wurde. Aber gerade das ist ja der Sinn hinter SignalSlot: Es ist nicht bekannt, wo ein Signal verarbeitet wird, es wird lediglich gesendet. Ob und wie es verarbeitet wird, braucht Sie in diesem Moment nicht zu kümmern. Die SignalSlot-Komponente erzeugt standardmäßig noch nicht einmal einen Fehler, falls zu einem gesendeten Signal nirgendwo ein Slot registriert ist, der es verarbeitet. Der error-Slot, soviel kann man bereits erahnen, erwartet eine frei definierbare Fehlermeldung. In Kapitel 4, »Fehlerbehandlung und Debugging«, wird die Fehlerbehandlung genauer betrachtet.

Ihr Kommentar