hotti: Konfiguration, OOP² oder doch nur Rad² ?

Beitrag lesen

ehlo,

Was ich aber bis heute noch nicht ganz klar geregelt habe, sind die Konfigurationsvariablen und -konstanten. Wie baut Ihr eure Konfigurationsdateien?

Eine zentrale ini-Datei mit der Möglichkeit, dezentrale ini's dazulinken zu können. Das ini-Format passt sehr gut zu OOP:

[OID]
attr1=value1
a2=v2

wobei die OID sowohl eine Sammlung an Konstanten unter sich haben kann, als auch alle Attribute einer URL (== OID). In den Attributen steht dann alles drin, von Title über Description bis hin zum Body oder Template und auch die Berechtigungen.

In den Attributen steht u.a. auch der Name der Methode, die den Body erzeugt, der Name des Controlers (auch eine Methode) welcher die Eingaben verarbeitet, ergibt sich aus dem Namen der Methode, welche einen Body ohne Eingaben erzeugt. Für die Templates, die ich erst später eingeführt habe, muss der Name des Controlers in einer extra Eigenschaft genannt sein.

Aufgrund der OIDs ergibt sich eine virtuelle Verzeichnisstruktur, [/], [/foo], [/foo/bar] usw. und über dezentrale ini's ist es auch möglich, Verzeichniszweige in die virtuelle Verzeichnisstruktur einzuhängen (linken). Beispielsweise, wenn im Multi-User-Betrieb bestimmte Verzeichniszweige (Artikel im Shop-Bereich...) von externen Kumpels bearbeitet werden.

Der Content-Manager ist nur ein Linker, alle dezentralen ini's in eine einzige Binary compiliert in der dann jedes Response-Objekt komplett mit Body oder Template vorliegt. Die Binary schließlich wird vom ResponseHandler (RH) bei jedem Request eingelesen und nach entsprechenden Prüfungen (found, permissions....) ruft der RH nur noch die zugeordneten Methoden auf.

Das Ganze ist so gebaut, dass eine verständliche Fehlermeldung gezeigt wird, wenn eine Methode nicht vorhanden ist. Das ist mein Plugin-Modell ;)

Hotti