XML Files als Configfiles (Userfreundlichkeit)

[Beat]

Hallo allerseits

Ich schreibe an einem CMS
Dessen Herzstück ist eine Konfigdatei.

Meine Frage und Bitte an euch ist diese:

Könnt ihr euch diese Datei mal anschauen, und mir euren Eindruck berichten?

• Ist die Datei gut strukturiert.
• Ist sie auch für nicht Spezialisten verständlich (Schreibfehler sind noch vorhanden) Och ihr seid ja alles Spezialisten. Ist hier noch ein Hausmann/ eine Hausfrau?

Derzeit plagen mich etwas die folgenden Fragen.
Mein CMS produziert per default HTML4.01 strict.
Dieses vorliegende Configfile aber habe ich als XML verfasst.

Ist dieses Konzept nicht verwirrend für den Anwender.
Ich gehe davon aus, dass Anwender von HTML selbst nicht viel Ahnung haben müssen äh... sollten.
Unter der Annahme, dass solche Configfiles nicht direkt an den Browser geschickt werden, (werden eh nur als .txt ausgegeben) wäre ein Pseudo-Html besser?

Gibt es ein Configfile-Design, das sich als besser / verständlicher herausgestellt hat?

Meine Anforderung an ein Configfile ist, dass es sowohl im Plaintext-Editor wie auch, wenn über eine WebGui bearbeitet, gleichermassen funzenfunzen tut.
Ich brauche also Konsistenz an erster Stelle.

http://www.elcappuccino.ch/privat_ec/__MAINCONFIG.txt
mfg Beat;

[Rouven]

Hello,

Dieses vorliegende Configfile aber habe ich als XML verfasst.

da kann man vmtl. geteilter Meinung drüber sein. Man sollte zunächst mal davon ausgehen, dass kein Laie jemals die Configdatei zu sehen geschweige denn anzufassen bekommt. Damit hat man es hoffentlich mit jemandem zu tun, der sich mit Technik auskennt. Anders herum halte ich XML allerdings für etwas problematisch, da man sich u.U. mit Entities etc. auskennen muss, es gibt zu viele Zeilen, denen eine besondere Bedeutung zukommt. Property-Files sind da etwas einfacher strukturiert, alles was nach dem "=" kommt bis zum Zeilenende ist der Wert, ohne wenn und aber.

MfG
Rouven

[Sven Rautenberg]

Moin!

Könnt ihr euch diese Datei mal anschauen, und mir euren Eindruck berichten?

Mein Eindruck: grausam!

• Ist die Datei gut strukturiert.

Nein. Alles ist voll mit Kommentar, die eigentlichen Konfigurationszeilen sind hingegen extrem gut versteckt. Da springt absolut nichts ins Auge.

• Ist sie auch für nicht Spezialisten verständlich (Schreibfehler sind noch vorhanden) Och ihr seid ja alles Spezialisten. Ist hier noch ein Hausmann/ eine Hausfrau?

Wenn ich nicht weiß, was ich konfigurieren kann, bringt mir eine ausführlich kommentierte Datei relativ wenig. Ebensowenig weiß ich, was ich konfigurieren WILL, und welche der verfügbaren Einstellungen ich denn wünsche oder wünschen sollte.

Ganz tödlich sind natürlich die XML-Kurztags <tagname/>, denn wenn man da was reinintegrieren will, muß man eventuell erstmal das schließende Tag schreiben.

Aus Sicht eines Konfigurationsdateibearbeiters will ich so wenig wie möglich Schreibarbeit haben. Das bedeutet:
1. Vorkonfigurierte, aber auskommentierte Beispielzeilen, die ich mit einfachsten Mitteln aktivieren kann.
2. Kurze Handreichung hinsichtlich der verfügbaren Optionen - keine Komplettdoku.
3. Die Default-Einstellungen, die sich auch ohne Konfiguration aus der Software ergeben würden, sind als aktivierte Einstellungszeile in der Datei enthalten und können auf einfache Weise abgeändert werden.
4. Immer und überall das gleiche Muster der Einstellung.

Mein CMS produziert per default HTML4.01 strict.
Dieses vorliegende Configfile aber habe ich als XML verfasst.

Das ist durchaus eine Wurzel des Übels.

Ist dieses Konzept nicht verwirrend für den Anwender.

Ja, aber aus anderen Gründen. Ich würde nicht freiwillig auf die Idee kommen, eine Konfigurationsdatei in XML zu verfassen, wenn diese Datenstruktur nicht wirklich enorme Vorteile hätte. Und das sehe ich bei dir nicht. Das, was du da konfigurieren willst, paßt locker in ein INI-Dateiformat, alternativ würde es genausogut auch als Variablendefinitionsdatei der genutzten Programmiersprache funktionieren.

