view release on metacpan or  search on metacpan

Intro.txt  view on Meta::CPAN

Die Zugehörigkeit eines Werkzeugs zu einem bestimmten
Werkzeugkasten (im folgenden "scope" genannt) kann dabei z.B.
durch eine "package"-Deklaration am Anfang des Skripts automatisch
gesteuert werden. Ein expliziter Aufruf mit der Übergabe des
gewünschten "scope" als Parameter ist natürlich auch realisierbar.

Zum anderen ist es möglich, sensible personenbezogene Daten in
eigene Dateien auszulagern, die durch Mittel des Betriebssystems
so geschützt werden können, dass sie nur vom jeweiligen Benutzer
gelesen und beschrieben werden können.

Diese müssen stets am Ende der Kette von einzulesenden
Konfigurationsdateien stehen. Dies hängt damit zusammen, dass es
möglich sein muss, die wesentlichen Konfigurationsinformationen
auch eines vom Aufrufer des Tools verschiedenen Benutzers
einzulesen (wichtig z.B. für den Betreuer der Tools, wenn er
Fehler in der Konfiguration eines Benutzers aufspüren soll und
sich diese daher auflisten lassen können muss, oder zur Ausführung
von Tools unter der Kennung eines "Projekt-Users"). Gleichzeitig
dürfen aber die Dateien mit den sensiblen Daten für andere
Benutzer nicht lesbar sein – ein Versuch sie trotzdem zu lesen
führt zu einem Fehler des Betriebssystems. Das Modul "Conf.pm"
geht nun so vor, dass es bei den speziellen "privaten"
Konfigurationsdateien diesen Fehler einfach ignoriert. Da das aber
dazu führt, dass die Angabe, welche Konfigurationsdatei als
nächstes eingelesen werden soll, nicht ausgewertet werden kann,
die Kette der Konfigurationsdateien an dieser Stelle also
abbricht, muss die "private" Konfigurationsdatei stets die letzte
Datei der Kette sein. Damit das Modul "Conf.pm" einen Lesefehler
ignoriert, muss der Name der entsprechenden speziellen
Konfigurationsdatei mit "PRIVAT.ini" oder "PRIVATE.ini" aufhören.

Ein weiteres Feature des "Conf.pm"-Moduls, das bisher noch
gänzlich unerwähnt geblieben ist, ist die Möglichkeit, innerhalb
der Definition einer Konfigurationskonstanten auf andere
Konfigurationskonstanten zuzugreifen (was auch als
"String-Interpolation" bezeichnet wird), und zwar völlig
unabhängig davon, ob die referenzierte Konfigurationskonstante in
derselben Datei definiert ist oder in einer anderen Datei, und
unabhängig davon, ob es sich um eine Konfigurationsdatei handelt,
die vor oder nach der aktuellen Konfigurationsdatei eingelesen
wird.

Dies wird dadurch ermöglicht, dass zuerst alle
Konfigurationsdateien eingelesen werden, bevor irgendwelche
Definitionen von Konfigurationskonstanten ausgewertet werden (mit
Ausnahme der Verweise auf die jeweils nächste einzulesende
Konfigurationsdatei in der Kette). Tatsächlich ist es sogar so,
dass jede Konfigurationskonstante erst dann ausgewertet (und ab
diesem Zeitpunkt in einem Cache gepuffert) wird, wenn sie
tatsächlich angefordert wird (dies wird als "Lazy Evaluation"
bezeichnet), d.h. Konfigurationskonstanten, die vom Programm nicht
benötigt werden, müssen auch nicht ausgewertet werden, was zu
einer deutlichen Performance-Steigerung führt.

Diese String-Interpolation benutzt dabei eine Syntax, die stark an
Shell- und Perl-Programme angelehnt ist (während der Aufbau der
Dateien selbst von Windows inspiriert ist):

    [DEFAULT]
    # $[SPECIAL]{OS} enthält den Namen des aktuellen Betriebssystems:
    Home-Dir     = $[$[SPECIAL]{OS}]{Home-Dir}
    Group-Dir    = $[$[SPECIAL]{OS}]{Group-Dir}
    Group-User   = $[$[SPECIAL]{OS}]{Group-User}
    TEMPDIRPATH  = $[$[SPECIAL]{OS}]{TEMPDIRPATH}
    LOGFILEPATH  = ${Group-Dir}/Tools/Logfiles
    CONFIGPATH   = ${Group-Dir}/Tools/Config
    GLOBALCONF   = ${CONFIGPATH}/Global/DEFAULT.ini

    [MSWin32]
    Home-Dir     = U:
    Group-Dir    = G:
    Group-User   = Administrator
    TEMPDIRPATH  = C:/Temp

    [freebsd]
    Base-Dir     = /u
    Home-Dir     = $[UNIX]{Home-Dir}
    Group-Dir    = $[UNIX]{Group-Dir}
    Group-User   = projadmin
    TEMPDIRPATH  = /tmp

    [UNIX]
    # Die folgende Zeile holt das Home-Dir des aktuellen Benutzers aus /etc/passwd:
    Home-Dir     = $[SPECIAL]{HOME}
    Group-Dir    = $[$[SPECIAL]{OS}]{Base-Dir}/$[$[SPECIAL]{OS}]{Group-User}

    [Manager]
    GROUPCONF    = $[DEFAULT]{CONFIGPATH}/Group/GROUP.ini
    NEXTCONF     = $[DEFAULT]{Home-Dir}/Config/USER.ini

