5.4 Direkter Zugriff

In den Beispielen des letzten Abschnitts wurde der ezcConfigurationManager zum Zugriff auf die Einstellungen verwendet. Dies macht in Applikationen gewöhnlich auch Sinn, da die Konfigurationsdateien syntaktisch korrekt sind und man lediglich einen zentralen Zugriffsmechanismus auf eine Menge von Konfigurationsdateien benötigt.

Dem Konfigurationsmanager wurde beim Instanziieren der Name einer Reader-Klasse übergeben, die er verwenden soll, um auf Konfigurationsdateien zuzugreifen. Diese Reader-Klassen, die, wie der Name schon impliziert, verwendet werden, um die Konfigurationsdateien zu lesen, können auch direkt instanziiert und verwendet werden. Im Unterschied zum ezcConfigurationManager erlaubt die direkte Verwendung von Reader-Klassen Ihnen zum Beispiel die Validierung des unterstützten Formats.

$reader = new ezcConfigurationIniReader( 'site.ini' );
$result = $reader->validate();
foreach ( $result->getResultList() as $item )
{
    printf( "In '%s' on line '%d', position: ''%d': %s\n",
        $item->file, $item->line, $item->column, $item->details
    );
}
$cfg = $reader->getConfig();
echo $cfg->getSetting( 'general', 'title' );

Listing 5.6 Überprüfung auf Validität

Dieser Beispielcode validiert die Konfigurationsdatei site.ini und zeigt eventuelle Fehler wie Leerzeichen in einem Konfigurationsschlüssel an. Dabei wird in der ersten Zeile der ezcConfigurationIniReader mit dem Pfad der zu ladenden Datei instanziiert.

Anschließend wird die Methode validate() des ezcConfigurationIniReaders aufgerufen, welche die Konfigurationsdatei auf syntaktische Fehler hin überprüft. Die Methode gibt ein Objekt der Klasse ezcConfigurationValidationResult zurück, das Informationen über die Validierung enthält. Falls keine Fehler beim Validieren der Datei auftreten, enthält das Attribut $isValid den Wert true zurück. Andernfalls können die aufgetretenen Fehler über die Methode getResultList() abgefragt werden, die einen Array von ezcConfigurationValidationItem-Instanzen zurückgibt. Da die Fehlerliste leer ist, wenn kein Fehler auftrat, verzichtet das Beispiel auf die Prüfung der Eigenschaft $isValid.

Wie in der foreach-Schleife im Beispiel gezeigt, enthält jedes ezcConfigurationValidationItem sowohl Informationen zur Postion des Fehlers in der Konfigurationsdatei als auch eine für den Anwender lesbare Fehlermeldung in der Eigenschaft $details.

Nachdem sichergestellt ist, dass die Konfigurationsdatei validiert, kann auf die Werte zugegriffen werden. Dazu gibt $reader->getConfig() ein ezcConfiguration-Objekt zurück, aus dem Sie die Einstellungen direkt per getSetting() beziehen können. getSetting() akzeptiert, anders als die gleichlautende Methode auf dem ezcConfigurationManager, natürlich nur zwei Parameter, da die Angabe einer Datei in diesem Fall überflüssig ist.

5.4.1 Änderungen speichern

Neben den Reader-Klassen stellt die Configuration-Komponente auch Writer-Klassen für die vorhandenen Backends bereit. Zusammengenommen lässt sich damit einfach ein Frontend zur Verwaltung der Konfigurationsdateien schreiben, indem bestehende Konfigurationsdateien geladen, verifiziert und anschließend wieder gespeichert werden können.

$writer = new ezcConfigurationIniWriter();
$writer->init( 'path/', 'site', $cfg );
$writer->save();

Listing 5.7 Änderungen in Konfigurationsdatei speichern

Die Writer-Klasse lässt sich genauso instanziieren, wie es auch für die reader-Klasse angesprochen wurde, und akzeptiert als dritten zusätzlichen Parameter ein ezcConfiguration-Objekt, das gespeichert werden soll. Durch einen Aufruf von save() wird die Konfiguration im ini-Format in die spezifizierte Datei geschrieben, wobei Kommentare und Leerzeilen nicht verlorengehen.

5.4.2 Schnellerer Zugriff durch PHP-Arrays