Wenn es denn unbedingt mit Tags sein muß, bietet sich als Vorbild die Apache-Konfiguration an: Die einzelnen Werte werden mit "Option Wert1 Wert2 Wert3" in einer einzelnen Zeile geschrieben, zusammengehörige Werte mit Tags gruppiert. Kommentare fallen durch den Zeilenbeginn mittels "#" sowohl extrem auf, zusätzlich erlaubt diese Schreibweise auch das sehr schnelle Auskommentieren oder Reaktivieren einer einzelnen Zeile.

Ich gehe davon aus, dass Anwender von HTML selbst nicht viel Ahnung haben müssen äh... sollten.

Wenn der Anwender von HTML nichts weiß, dann weiß er auch nichts von der Konfiguration eines CMS. Heißt: Die Konfiguration nimmt entweder ein Fachmann vor, der sich mit der CMS-Software auskennt, oder es bleibt eben bei den Defaults, solange die für die Anforderungen ausreichen.

Unter der Annahme, dass solche Configfiles nicht direkt an den Browser geschickt werden, (werden eh nur als .txt ausgegeben) wäre ein Pseudo-Html besser?

Ich halte es für unsinnig, hier überhaupt mit Pseudo-HTML zu operieren. Tags wie <title> oder <meta> verwirren nur, bieten aber keinerlei Mehrwert. Im Gegenteil!

<meta name="..." content="..."> - ok, da kann man natürlich assoziieren, dass hier zu generierende Meta-Elemente in der fertigen Seite gemeint sind. Gefällt mir trotzdem nicht in der Umsetzung, insbesondere nicht mit dem erfundenen Extra-Attribut "ehf-mix".

Ebenso die Geschicjte mit <title>: In allen anderen Konfigurationsoptionen ist der festgelegte Wert Bestandteil eines Attributs - nur hier ist es plötzlich anders, und der Wert ist Bestandteil des Taginhalts.

Verwirr mich nicht mit unterschiedlichen, voneinander abweichenden Methoden der Konfiguration, das wird immer Anlaß von Konfigurationsfehlern sein!

Ich würde explizit die namentliche Übereinstimmung von Konfigurationsoptionen und existierenden HTML-Elementen vermeiden wollen!

Gibt es ein Configfile-Design, das sich als besser / verständlicher herausgestellt hat?

INI-Format.
Apache-Format.
PHP-Skript mit Konfigurationsarraydefinition.

Meine Anforderung an ein Configfile ist, dass es sowohl im Plaintext-Editor wie auch, wenn über eine WebGui bearbeitet, gleichermassen funzenfunzen tut.

Jede "Textdatei" funzt dort.

Ich brauche also Konsistenz an erster Stelle.

Daran mangelt es ja noch.

- Sven Rautenberg

[Beat]

Nein. Alles ist voll mit Kommentar, die eigentlichen Konfigurationszeilen sind hingegen extrem gut versteckt. Da springt absolut nichts ins Auge.

• Ist sie auch für nicht Spezialisten verständlich (Schreibfehler sind noch vorhanden) Och ihr seid ja alles Spezialisten. Ist hier noch ein Hausmann/ eine Hausfrau?

Wenn ich nicht weiß, was ich konfigurieren kann, bringt mir eine ausführlich kommentierte Datei relativ wenig. Ebensowenig weiß ich, was ich konfigurieren WILL, und welche der verfügbaren Einstellungen ich denn wünsche oder wünschen sollte.

Das finde ich seltsam. Kein Kommentar, aber die Anleitung wohl dann irgendwo versteckt, wäre dir hilfreicher?
Ist für mich nicht nachvollziehbar.

Ganz tödlich sind natürlich die XML-Kurztags <tagname/>, denn wenn man da was reinintegrieren will, muß man eventuell erstmal das schließende Tag schreiben.

Ein einfaches Element (eines ohne Endtag) ist ein Element, das keine anderen Elemente zum Inhalt hat.
Das möchte ich ausdrücken. bin aber nicht wirklich darauf angewiesen.

Aus Sicht eines Konfigurationsdateibearbeiters will ich so wenig wie möglich Schreibarbeit haben. Das bedeutet:

1. Vorkonfigurierte, aber auskommentierte Beispielzeilen, die ich mit einfachsten Mitteln aktivieren kann.

Das ist schlicht nicht möglich, weil du an viele Stellen einfach deine eigenen Werte eintragen musst.

Hier ein negativ Beispiel in meinen Augen

#wert=0
#wert=1
wert=auto

Das ist vorkonfiguriert,aber erklärt nichts.

Apache hat das gerne, und ich bekomme regelmässig das Apache Syndrom, weil alles am linken Rand klebt.

