Zustand jetzt

Nach Umbau der Konfiguration (Ablage in DB) werden client-specific skins noch etwas komplizierter. Hier gilt es zwei "Konfigurationswelten" zu bedienen.
1. resources.layout.layoutPath = ...
2. runtimeOptions.XYZ bspw. runtimeOptions.publicAdditions.css
nur letztere sind in der DB, resources.XYZ verbleiben in der installation.ini.

Strategien das zu verbessern

Namensraum der Konfigwerte

Statt hier resource.XX und runtimeOptions zu mischen, wäre diese Werte wohl alle besser unterhalb von resources. aufgehoben.
Bsp.:
runtimeOptions.publicAdditions.css
=>
resources.layout.publicAdditions.css

Konfigwerte aktivieren

Anstatt die für eine client-specific benötigten Werte irgendwo separat zu speichern und diese dann händisch in die Installation zu "mergen" wäre es wesentlich einfacher innerhalb des client-specific Verzeichnisses diese ini-Daten direkt abzulegen.

Bsp.
/client-specific/config.ini

Abschreckendes Beispiel

Hier nun die Anweisungen eine aktuellen Kunden-Umsetzung als abschreckendes Beispiel.. nicht sehr übersichtlich

[application]
;Specific Layout:
resources.layout.layoutPath = APPLICATION_PATH "/../client-specific/layouts/"


; runtimeOptions can not be set in installation.ini any more therefore:
;runtimeOptions.publicAdditions.css[] = "client-specific/editorAdditions.css"
;runtimeOptions.server.pathToIMAGES = "client-specific"

; has to be done by calling the following on the command line:
; ./translate5.sh config runtimeOptions.publicAdditions.css [\"css/editorAdditions.css?v=1\"]
; ./translate5.sh config runtimeOptions.server.pathToIMAGES client-specific