Quicknavi |
|
Konfiguration
1. Einführung
Um wiederverwendbare Anwendungen implementieren zu können wird an ein einigen Stellen das
Hilfsmittel Konfiguration eingesetzt. Um auch hier eine generische Schnittstelle für das Laden
und das Auslesen für Konfigurationen im Windows-INI-Stil zur Verfügung zu haben wurde
der configurationManager in das Framework integriert. Eine zusätzliche Wrapper-Methode
in der Klasse coreObject bietet in jeder von coreObject erbenden Klasse die
Möglichkeit die Methode __getConfiguration() aufzurufen und mit dieser eine
Konfiguration zu laden. Da der configurationManager im Singleton-Modus initialisiert wird,
kann ohne Performance-Einbußen beliebig oft auf diesen zugegriffen werden - die Konfigurationen
werden intern gecached. Wie bereits erwähnt sind die Konfigurations-Dateien wie INI-Dateien
aufgebaut, haben somit Sektionen- und Werte-Bereiche. Eine typische INI-Datei zeigt folgendes
Code-Beispiel:
[Section1]
Param1 = "Value1"
Param2 = "Value2"
...
[Section2]
Param1 = "Value1"
Param2 = "Value2"
...
Die in der Konfigurationsdatei enthaltenen Sektionen und Schlüssel-Werte-Paare sind frei
vom Entwickler wählbar. Lediglich die Struktur der bereits bestehenden Komponenten sind vorgegeben
und die verwendeten Sektionen und Konfigurationsschlüssel stehen fest.
2. Benennung von Pfaden und Dateien
Bei der Bezeichnung der Dateien und Pfade sind einige Rahmenbedingungen zu beachten. Um Anwendungen
oder Module (=Software-Teile, die in mehreren Applikationen eingesetzt werden können) in
verschiedenen Applikationen (=Webseiten oder Anwendungen) wiederverwendbar zu machen ist eine
Konfigurationsdatei aus viel unterschiedlichen Teilen zusammengesetzt:
-
Namespace:
Der Namespace ist der Pfad zum Basis-Ordner, in der alle Konfiguration einer Core-Klasse oder
eines Moduls residieren. Der Namespace ist oft übereinstimmend mit dem Namespace des Moduls,
in dem die Konfiguration benötigt wird. Grundsätzlich sind alle Konfigurationen unter
dem Ordner config abgelegt um Konfigurationen vom Code zu separieren.
-
Context:
Um Wiederverwendbarkeit zu realisieren, wird der Pfad zur Konfigurationsdatei mit dem Context
der Applikation erweitert. So kann ein Modul A in der Webseite B und C ohne Änderung
des Codes und nur durch Modifikation der jeweiligen Konfiguration eingesetzt werden.
-
Environment:
Das dritte Unterscheidungsmerkmal ist das Umfeld, in dem die Applikation oder das Modul eingesetzt
wird. Es ist mit dieser Unterscheidung möglich jeweils eine Konfigurationsdatei für
ein Umfeld (Test-Server, Produktions-Server) anzulegen und nur durch setzen der Umgebungsvariable
wird jeweils die "richtige" Konfiguration gezogen. Die Umgebungsvariable wird dabei in der
Registry verwaltet und kann - falls nötig - in der Bootstrap-Datei angepasst
werden (siehe hierzu
Grundlagen, Kapitel 3.3. Basis-Konfiguration).
-
Name:
Der Name der Konfigurationsdatei sollte den Inhalt möglichst treffend beschreiben. Dieser
wird dann um das Präfix {ENVIRONMENT} und dem Suffix .ini erweitert.
Möchte der Entwickler eine Konfigurationsdatei mit dem Namen myconfig
verwenden und die Umgebungsvariable wurde nicht verändert, wird die Datei unter dem Namen
DEFAULT_myconfig.ini erwartet.
Der Context einer Applikation kann durch explizites Setzen desselben bei Einsatz des FrontControllers
und durch explizites und implizites Setzen bei Einsatz des PageControllers beeinflusst werden.
2.1. Context beim FrontController
Dem FrontController wird durch explizites Aufrufen der set()-Methode die interne Variable
"Context" mit dem für die Applikation geltenden "Context" versorgt. Der Context wird intern
beim Erstellen weiterer Objekte im DOM der Präsentations-Schicht oder von Service-Objekten der
Business- und Daten-Schicht weitergegeben. Der Aufruf gestaltet sich wie folgt:
$fC = &Singleton::getInstance('Frontcontroller');
$fC->set('Context','my::apps::context');
$fC->start('sites::mysite::pres::templates','mywebsite');
2.2. Context beim PageController
Beim Einsatz des PageControllers wird der Context implizit mit dem in der Methode loadDesign()
angegebenen Namespace des zu ladenden Templates gefüllt, wenn vorher kein explizites Setzen des
Contextes veranlasst wurde:
$Page = new Page('mywebsite');
$Page->loadDesign('sites::mysite','pres/templates/mywebsite');
echo $Page->transform();
Der Context der Applikation ist nun "sites::mysite". Wird der Context - wie im folgenden Beispiel -
zuvor gesetzt, so trägt er den Wert "sites::myapp":
$Page = new Page('mywebsite');
$Page->set('Context','sites::myapp');
$Page->loadDesign('sites::mysite::pres::templates','mywebsite');
echo $Page->transform();
Führt man das eben genannte Beispiel weiter, so würde der configurationManager bei
Aufruf des Befehls
$Config = &$this->__getConfiguration('modules::mymodule','mymoduleconfig');
und einer index.php mit dem Inhalt
$Page = new Page('mywebsite');
$Page->set('Context','sites::myapp');
$Page->loadDesign('sites::mysite::pres::templates','mywebsite');
echo $Page->transform();
eine Konfigurations-Datei im Ordner
/apps/config/modules/mymodule/sites/myapp/
mit dem Dateinamen
DEFAULT_mymoduleconfig.ini
erwarten. Ist die Datei falsch benannt oder passen Namespace oder Context nicht korrekt, wird eine
Fehlermeldung ausgegeben, die den Entwickler darauf hinweist, welcher Pfad und welche Datei erwartet
wird.
3. Service-Objekte
Da Konfigurationen oft in der Business- und Daten-Schicht Verwendung finden, muss diesen beiden
Schichten ebenso der Context der Applikation bekannt sein. Beim Einsatz des FrontControllers wird
jeder Action der aktuelle Context mitgegeben und diese kann Service-Objekte der Business-Schicht mit
diesem Aufrufen. In PageController-Anwendungen wird der Context beim Aufbau des DOM-Baumes jedem
neu erstellten Objekt mitgegeben. Möchte nun ein DocumentController eine Business-Komponente
erzeugen, oder eine Referenz auf diese holen, so müssen immer die Methoden
__getServiceObject() oder __getAndInitServiceObject verwendet werden. Die beiden
Funktionen stellen sicher, dass jedes Service-Objekt den richtigen Context erhält. Implementierungs-
Details und Dokumentation der Parameter finden sich in der API-Dokumentation. In der Regel reicht es
aus eine Service-Schicht mit dem PHP-Code
$GuestbookID = '1';
$oGuestbookManager = &$this->__getServiceObject('modules::guestbook::biz','guestbookManager');
$Guestbook = $oGuestbookManager->loadGuestbook($GuestbookID);
aufzurufen und anschließend zu verwenden. Um eine initialisierte Service-Komponente zu erhalten
kann
$GuestbookID = '1';
$oGuestbookManager = &$this->__getAndInitServiceObject(
'modules::guestbook::biz',
'guestbookManager',
$GuestbookID
);
$Guestbook = $oGuestbookManager->loadGuestbook();
verwendet werden.
4. Konfigurationen auslesen
Um die Werte einer Konfiguration auszulesen stehen mehrere Methoden des zentrale Konfigurations-Objekts
zur Verfügung. Diese sind getConfiguration(), getSection() und getValue().
Mit diesen können entweder die komplette Konfiguration, eine einzelne Sektion oder der Wert
einer Sektion zurückgegeben werden.
Beispiel:
Wurde die verwendete Konfigurations-Datei mit den Werten
[Section1]
Key1 = "Value1"
Key2 = "Value2"
Key3 = "Value3"
[Section2]
Key1 = "Value1"
Key2 = "Value2"
Key3 = "Value3"
gefüllt, so kann mit dem PHP-Code
$Config = &$this->__getConfiguration('modules::mymodule','mymoduleconfig');
echo printObject($Config->getConfiguration());
das komplette Konfigurations-Array
Array
(
[Section1] => Array
(
[Key1] => Value1
[Key2] => Value2
[Key3] => Value3
)
[Section2] => Array
(
[Key1] => Value1
[Key2] => Value2
[Key3] => Value3
)
)
ausgegeben werden, mit
$Config = &$this->__getConfiguration('modules::mymodule','mymoduleconfig');
echo printObject($Config->getSection('Section2'));
das Array
Array
(
[Section2] => Array
(
[Key1] => Value1
[Key2] => Value2
[Key3] => Value3
)
)
und mit
$Config = &$this->__getConfiguration('modules::mymodule','mymoduleconfig');
echo $Config->getValue('Section1','Key2');
der Wert
Value2
. Die Funktion printObject() wurde in den Code-Beispielen lediglich zur "Verschönerung"
der Ausgabe eingesetzt und ist in der Realität nicht erforderlich.
5. Anwendungsfall Mehrsprachigkeit
Um mehrsprachige Anwendungen einfach implementieren zu können wird in jedem GUI-Objekt des
Frameworks die Sprache vorgehalten. So ist die aktuell verwendete Sprache immer bekannt und Teilbäume
können auch mit unterschiedlichen Sprachen ausgestattet werden. Die Realisierung der Mehrsprachigkeit
in Anwendung wird durch die Tags <html:getstring /> und
<template:getstring /> unterstützt. Diese lesen aus einer in den Tags
spezifizierten Konfigurations-Datei die sprachabhängigen Inhalte aus und stellen diese in
Template-Dateien oder HTML-Templates dar.
Für die Realisierung sind zwei Schritte notwenig:
5.1. Erstellen der Konfigurations-Datei
Wie in Kapitel 2 beschrieben muss beim Anlegen der Konfigurations-Datei darauf geachtet werden, in
welchem Context die Applikation ausgeführt wird. Sinnvollerweise erstellt der
Entwickler zur Ablage der sprachabhängigen Daten einen eigenen Ordner unter dem Namespace der
aktuellen Applikation. Unter der Annahme, dass die aktuell besprochene Applikation ein Modul im
Namespace
/apps/modules/mymodule/
ist und der aktuelle Context der Applikation sites::myapp lautet, muss die
Konfigurations-Datei für die sprachabhängigen Inhalte im Ordner
/apps/modules/mymodule/sites/myapp/
liegen. Um zu kennzeichnen, dass die Datei eine Sprachdatei ist, wird dieser der Name
DEFAULT_mymodule_lang.ini
gegeben. Der Inhalt der Datei kann vom Entwickler oder Template-Bauer selbst bestimmt werden. Lediglich
die Sektionen sind mit den ISO-Ländercodes zu benennen. Siehe hierzu
http://de.wikipedia.org/../ISO-L%C3%A4ndercode
bzw.
http://www.iso.org/../list-en1.html
. Die Konfigurationsdatei kann dann folgende Struktur für ein Kontaktformular besitzen:
[de]
Form.Name = "Ihr Name"
Form.EMail = "Ihre E-Mail-Adresse"
Form.Subject = "Betreff"
..
[en]
Form.Name = "Your name"
Form.EMail = "Your email adress"
Form.Subject = "Subject"
..
5.2. Darstellen der sprachabhängigen Texte
Zur Darstellung von sprachabhängigen Texten sind zwei Möglchkeiten im Framework vorhanden.
Einerseits können in Template-Dateien und HTML-Templates die Tags <html:getstring />
und <template:getstring /> genutzt werden, andererseits kann auch mit dem
configurationManager bzw. mit der Methode __getConfiguration() auf die Datei
zugegriffen und Begriffe - beispielsweise für die Beschriftung von Buttons - ausgelesen werden.
Zuerst sei die Einbindung der oben beschriebenen Konfigurationsdatei in ein HTML-Template erläutert:
Ein Template der Form
<html:template name="MyTemplate">
[..]
Ihr Name: <template:placeholder name="Name" />
<br />
Ihre E-Mail-Adresse: <template:placeholder name="EMail" />
<br />
[..]
</html:template>
muss, um den Wert des Schlüsselwortes "Form.Name" statt des statischen Textes "Ihr Name"
darstellen zu können folgendermaßen erweitert werden:
<html:template name="MyTemplate">
[..]
<template:getstring namespace="modules::mymodule" config="mymodule_lang" entry="Form.Name" />:
<template:placeholder name="Name" />
<br />
<template:getstring namespace="modules::mymodule" config="mymodule_lang" entry="Form.EMail" />:
<template:placeholder name="EMail" />
<br />
[..]
</html:template>
Werden innerhalb eines Controllers sprachabhängige Werte zur Beschriftung oder beispielsweise
zum Versand einer E-Mail benötigt, können diese durch
$Config = &$this->__getConfiguration('modules::mymodule','mymodule_lang');
echo '<br />Form.Name: '.$Config->getValue($this->__Language,'Form.Name');
echo '<br />Form.EMail: '.$Config->getValue($this->__Language,'Form.EMail');
echo '<br />Form.Subject: '.$Config->getValue($this->__Language,'Form.Subject');
ausgelesen und verarbeitet werden. Die "echo"-Befehle wurden nur zu Verdeutlichung des Zugriffs notiert.
In Realität würde der Inhalt eines "<div />"-Tags im Template
<html:template name="MyTemplate">
<div class="FormHeader">
<template:placeholder name="FormHeader" />
</div>
</html:template>
mit dem Code
// Konfiguration auslesen
$Config = &$this->__getConfiguration('modules::mymodule','mymodule_lang');
// Referenz auf Template holen
$Template__MyTemplate = &$this->__getTemplate('MyTemplate');
// Platzhalter "FormHeader" setzen
$Template__MyTemplate->setPlaceHolder('FormHeader',$Config->getValue($this->__Language,'Form.Name'));
gefüllt werden. Ein gutes Beispiel bieten hier die Template- und Controller-Dateien des Moduls
Gästebuch.
Kommentare
Möchten Sie den Artikel eine Anmerkung hinzufügen, oder haben Sie ergänzende Hinweise? Dann können Sie diese hier einfügen. Die bereits verfassten Anmerkungen und Kommentare finden Sie in der untenstehenden Liste.
Für diesen Artikel liegen aktuell keine Kommentare vor.
|