2. Kurze Handreichung hinsichtlich der verfügbaren Optionen - keine Komplettdoku.

Meine Krankheit. Aber ich brauche dies auch als Leitfaden fürs programmieren.

3. Die Default-Einstellungen, die sich auch ohne Konfiguration aus der Software ergeben würden, sind als aktivierte Einstellungszeile in der Datei enthalten und können auf einfache Weise abgeändert werden.

Theoretisch ja, aber praktisch dann nicht anwendbar, wenn der Default eine leere Liste ist.

4. Immer und überall das gleiche Muster der Einstellung.

Generell ja, aber das hat auch seine Tücken. Wenn wirklich sich alle identisch anfasst, weist du bald nicht mehr, was du anfasst.

Aber die Anforderung besagt, dass ich generell eine einheitliche Sprache brauche. Das kann dann nur [p:c] oder etwas html artiges sein.

...

Ist dieses Konzept nicht verwirrend für den Anwender.

Ja, aber aus anderen Gründen. Ich würde nicht freiwillig auf die Idee kommen, eine Konfigurationsdatei in XML zu verfassen, wenn diese Datenstruktur nicht wirklich enorme Vorteile hätte. Und das sehe ich bei dir nicht. Das, was du da konfigurieren willst, paßt locker in ein INI-Dateiformat, alternativ würde es genausogut auch als Variablendefinitionsdatei der genutzten Programmiersprache funktionieren.

Tja, bis jetzt sieht es ja relativ Flach aus.
Das Problem ist, ich brauche eine Sprache für Baumartige Verschachtelung, und da ist ebene XML gut.

Wenn es denn unbedingt mit Tags sein muß, bietet sich als Vorbild die Apache-Konfiguration an: Die einzelnen Werte werden mit "Option Wert1 Wert2 Wert3" in einer einzelnen Zeile geschrieben, zusammengehörige Werte mit Tags gruppiert. Kommentare fallen durch den Zeilenbeginn mittels "#" sowohl extrem auf, zusätzlich erlaubt diese Schreibweise auch das sehr schnelle Auskommentieren oder Reaktivieren einer einzelnen Zeile.

Da muss ich widersprechen. Dieses Format ist extrem Gewöhnungsbedüftig.
Da hagelt es von Inkonsistenzen.

...

Ich halte es für unsinnig, hier überhaupt mit Pseudo-HTML zu operieren. Tags wie <title> oder <meta> verwirren nur, bieten aber keinerlei Mehrwert. Im Gegenteil!

<meta name="..." content="..."> - ok, da kann man natürlich assoziieren, dass hier zu generierende Meta-Elemente in der fertigen Seite gemeint sind. Gefällt mir trotzdem nicht in der Umsetzung, insbesondere nicht mit dem erfundenen Extra-Attribut "ehf-mix".

Und was ist die Lösung? Ein Element ganz artfremd zu beschreiben im Sonne vom
<global-keywords mode=append words="">

Damit entgehe ich eher zufällig dem Anklang und habe unter Umständen weniger erklärt als wenn ich <meta> verwende.

Ebenso die Geschicjte mit <title>: In allen anderen Konfigurationsoptionen ist der festgelegte Wert Bestandteil eines Attributs - nur hier ist es plötzlich anders, und der Wert ist Bestandteil des Taginhalts.

Ja. Das ist ein inkonsistenter Punkt. akzeptiert.

Verwirr mich nicht mit unterschiedlichen, voneinander abweichenden Methoden der Konfiguration, das wird immer Anlaß von Konfigurationsfehlern sein!

Ich würde explizit die namentliche Übereinstimmung von Konfigurationsoptionen und existierenden HTML-Elementen vermeiden wollen!

Würdest du wollen aber nicht können, ausser du rettest dich in eine Syntax, die schon gar nicht mit html oder xml verwandt ist.

Ich könnte natürlich auf [p:c] umstellen, da dies auch eine baumartige gruppierung erlaubt, aber frei ist von semantischer Vorherbestimmung im Sinne von HTML.

Gibt es ein Configfile-Design, das sich als besser / verständlicher herausgestellt hat?

INI-Format.

OK, [p:c] nicht unähnlich

Apache-Format.

Grauenhaft

PHP-Skript mit Konfigurationsarraydefinition.

läuft auf Perl. Warum die Syntax einer anderen Sprache?
Aber du hast meine Frage beantwortet.

OK. Ich werde also eher das Augenmerk auf Syntaktische Einheitlichkeit setzen.
Kommentare sind weniger wichtig.
(Für mich sind sie es, denn sie sind ein Plan dessen, was mein Programm zu bewältigen hat, und was ich damit beabsichtige)