Wie zu Beginn des Kapitels erwähnt, erlaubt es die Configuration-Komponente, mehrere Backends und Konfigurationsdateien in verschiedenen Formaten zu speichern. Sie können sehr einfach eigene Backend-Klassen entwickeln und ezcConfiguration damit um weitere Konfigurationsformate erweitern. Im Paket befinden sich neben dem ezcConfigurationIniReader und dem ezcConfigurationIniWriter auch Klassen, um Konfigurationen als mehrdimensionales PHP-Array direkt in Dateien zu speichern und sich so die Vorteile des schnellen PHP-Interpreters und optionaler Op-Code-Caches zunutze zu machen. Die API, um auf solche Konfigurationsdateien zuzugreifen, ist die gleiche wie für ini-Dateien. ezcConfiguration kann natürlich auch Konvertierungen zwischen den Formaten durchführen, da alle Backends von den abstrakten Klassen ezcConfigurationReader und ezcConfigurationWriter ableiten und intern die gleichen Datenstrukturen verwenden.

$reader = new ezcConfigurationIniReader( 'actions.ini' );
$cfg = $reader->getConfig();

$writer = new ezcConfigurationArrayWriter();
$writer->init( 'cached/', 'actions', $cfg );
$writer->save();

Listing 5.8 Cachen der Konfiguration in PHP-Dateien

In den ersten beiden Zeilen wird eine ini-Datei geladen und die darin enthaltenen Konfigurationswerte werden ausgelesen. In den darauf folgenden drei Zeilen, die bis auf die instanziierte Writer-Klasse äquivalent zum vorhergehenden Beispiel des Schreibens einer ini-Datei sind, werden die Informationen aus der ini-Datei in einer PHP-Datei gespeichert. Diese generierte PHP-Datei enthält ein mehrdimensionales Array mit den Konfigurationswerten, das aus der Datei zurückgegeben wird:

return array (
  'settings' =>
  array (
    'classes' =>
    array (
      'action' =>
      array (
        0 => 'gpBlogActionEntryDisplay',
        1 => 'gpBlogActionEntryDelete',
        2 => 'gpBlogActionEntryEdit',
        3 => 'gpBlogActionError',
      ),
    ),
  ),
  'comments' =>
  array (
    'classes' =>
    array (
      '#' => ' Classes containing actions to register for
           dispatcher',
    ),
  ),
);

Listing 5.9 Generierter PHP-Code

Wie das Beispiel zeigt, gehen mit dem Array-Writer auch die Kommentare zu einzelnen Konfigurationsschlüsseln nicht verloren, sondern bleiben wie gewohnt erhalten.

5.4.3 Lazy-Initialization

Auch die Configuration-Komponente unterstützt das Konzept der Lazy-Initialization, die Initialisierung und Konfiguration beim ersten wirklichen Gebrauch (siehe auch Abschnitt 2.3.4, »Lazy-Initialization«).

class customLazyConfigurationConfiguration
{
    public static function configureObject( $cfg )
    {
        $cfg->init( 'ezcConfigurationIniReader',
            dirname( __FILE__ ) . '/../config' );
    }
}

Listing 5.10 Lazy-Initialization der Configuration-Komponente

Die Klasse customLazyConfigurationConfiguration übernimmt die Konfiguration von ezcConfigurationManager, wenn dessen Instanz zum ersten Mal angefragt wird. In diesem Moment wird die Methode configureObject() aus der Lazy-Initialization-Klasse mit der Instanz des Managers aufgerufen. In Zeile fünf wird entsprechend das Basisverzeichnis der Konfigurationsdateien gesetzt.

ezcBaseInit::setCallback(
    'ezcInitConfigurationManager',
    'customLazyConfigurationConfiguration'
);

Listing 5.11 Callback definieren

Mit der Methode ezcBaseInit::setCallback() wird mit dem Schlüsselwort, das die Configuration-Komponente identifiziert (ezcInitConfigurationManager), diejenige Klasse assoziiert, die der Lazy-Initialization-Mechanismus zur Konfiguration verwenden soll.

// Classes loaded and configured on first request
$author = ezcConfigurationManager::getInstance()
    ->getSetting( 'site', 'general', 'name' );
echo "Autor des Blogs: '{$author}'.\n";

Listing 5.12 Lazy-Initialization nutzen

Wenn nun im GP-Blog das erste Mal auf den Konfigurationsmanager zugegriffen wird, um Werte aus einer Konfigurationsdatei zu lesen, wird das neu erzeugte Manager-Objekt über die von Ihnen definierte Klasse konfiguriert. Das erwartete Ergebnis, die Ausgabe des Blog-Besitzer-Namens, wird damit erzielt. Sollte innerhalb eines Requests kein Zugriff auf Werte aus den Konfigurationsdateien benötigt werden, wird die Komponente entsprechend auch nicht initialisiert und konfiguriert.

Ihr Kommentar