Zusätzlich zur String-Interpolation besteht ausserdem die
Möglichkeit zur sogenannten "Indirektion", d.h. eine
Konfigurationskonstante kann ihrerseits den symbolischen Namen
einer anderen Konfigurationskonstanten (oder einer
"Section"-Überschrift) enthalten, deren Inhalt dann (per
String-Interpolation) eingefügt werden soll.

Hinweis: Der Inhalt der Konfigurationsdateien lässt sich – ganz
wie bei "INI"-Dateien unter Windows – mit Hilfe von "Section"-
(also "Kapitel"-) Überschriften in virtuelle Abschnitte einteilen.
Virtuell deshalb, weil dieselbe "Section"-Überschrift mehrmals
vorkommen darf – sowohl in derselben Konfigurationsdatei als auch
in verschiedenen Konfigurationsdateien. Die Gesamtheit aller
Einträge, die zur selben "Section"-Überschrift gehören, bildet
dann zusammengenommen den virtuellen Abschnitt. Die Verwendung von
"Section"-Überschriften ist jedoch keineswegs verpflichtend, und
alle Einträge ohne vorherige "Section"-Überschrift gehören
automatisch zum Abschnitt "DEFAULT". Doppelte Einträge im selben
virtuellen Abschnitt (nicht notwendigerweise jedoch "physikalisch"
unterhalb derselben "Section"-Überschrift, d.h. innerhalb
desselben Blocks) innerhalb derselben Konfigurationsdatei sind
übrigens verboten (jedoch nicht in unterschiedlichen
Konfigurationsdateien, denn ein Benutzer muss ja z.B. globale
Defaults "überschreiben" können).

Zusammen mit gewissen eingebauten Spezial-Variablen sowie der
Möglichkeit des Zugriffs auf sämtliche Umgebungsvariablen lassen
sich mit Hilfe der String-Interpolation und der Indirektion z.B.
betriebssystemabhängige Einstellungen ohne Programmierung, allein
durch Konfiguration, vor dem Werkzeug "verbergen". Auch ist es auf
diese Weise beispielsweise möglich, von "dem" Benutzerpasswort für
"das" Server-Account zu sprechen (und es auch so zu verwenden),
unabhängig davon, um welchen von mehreren Servern es sich gerade
handelt, bzw. welche Zielumgebung gerade eingestellt ist.

D.h. mit anderen Worten, dem Programm bleibt es erspart, zuerst in
der Konfiguration nachzusehen, welche Zielumgebung eingestellt
ist, um daraufhin (abhängig von der eingestellten Umgebung) sich
das Login und Benutzerpasswort des Aufrufers für diese Umgebung
herauszusuchen. Dies lagert einen bedeutenden (und immer
wiederkehrenden, aber nie identischen) Teil der Programmierung in
eine einfache, leicht zu handhabende Konfigurationssyntax aus, und
hilft so einen erheblichen Programmieraufwand einzusparen.

Nähere Details zur genauen Syntax und den Spezial- und
Umgebungsvariablen sind in der Man-Page dieses Moduls (die mit
Hilfe von "perldoc" angezeigt werden kann, unter Unix auch mittels
"man") zu finden.

Mit Hilfe eines weiteren Moduls ("Base.pm") besteht ausserdem die
Möglichkeit, einzelnen Konfigurationskonstanten über die
Kommandozeile (für die Dauer des jeweiligen Tool-Aufrufs) einen
anderen Wert zuzuweisen. Vereinzelt sind im Modul "Base.pm" zu
diesem Zweck für manche, häufig benötigte Konfigurationskonstanten
auch besonders handliche Abkürzungen definiert. In einigen Fällen
gibt es zudem die Möglichkeit, bestimmte Konfigurationskonstanten
per Umgebungsvariable zu überschreiben (genaueres hierzu ist in
der Man-Page dieses Moduls nachzulesen).