Ich werde wohl für den User alles über die GUI machen, so dass er vom Format der Konfiguration gar nicht berührt wird.

mfg Beat

[at]

Hallo.

Das finde ich seltsam. Kein Kommentar, aber die Anleitung wohl dann irgendwo versteckt, wäre dir hilfreicher?
Ist für mich nicht nachvollziehbar.

Für mich ist auch nicht nachvollziehbar, weshalb du sie verstecken willst. Eine einfache conf_readme.txt oder ähnliches sollte doch nicht so schwer zu finden sein. Wenn du deine XML-Datei auch auf .xml enden ließest, könnte die Hilfedatei sogar den gleichen Vornamen tragen.
Ich finde XML-Dateien übrigens recht praktisch, da ich sie direkt mit dem Property List Editor bearbeiten kann, dann aber bitte möglichst ohne Kommentare. Allerdings hattest du selbst das Erfordernis definiert, dass die Datei mehr oder minder gut in einem Texteditor zu bearbeiten sein solle.

Ein einfaches Element (eines ohne Endtag) ist ein Element, das keine anderen Elemente zum Inhalt hat.
Das möchte ich ausdrücken. bin aber nicht wirklich darauf angewiesen.

Ich kann den Sinn nachvollziehen und würde es ähnlich machen.

Aus Sicht eines Konfigurationsdateibearbeiters will ich so wenig wie möglich Schreibarbeit haben. Das bedeutet:

1. Vorkonfigurierte, aber auskommentierte Beispielzeilen, die ich mit einfachsten Mitteln aktivieren kann.

Das ist schlicht nicht möglich, weil du an viele Stellen einfach deine eigenen Werte eintragen musst.

Umso wichtiger ist es, dass diese Stellen offensichtlich sind.

Hier ein negativ Beispiel in meinen Augen

#wert=0
#wert=1
wert=auto

Das ist vorkonfiguriert,aber erklärt nichts.

Aber nur weil du die Hilfedatei nicht zur Hand hast.

Apache hat das gerne, und ich bekomme regelmässig das Apache Syndrom, weil alles am linken Rand klebt.

2. Kurze Handreichung hinsichtlich der verfügbaren Optionen - keine Komplettdoku.

Meine Krankheit. Aber ich brauche dies auch als Leitfaden fürs programmieren.

Dann lagere es deinen Leitfaden eben aus.

4. Immer und überall das gleiche Muster der Einstellung.

Generell ja, aber das hat auch seine Tücken. Wenn wirklich sich alle identisch anfasst, weist du bald nicht mehr, was du anfasst.

Das ist eine Frage der Struktur und der Werkzeuge. Ellenlange XML-Listen in einem einfachen Texteditor zu bearbeiten, ist doch ohnehin häufig eine Zumutung. Aber wenn man schon XML verwendet, kann man ja auch ein besser geeignetes Werkzeug verwenden.

Aber die Anforderung besagt, dass ich generell eine einheitliche Sprache brauche. Das kann dann nur [p:c] oder etwas html artiges sein.

Inwiefern? Wer gibt das vor? Was heißt "einheitlich"? Was außer HTML definierst du als HTML-artig?

Tja, bis jetzt sieht es ja relativ Flach aus.
Das Problem ist, ich brauche eine Sprache für Baumartige Verschachtelung, und da ist ebene XML gut.

Kannst du mal ein Beispiel für eine vollständige Konfiguration bereitsstellen? Dann wird das sicher deutlicher.

Ich halte es für unsinnig, hier überhaupt mit Pseudo-HTML zu operieren. Tags wie <title> oder <meta> verwirren nur, bieten aber keinerlei Mehrwert. Im Gegenteil!

<meta name="..." content="..."> - ok, da kann man natürlich assoziieren, dass hier zu generierende Meta-Elemente in der fertigen Seite gemeint sind. Gefällt mir trotzdem nicht in der Umsetzung, insbesondere nicht mit dem erfundenen Extra-Attribut "ehf-mix".

Und was ist die Lösung? Ein Element ganz artfremd zu beschreiben im Sonne vom
<global-keywords mode=append words="">

Damit entgehe ich eher zufällig dem Anklang und habe unter Umständen weniger erklärt als wenn ich <meta> verwende.

Du hältst den Wiedererkennungswert für einen großen Vorteil. Das kann ich persönlich nicht nachvollziehen, wenn es um Konfigurationsdaten geht. Hinsichtlich eines Templates hättest du hingegen sicher recht.

Verwirr mich nicht mit unterschiedlichen, voneinander abweichenden Methoden der Konfiguration, das wird immer Anlaß von Konfigurationsfehlern sein!

Ich würde explizit die namentliche Übereinstimmung von Konfigurationsoptionen und existierenden HTML-Elementen vermeiden wollen!

