nicht angemeldet
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:
- 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.
- Kurze Handreichung hinsichtlich der verfügbaren Optionen - keine Komplettdoku.
Meine Krankheit. Aber ich brauche dies auch als Leitfaden fürs programmieren.
- 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.
- 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