Entschuldigung aber du hast nicht die Rechte um dieses Post zu sehen!
6 Antworten auf „Anforderung Sys-StSt-1: Zentrale Konfigurationsdatei“
Ist die Speicherung der StartStopp-Konfiguration als XML-Datei unverzichtbar?
Für eine Kommunikationsschnittstelle, die eventuell auch in Webapplikationen verwendet werden soll, würde man vermutlich JSON-Objekte verwenden, da diese ohne weitere Konvertierung in JavaScript verwendbar wäre.
Es würde sich daher anbieten, auch die Konfiguration als JSON-Datei abzulegen, dann muss nur eine Konvertierung ungesetzt und gepflegt werden.
Die Speicherung im XML-Format ist nicht unverzichtbar. Allerdings ist der Einsatz in Web-Applikationen auch relativ vage.
Wenn JSON verwendet wird, muss das natürlich auch von dem Konverter unterstützt werden, vermutlicht sogar expliziter als bisher. Also tatsächlich eine Konvertierung von XML nach JSON und nicht nur implizit im alten Format einlesen und im neuen speichern.
Außerdem muss dann die Bearbeitung der Konfiguration über die Benutzeroberfläche (ggf. noch stärker) in den Fokus gerückt werden. Ziel ist es dann, die Bearbeitung nahezu ausschließlich über die GUI zu machen und den externen Texteditor als den (seltenen) Ausnahmefall zu lassen. Und es wäre dann natürlich sehr hilfreich, einfache Beispielkonfigurationen bei der Auslieferung beizulegen.
Ich argumentiere doch gar nicht für XML. Ich stimme Ihnen auch zu, dass JSON eher einfacher ist als XML (z. B. wegen der fehlenden schließenden Tags). Ich wollte das nur nochmal ausdrücklich festhalten, weil es gegenüber den Anforderungen und dem Vertrag doch eine wesentliche Änderung darstellt. Ansonsten glaube ich auch, dass die Zukunft eher JSON gehört – man muss sich halt einmal darin einarbeiten und eindenken und dann kann man flott mir arbeiten, das ist unstrittig.
Da es aber aus meiner vorherigen Antwort nicht eindeutig hervorgeht: Der Verwendung von JSON als Format für die Konfigurationsdatei wird zugestimmt.
Kommentare sollten möglichst aufgehoben werden. Die Intention ist, Kommentare für temporär ausge-schlossene Teile, z.b. Argumente einer Inkarnation zu verwenden, um ein „Backup“ zu halten.
Unser Vorschlag wäre, diesen Anwendungsfall durch verschiedene Makros zu lösen, d.h. der Standard-parameterwert ist in einem Makro abgelegt, im Testbetrieb kann das Makro durch den neuen Parameter (der seinerseits wieder ein Makro sein könnte) ersetzt werden. Die Einstellungen des Produktivsystems könnten dann einfach durch Ersatz des Makros wiederhergestellt werden.
Eventuell wäre es hilfreich die Definition der Makros in der Konfigurationsdatei (DTD) um ein Attribut „beschreibung“ zu erweitern, dann wären die Makros dokumentiert und diese „Dokumentation“ könnte auch definiert durch die Bedeinoberfläche ausgelesen und angezeigt/editiert werden
Ist die Speicherung der StartStopp-Konfiguration als XML-Datei unverzichtbar?
Für eine Kommunikationsschnittstelle, die eventuell auch in Webapplikationen verwendet werden soll, würde man vermutlich JSON-Objekte verwenden, da diese ohne weitere Konvertierung in JavaScript verwendbar wäre.
Es würde sich daher anbieten, auch die Konfiguration als JSON-Datei abzulegen, dann muss nur eine Konvertierung ungesetzt und gepflegt werden.
Die Speicherung im XML-Format ist nicht unverzichtbar. Allerdings ist der Einsatz in Web-Applikationen auch relativ vage.
Wenn JSON verwendet wird, muss das natürlich auch von dem Konverter unterstützt werden, vermutlicht sogar expliziter als bisher. Also tatsächlich eine Konvertierung von XML nach JSON und nicht nur implizit im alten Format einlesen und im neuen speichern.
Außerdem muss dann die Bearbeitung der Konfiguration über die Benutzeroberfläche (ggf. noch stärker) in den Fokus gerückt werden. Ziel ist es dann, die Bearbeitung nahezu ausschließlich über die GUI zu machen und den externen Texteditor als den (seltenen) Ausnahmefall zu lassen. Und es wäre dann natürlich sehr hilfreich, einfache Beispielkonfigurationen bei der Auslieferung beizulegen.
Wir können das gerne in beiden Versionen betrachten, die Argumentation für XML kann ich trotzdem nicht ganz nachvollziehen.
Eine JSON-Datei zu bearbeiten ist nicht komplizierter als eine XML-Datei. Ich meine sogar im Gegenteil 😉
Beispiel in vorläufiger Version:
https://github.com/bitctrl/de.bsvrz.sys.startstopp/blob/develop/startstopp_sample.json
Die Beschreibung erfolgt per JSON-Schema (entsprechend DTD, was eigentlich besser auch XML-Schema sein sollte).
https://github.com/bitctrl/de.bsvrz.sys.startstopp/blob/develop/src/main/resources/startstoppkonfiguration.schema.json
Ich argumentiere doch gar nicht für XML. Ich stimme Ihnen auch zu, dass JSON eher einfacher ist als XML (z. B. wegen der fehlenden schließenden Tags). Ich wollte das nur nochmal ausdrücklich festhalten, weil es gegenüber den Anforderungen und dem Vertrag doch eine wesentliche Änderung darstellt. Ansonsten glaube ich auch, dass die Zukunft eher JSON gehört – man muss sich halt einmal darin einarbeiten und eindenken und dann kann man flott mir arbeiten, das ist unstrittig.
Da es aber aus meiner vorherigen Antwort nicht eindeutig hervorgeht: Der Verwendung von JSON als Format für die Konfigurationsdatei wird zugestimmt.
Gemäß Absprache müssen Kommentare nicht gesichert/übernommen werden.
Kommentare sollten möglichst aufgehoben werden. Die Intention ist, Kommentare für temporär ausge-schlossene Teile, z.b. Argumente einer Inkarnation zu verwenden, um ein „Backup“ zu halten.
Unser Vorschlag wäre, diesen Anwendungsfall durch verschiedene Makros zu lösen, d.h. der Standard-parameterwert ist in einem Makro abgelegt, im Testbetrieb kann das Makro durch den neuen Parameter (der seinerseits wieder ein Makro sein könnte) ersetzt werden. Die Einstellungen des Produktivsystems könnten dann einfach durch Ersatz des Makros wiederhergestellt werden.
Eventuell wäre es hilfreich die Definition der Makros in der Konfigurationsdatei (DTD) um ein Attribut „beschreibung“ zu erweitern, dann wären die Makros dokumentiert und diese „Dokumentation“ könnte auch definiert durch die Bedeinoberfläche ausgelesen und angezeigt/editiert werden