Würdest du wollen aber nicht können, ausser du rettest dich in eine Syntax, die schon gar nicht mit html oder xml verwandt ist.

Es geht doch nur um die Elementnamen und hinsichtlich der Unterscheidung von Konfigurationsdaten und Templates kann ich das gut nachvollziehen.

Gibt es ein Configfile-Design, das sich als besser / verständlicher herausgestellt hat?

Das ist eine Frage der erforderlichen Strukturtiefe und Inhalte sowie der geeigneten Werkzeuge. Für deinen Zweck halte ich XML nicht für falsch.

Ich werde wohl für den User alles über die GUI machen, so dass er vom Format der Konfiguration gar nicht berührt wird.

Das ist sicher sinnvoll.
MfG, at

[Beat]

Das finde ich seltsam. Kein Kommentar, aber die Anleitung wohl dann irgendwo versteckt, wäre dir hilfreicher?
Ist für mich nicht nachvollziehbar.

Für mich ist auch nicht nachvollziehbar, weshalb du sie verstecken willst. Eine einfache conf_readme.txt oder ähnliches sollte doch nicht so schwer zu finden sein.

Tja, mit wem hat an es zu tun?
Ich muss nur mich selbst beobachten, Je mehr Files, um so mehr Chaos.
Ich habe das jetzige Konfigfile noch viel mehr reduziert, und kann es hoffentlich so markieren, dass es dann im Installationsordner ins Auge sticht.

Wenn du deine XML-Datei auch auf .xml enden ließest, könnte die Hilfedatei sogar den gleichen Vornamen tragen.

Ich halte es für keine gute Idee, User, die mit systemfiles konfrontiert werden, mit Dateiendungen zu belästigen.

MAINCONFIG
und
LIESMICH

alles andere ist von Übel.

Ich finde XML-Dateien übrigens recht praktisch, da ich sie direkt mit dem Property List Editor bearbeiten kann, dann aber bitte möglichst ohne Kommentare. Allerdings hattest du selbst das Erfordernis definiert, dass die Datei mehr oder minder gut in einem Texteditor zu bearbeiten sein solle.

Meine angezielte Benutzergruppe gehört zu jenen, die sich lieber Webseiten machen lassen, als nur irgend ein chinesisches Zeichen zu schreiben.

Ich bin nun gänzlich weg vom XML Format. Nicht einmal als ein Speicherformat brauche ich es, weil ich mit Perls Storable Modul direkt Bin Daten speichere, die über eine GUI verändert werden.

...

Tja, bis jetzt sieht es ja relativ Flach aus.
Das Problem ist, ich brauche eine Sprache für Baumartige Verschachtelung, und da ist ebene XML gut.

Kannst du mal ein Beispiel für eine vollständige Konfiguration bereitsstellen? Dann wird das sicher deutlicher.

Es geht darum, dass im grunde die ganze Filestruktur im XML in verschiedenen Elementen vorlag.
hier ein beispiel aus dem alten XML entwurf

<ehf-filedefaults>

<filetype
        type="txt"
        parse="0"
    />

<filetype
        type="ehfml"
        parse="1"
    />

<filetype
        type="gif"
        parse="0"
    />

...

</ehf-fildefaults>

und

<ehf-filedefs>

<file
       id="f001"
       name="example.txt"
       label="Beispiel"
       type="txt"
       parse="1"
       comment="ein Kommentar"
   />

...

<ehf-groups>

<group
      id="g123"
      name="contact"
      label="Kontaktseiten"
      members="f002,f004"
      comment="ein Kommentar"
   />

...

</ehf-groups>

Wie gesagt, solche Daten wird es weiterhin geben. Aber es ist obsolet dies in einem dem User sichtbaren Format zu präsentieren.

...

Gibt es ein Configfile-Design, das sich als besser / verständlicher herausgestellt hat?

Das ist eine Frage der erforderlichen Strukturtiefe und Inhalte sowie der geeigneten Werkzeuge. Für deinen Zweck halte ich XML nicht für falsch.

Ich kann direkt Perl Hashes speichern. Hier habe ich ein geeigneteres Instrument gefunden.

Die jetzt noch notwendigen Konfigurationen sind so mnimal geworden, dass sie als flache Liste dargestellt werden können.

Hier bin ich Alexander Brock gefolgt

mfg Beat

[at]

Hallo.

Wenn du deine XML-Datei auch auf .xml enden ließest, könnte die Hilfedatei sogar den gleichen Vornamen tragen.

Ich halte es für keine gute Idee, User, die mit systemfiles konfrontiert werden, mit Dateiendungen zu belästigen.

MAINCONFIG
und
LIESMICH

alles andere ist von Übel.

