XML Files als Configfiles (Userfreundlichkeit)

[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