Der SNCA-Editor [SNCAed]


#1

Aktuell muss jegliches Customizing durch Editieren der Datein SNCA.xml, snca-messages.properties und snca-messages_de.properties in einem (XML-)Editor erfolgen, was komplex und fehleranfällig ist.
Dies soll durch einen Editor vereinfacht werden, der:

  • Alle Optionen in einer graphischen Oberfläche zur Bearbeitung zur Verfügung stellt.
  • Die jeweilige Eingaben validiert und automatisch die korrekten Dateien erzeugt.
  • Die Übersetzungen für die Sprachdateien (snca-messages.properties, snca-messages_de.properties und weitere) mit speichert.
  • Die verinice Standardwerte und kundenspezifische Anpassungen in getrennte Dateien schreibt.

Das Laden der Dateien beim Starten von verinice wird dazu ebenfalls angepasst. Zuerst werden die Dateien mit den verinice Standardwerten geladen, danach die Dateien mit kundenspezifischen Erweiterungen, so dass aus beiden die gewünschten Properties/Felder generiert werden.

Vorteile:

  • Das Customizing wird deutlich vereinfacht.
  • Fehler werden vermieden.
  • Bei Updates ist kein zusätzlicher Abgleich der Anpassungen erforderlich.

#2

Hallo Herr Flürenbrock,

danke für den interessanten Gedanken / Ausblick.
Ich freue mich auf die ersten Einblicke in das neue Konzept, möchte vorab jedoch die eine oder andere Frage loswerden:

  1. Wenn man in grafischer Verarbeitung die Elemente zusammenklicken können soll, könnte der Aufwand ebenso komplex werden, wie die GUI-Builder diverser Entwicklungsumgebungen zum Erzeugen der SWT-Elemente. Am Ende müssen auch hier die Nutzer ewig viele Klicks durchführen, um Bezeichnung, Wertebereich, Typ und Verhalten des Grafik-Elementes den Vorstellungen entsprechend zu konfigurieren. Man nehme bspw. ein Single-Select, gebe dem einen Namen, muss die Feld-Werte konfigurieren, ggf. auch die Anzeigenamen anpassen (“sehr hoch” = 3), es ggf. in eine Gruppe packen, Abhängigkeiten von anderen Felder definieren und schließlich das Element an die richtige Stelle verschieben.
    Das Gleiche schafft ein versierter Nutzer in 4 Zeilen XML-Code (den er tlw. sogar von bestehenden Elementen kopieren kann).
    Wird hier tatsächlich auf ein Zeitgewinn / Komplexitätsverlust abgezielt?

  2. Interessant bleibt für mich auch, ob wieder ein Zusatzprodukt (wie der vDesigner) verwendet wird, oder die Plug-In-Architektur des Eclipse-Frameworks zum Tragen kommt. Vorstellbar wäre ein integrierter XML-Editor als Plug-In mit angenehmen High-Lighting als Extra-View/-Part. Das sollte es in Massen für Eclipse geben und auch hier kompatibel sein. Ggf. erweiterbar um eine Anzeige, wie das aktuell selektierte Element als GUI-Element aussehen wird…

  3. Die Reihenfolge des Ladens finde ich im ersten Ansatz recht angenehm, zumindest wenn man lediglich Elemente hinzufügt. Wird so auch das Modifizieren und sogar Löschen von vorgegebenen Elementen möglich sein?

  4. Derzeit ist für mich das Anpassen der SNCA.xml und der Properties viel leichter in Git (https://about.gitlab.com/) zu realisieren. Ein simpler 3-Wege-Merge kann jedem Nutzer ans Herz gelegt werden.
    Eingebaut ist somit auch Versionierung, Mehr-User-Anwendbarkeit und automatisches Vergleichen. Ich fürchte, diese Features mit dem neuen Editor zu verlieren. Ist andernfalls ein adaptieren dieser Konzepte seitens SerNet denkbar?

Vielen Dank vorab.


#3

Hallo Member123,

vielen Dank für die Anregungen, die ich gerne kommentiere:

ad 2. Wir bleiben im Eclipse-Framework und unterstützen weitestgehend die Funktionalität wie von Ihnen dargestellt. Ich hänge in Kürze noch mal einen Screenshot an…

ad 3. Korrekt, und auch hier war ich nicht ganz präzise. verinice lädt:

  • die Original SNCA
  • die Datei mit Kundenseitig gelöschten Properties
  • die Datei mit Kundenseitig hinzugefügten Properties
    Geänderte Proeprties werden dabei praktisch erst einmal gelöscht und dann neu geladen.
    So ist die Planung, die konkrete Umsetzung werden wir natürlich noch weiter spezifizieren und testen.

ad 1. Die Möglichkeit einen Editor zu nutzen, beschränkt nicht die direkt Bearbeitung im XML-Code. Ich denke beide Möglichkeiten haben Ihre Berechtigung nebeneinander. Sei es für weniger versierte/versierte AnwenderInnen, sei es wegen des Kopierens längerer Abschnitte o.ä.

ad 4. Prima wenn Sie mit dem Merge über Git gut arbeiten können. Ich kann mir vorstellen, dass auch einige andere AnwenderInnen interessiert an Ihrer Vorgehensweise sind. Mich persönlich würde ein simpler 3-Wege-Merge auf Git zugegebener Maßen überfordern :wink: Ich denke so geht es auch anderen, weshalb ich beide Lösungen anbieten möchte.

MfG Michael Flürenbrock