Das kann ich insofern nicht nachvollziehen, als dass zum einen LIESMICH alles mögliche enthalten könnte, das nichts mit der Konfiguration zusammenhängt und zum anderen nicht sichergestellt ist, dass sich nicht noch einige andere Dateien alphabetisch dazwischen einsortieren, so dass der Zusammenhang endgültig nicht mehr offensichtlich ist.

Ich bin nun gänzlich weg vom XML Format.

Schade, aber wenn es nicht zu deinen Anforderungen passt, ist das natürlich richtig so.

Nicht einmal als ein Speicherformat brauche ich es, weil ich mit Perls Storable Modul direkt Bin Daten speichere, die über eine GUI verändert werden.

Und weil du deinen Anspruch, es müsse im Texteditor funktionieren, über Bord geworfen hast.

Tja, bis jetzt sieht es ja relativ Flach aus.
Das Problem ist, ich brauche eine Sprache für Baumartige Verschachtelung, und da ist ebene XML gut.

Kannst du mal ein Beispiel für eine vollständige Konfiguration bereitsstellen? Dann wird das sicher deutlicher.

Es geht darum, dass im grunde die ganze Filestruktur im XML in verschiedenen Elementen vorlag.
hier ein beispiel aus dem alten XML entwurf

[...]

Wie gesagt, solche Daten wird es weiterhin geben. Aber es ist obsolet dies in einem dem User sichtbaren Format zu präsentieren.

Vor allem sah das immer noch sehr flach aus. Da ist dann natürlich die Frage nach dem Sinn von XML angebracht.

Gibt es ein Configfile-Design, das sich als besser / verständlicher herausgestellt hat?

Das ist eine Frage der erforderlichen Strukturtiefe und Inhalte sowie der geeigneten Werkzeuge. Für deinen Zweck halte ich XML nicht für falsch.

Ich kann direkt Perl Hashes speichern. Hier habe ich ein geeigneteres Instrument gefunden.

Bei der gezeigten Strukturtiefe glaube ich das gern.

Die jetzt noch notwendigen Konfigurationen sind so mnimal geworden, dass sie als flache Liste dargestellt werden können.

Prima.
MfG, at

[Beat]

Ein Addendum.

Die Aufgabe hat sich insofern verlagert, und ist nun als ein Perl Thema aufzufassen.

Das Script braucht grundlegende Configurationsdaten.
Da diese Datenanforderungen mit Scriptapdates sich ändern können, muss
eine minimal operierende Configuration aus dem Script selbst entstehen.

Mein Idee nun verwendet ein Modul, dessen Inhalt ein Hash ist.
Das Modul soll standardmässig mit use eingebunden werden.

Ich möchte damit einen standardmässig schnellen Datenzugriff,
statt langsames Einlesen von Userkonfigurationen,
welche zudem Fehler enthalten könnten, erreichen.

Ist es nun notwendig, dass eine Basiskonfiguration erstellt wird [1]
( dazu gehören
  --erfasse das verfügbare Filesystem, und die Files
  --erfasse eine eventuell vorliegende Userkonfiguration
)
... so soll eine Scriptroutine das Perlmodul schreiben.
Das setzt voraus, dass ich natürlich das Modul als print Text beschreiben
kann, während es via use eingebunden ist.

Beim nächsten Script-Run würde dann aus dem Modul ein aktualisierter Hash eingelesen, der die aktualiserte gültige Konfiguration darstellt.

[1] Diese Notwendigkeit egibt sich aus dem firstrun des Scriptes
    Sowie auf Wunsch des Admins, wenn er seine eigene
    Userkonfiguration geändert hat

Meine Frage dazu:

hat jemand Erfahrung mit einem solchen Vorgehen?
hat es sich als praktisch erwiesen?
Pitfalls?

mfg Beat;

[Alexander (HH)]

Moin Moin!

Mein Idee nun verwendet ein Modul, dessen Inhalt ein Hash ist.
Das Modul soll standardmässig mit use eingebunden werden.

Ich möchte damit einen standardmässig schnellen Datenzugriff,
statt langsames Einlesen von Userkonfigurationen,
welche zudem Fehler enthalten könnten, erreichen.

Irgendwann wird jemand die Konfiguration manuell ändern müssen, da ist dann ein bekanntes, einfaches Format meistens weniger anfällig als ein Modul, das als Perl-Code geparst wird.

Das Windows-INI-Format kann wesentlich entspannter gelesen werden. JSON ist auch recht schmerzfrei und mit JSON::XS rattenschnell, YAML hat AFAIK einige lästige Begrenzungen. XML ist Overkill, insbesondere beim Parsen, und kann auch nicht mehr Struktur abbilden als JSON.

JSON und INI sind schnell und schmerzfrei gelesen, der Perl-Start dauert wesentlich länger.

