So, nachdem die letzten Beiträge eher “Blabla” waren, heute endlich mal wieder was mit Inhalt. Es geht um meine eigene Erweiterung von Zend_Application mit dem Namen Libcrunch_Application_Application [1] natürlich zu finden in der hauseigenen Libcrunch-Bibliothek. Die Klasse nutzt zudem noch Libcrunch_Config_Config, weshalb man es (wie jede andere Bibliothek) nicht auseinander pflücken sollte.

Zend_Application wurde nun so erweitert, dass sie statt einer einzelnen Konfiguration (configs/application.ini) auch die Angabe eines ganzen Verzeichnisses (configs/) erlaubt, aus dem dann alle gefundenen Dateien geladen und integriert werden.

Über …

Als ich Zend_Application das erste mal in der Hand hatte, fiel mir gleich auf, dass man nur eine einzelne Konfigurationsdatei angeben kann. Das find ich eigentlich auch heute nicht sooo schlimm, allerdings war die Datei in ihrem Verzeichnis schon sehr einsam. Die Idee war nun, dass man das Verzeichnis als Ganzes nutzen kann.

Bei Angabe einer einzelnen Datei passiert nichts Aussergewöhnliches, gibt man allerdings ein Verzeichnis an, so wird darüber (rekursiv) iteriert und alle gefunden (gültigen) Konfigurationen an der korrekten Stelle eingebunden. Was heißt “korrekte Stelle”? Einfach alle Konfigurationen mit der Wurzel zu vermischen, wirkte nicht besonders praktisch, weil damit jede einzelne Datei genauso unübersichtlich bleibt, wie vorher auch. Die jetzige Umsetzung setzt jede Konfiguration so in den Optionen-Baum ein, wie es durch die (relative) Pfadangabe vorgegeben ist.

Klingt etwas umständlich (Note: Bessere Formulierung suchen). Praktisch bedeutet dass, das der Inhalt der Datei resources/frontController.xml im Options-Baum unter resources.frontController eingebunden wird. Ebenso könnte man nun die gleichen Optionen in resources.xml unter den Abschnitt frontController eintragen, man ist da relativ frei, wie man die einzelnen Optionen aufteilt, bzw nicht aufteilt.

Schwächen

Vom Overhead gegenüber einer einzelnen Konfigurationsdatei will ich garnicht erst reden. Dazu gibt es allerdings schon Ideen.

Ein anderes “Problem” ist, dass es keine “globale” Konfigurationsdatei mehr gibt. Bedingt durch die Art und Weise, wie die einzelnen Dateien eingebunden werden, kann es keine Datei geben, die direkt auf die Wurzel des Optionsbaumes zeigt. Ebenso wenig (mit der selben Begründung) ist es möglich zwei Dateien am selben Punkt einzuhängen. Grundsätzlich gibt es dazu auch eine Idee, allerdings find ich das zweitrangig.

Jede Konfigurationsdatei braucht den kompletten Aufbau, speziell alle benötigten Sektionen. Bei Ini-Dateien hält dabei sich der Overhead im Vergleich zu Xml-Dateien eher in Grenzen. Der Aufbau ist allerdings notwendig, denn sonst wären umgebungsabhängige Konfigurationen garnicht mehr möglich. Keine Idee, allerdings auch kein wirkliches Problem

<config>
  <default>
    <!-- Config -->
  </default>
  <development extends="default">
    <!-- Config -->
  </development>
  <production extends="default">
    <!-- Config -->
  </production>
</config>

Es muss auch für eine tiefer verschachtelte Konfiguration die komplette Verzeichnisstruktur aufgebaut werden, wenn man die Verschachtelung eben nicht in der Datei selbst stehen haben möchte. Auch dafür gibt es Ideen.

Man sollte es übrigens vermeiden in zwei Dateien Schlüssel zu definieren, die das selbe bedeuten. Problem ist, dass die Reihenfolge der Abarbeitung nicht gewährleistet werden kann, so dass es vorkommen kann, das mal der eine, mal der andere Vorrang hat. Das gilt nicht für die einzelnen Abschnitte, weil die Ursache für beides liegt in Zend_Config::merge() und ist eben so .

Future Plans

• Wie angedeutet auf jeden Fall eine Möglichkeit, dass nicht jedes mal alles neu zusammen gebaut werden muss. Caching fällt dabei raus, weil das erst später bereit steht. Grund: Es hängt ab von der Konfiguration
• Um nicht gleich Dateien löschen zu müssen, wenn man die Konfiguration nicht braucht, existiert bei mir lokal schon der entsprechende Code, dass man sie “mal eben” deaktiviert. Näheres später. Umbenennen ist nebenbei auch nicht so eine gute Idee, weil der Code “auf Verdacht” versucht jede Datei einzubinden, man spart also nicht wirklich irgendetwas.
• Grundsätzlich wären Konfigurationsdateien in den Modul-Verzeichnissen interessant, allerdings fehlt es mir noch an DER überzeugenden Idee. Steht auf jeden Fall trotzdem irgendwo unten auf der ToDo.
• Tiefere Verschachtelungen sollten nicht einzig über den Verzeichnisaufbau aufgelöst werden, weil das sonst zu zu Strukturen bis x Ebenen in die Tiefe führen kann, die trotzdem nur eine Datei enthält. Auch hier existiert eine Idee.

Nachtrag

Punkt 2 von den “Future Plans” wird es dann wohl direkt beim nächsten Commit in mein Git-Repo geben: Es war leichter als erwartet und wurde mal eben während des Schreibens dieses Beitrages umgesetzt.

Nachtrag 2

Der schon genannte “Punkt 2″ ist nun umgesetzt, es ist bloss nicht mehr so einfach das vorkompilieren der Konfiguration zu verhindern … Dazu muss ich mir noch was ausdenken . Allerdings fiel mir bei Codedurchsicht auf, dass der letzte Punkt (der mit der Verschachtelung) “aus Versehen” bereits geklärt war. Und zwar sieht es so aus, dass Punkte im Verzeichnis- oder Dateinamen den selben Effekt haben, wie Verzeichnistrenner. Das heißt, zwei Datei resources/frontController.xml und resources.frontController.xml bedeuten gewissermaßen das Selbe. Das bedeutet ebenso, dass man im begrenzten Maße schon mehrere Konfigurationsdateien am selben Ort einhängen kann, man sollte es bloss tunlichst vermeiden.

View Spass damit,
Sebastian

[1] Der Name kommt daher, dass ich mir bei Einführung von ZF2 und PHP5.3-Namespaces etwas Vorarbeit bei der Struktur sparen möchte.