Ist es nun notwendig, dass eine Basiskonfiguration erstellt wird [1]
( dazu gehören
  --erfasse das verfügbare Filesystem, und die Files
  --erfasse eine eventuell vorliegende Userkonfiguration
)
... so soll eine Scriptroutine das Perlmodul schreiben.
Das setzt voraus, dass ich natürlich das Modul als print Text beschreiben
kann, während es via use eingebunden ist.

Das geht problemlos. use X ist equivalent zu BEGIN { require X; X->import(); }, wobei require die Datei auf einen Schlag einliest. Wenn das Modul dann abgearbeitet wird, ist die Datei beschreibbar.

Beim nächsten Script-Run würde dann aus dem Modul ein aktualisierter Hash eingelesen, der die aktualiserte gültige Konfiguration darstellt.

Warum so umständlich?

Starte das Script, suche nach Updates, installiere Updates, aktualisiere die Konfiguration, starte die eigentlich angeforderte Aufgabe. Das geht in einem Programmlauf.

Wenn Du eine Grundkonfiguration und eine User-Konfiguration haben willst, benutze zwei Konfigurationsdateien: Eine, sagen wir mal system.ini, fängt mit der dicken fetten Warnung an, in der Datei nicht herumzupfuschen, die zweite, user.ini, ist anfänglich leer. Die system.ini wird zuerst gelesen und legt die Defaults fest, die user.ini überschreibt dann die selbe Datenstruktur mit den Werten, die der User gerne hätte. Updates manipulieren dann nur die system.ini. (Außer bei wirklich üblen Fehlerfällen, wo ein Eintrag aus der user.ini gelöscht werden muß.)

Wenn Du ohnehin eine SQL-DB benutzt, kannst Du die Konfiguration natürlich auch in eine DB-Tabelle schreiben, und Du brauchst nur eine Mini-Datei, die die Verbindung zur DB beschreibt (DBI-Connect-String, User-Name, Passwort).

Alexander

[Beat]

Irgendwann wird jemand die Konfiguration manuell ändern müssen, da ist dann ein bekanntes, einfaches Format meistens weniger anfällig als ein Modul, das als Perl-Code geparst wird.

Nein, für die Userkonfiguration soll es eine GUI geben.
Damit ich diese aber darstellen kann, muss das Script eine Basiskonfiguration bereitstellen.

Da ist also kein Problem mit dem Perlcode, denn nur Perl sieht ihn.

Ist es nun notwendig, dass eine Basiskonfiguration erstellt wird [1]
( dazu gehören
  --erfasse das verfügbare Filesystem, und die Files
  --erfasse eine eventuell vorliegende Userkonfiguration
)
... so soll eine Scriptroutine das Perlmodul schreiben.
Das setzt voraus, dass ich natürlich das Modul als print Text beschreiben
kann, während es via use eingebunden ist.

Das geht problemlos. use X ist equivalent zu BEGIN { require X; X->import(); }, wobei require die Datei auf einen Schlag einliest. Wenn das Modul dann abgearbeitet wird, ist die Datei beschreibbar.

Ich habe jetzt den ersten Test durch:
Lade das Modul mit use, lies dann aber in einer Routine unten den Content ein, und schreibe ihn wieder in die pm Datei. Soweit ok. Also das Verfahren sollte problemlos möglich sein.

Beim nächsten Script-Run würde dann aus dem Modul ein aktualisierter Hash eingelesen, der die aktualiserte gültige Konfiguration darstellt.

Warum so umständlich?

Starte das Script, suche nach Updates, installiere Updates, aktualisiere die Konfiguration, starte die eigentlich angeforderte Aufgabe. Das geht in einem Programmlauf.

...Elend langsam. Das machst du nicht bei einer komplexeren Anwendung für jeden HTTP Request.

Updates gibt es verschiedener Art:
Softwareupdates (selten)
Userdataupdates (wohl häufig)
Aber in der Regel kann aus einer konstanten Konfiguration bedient werden, die eben möglichst geradlinig Perl bereitstehen soll.

Bei jedem Scriptrun ein nicht optimiertes Format, egal welcher Art einzulesen, ist eindeutig ein NoGo.

Wenn Du eine Grundkonfiguration und eine User-Konfiguration haben willst, benutze zwei Konfigurationsdateien: Eine, sagen wir mal system.ini, fängt mit der dicken fetten Warnung an, in der Datei nicht herumzupfuschen, die zweite, user.ini, ist anfänglich leer. Die system.ini wird zuerst gelesen und legt die Defaults fest, die user.ini überschreibt dann die selbe Datenstruktur mit den Werten, die der User gerne hätte. Updates manipulieren dann nur die system.ini. (Außer bei wirklich üblen Fehlerfällen, wo ein Eintrag aus der user.ini gelöscht werden muß.)

Wie gesagt. alles woran man nicht rumfuchteln darf ist derzeit
<quote>
1;

</quote>
Dieses mit Sinn zu füllen soll nicht bei jedem Run, sondern nach Updates, Inhaltsaktualisierungen durch den Admin geschehen, via Push-Button

Wenn Du ohnehin eine SQL-DB benutzt, kannst Du die Konfiguration natürlich auch in eine DB-Tabelle schreiben, und Du brauchst nur eine Mini-Datei, die die Verbindung zur DB beschreibt (DBI-Connect-String, User-Name, Passwort).

Warum das wichtige in Datenbanken verstecken, um es dann drei/viermal umzuformen?
Ich verfolge eine Absicht wenn ich die notwendige Konfiguration in ein .pm stecken will.

Das was ich eventuell in mein eigenes Datenbank System speichere, sind die Konfigurationsabschnitte für den Admin, für die Bearbeitung, GUI, Helpfiles etc...

mfg Beat

[Alexander (HH)]

Moin Moin!

Irgendwann wird jemand die Konfiguration manuell ändern müssen, da ist dann ein bekanntes, einfaches Format meistens weniger anfällig als ein Modul, das als Perl-Code geparst wird.

Nein, für die Userkonfiguration soll es eine GUI geben.

Was eine INI- oder JSON-Datei trotzdem nicht ausschließt.

Beim nächsten Script-Run würde dann aus dem Modul ein aktualisierter Hash eingelesen, der die aktualiserte gültige Konfiguration darstellt.

Warum so umständlich?

Starte das Script, suche nach Updates, installiere Updates, aktualisiere die Konfiguration, starte die eigentlich angeforderte Aufgabe. Das geht in einem Programmlauf.

...Elend langsam. Das machst du nicht bei einer komplexeren Anwendung für jeden HTTP Request.

Nö, nur beim Start der Anwendung und ggf. nach einer einstellbaren Zeit nochmal. Oder willst Du für jeden HTTP-Request den Perl-Compiler/Interpreter nochmal anwerfen?

Updates gibt es verschiedener Art:
Softwareupdates (selten)
Userdataupdates (wohl häufig)
Aber in der Regel kann aus einer konstanten Konfiguration bedient werden, die eben möglichst geradlinig Perl bereitstehen soll.

Bei jedem Scriptrun ein nicht optimiertes Format, egal welcher Art einzulesen, ist eindeutig ein NoGo.

Aber die Startup-Kosten von Perl stören Dich nicht?

Perl-Code muß auch nochmal durch den Perl-Parser (der definitiv alles andere als trivial ist). "Optimiert" ist das auch nicht.

Überlege mal, ob ein schnell zu ladendes binäres Format Deine Anforderungen erfüllt. Storable könnte eine Idee sein.

Vergleiche das aber mal mit dem Aufwand, den JSON::XS für die gleiche Datenmenge treibt. Ich schätze, dass der Aufwand in beiden Fällen ähnlich niedrig ist, verglichen mit dem Rest der Applikation, und deutlich niedriger als require file bzw. use module. Und JSON hat den Vorteil, dass man im Notfall Hand anlegen kann.

Wie gesagt. alles woran man nicht rumfuchteln darf ist derzeit
<quote>
1;

</quote>

Was für eine unnötige Einschränkung, die require Dir da aufbrummt. do $filename hat diese Einschränkung nicht.

Dieses mit Sinn zu füllen soll nicht bei jedem Run, sondern nach Updates, Inhaltsaktualisierungen durch den Admin geschehen, via Push-Button

Inhalte gehören in die DB, nicht in die Konfiguration.

Warum das wichtige in Datenbanken verstecken,

Weil Dir das Ärger mit Locking, zerschossenen Dateien und World-Writeable-Verzeichnissen abnimmt.

um es dann drei/viermal umzuformen?

Paßt Dein DB-Schema nicht zur Anwendung, dass Du die Daten so oft umformen mußt?

Ich verfolge eine Absicht wenn ich die notwendige Konfiguration in ein .pm stecken will.

Ich bezweifle nur, dass das der beste Weg ist. Offensichtlich möchtest Du im Web-Kontext arbeiten. Du hast eine Applikation, deren Konfigurationsdatei und deren Programmverzeichnis für den Webserver schreibbar sein muß. Das ist definitiv keine gute Idee.

Alexander

[Beat]

Überlege mal, ob ein schnell zu ladendes binäres Format Deine Anforderungen erfüllt. Storable könnte eine Idee sein.

Genau das ist es.
Hätte ich eigentlich selbst drauf kommen können.

mfg Beat