29.10.2014, 22:06
Hallo,
ich melde mich mal mit einem Zwischenstand.
Das Konzept im Groben
Erzeugung der Vorbelegung
1) Vorbelegung der notwendigen Parameter mit programminternen Defaults, soweit möglich.
2) Falls eine gridspezifische Konfigurations-XML geladen wird, überschreibt diese die Vorbelegung aus dem ersten Schritt.
3) Falls Ini-Dateien gefunden werden, gibt es zwei Möglichkeiten. Entweder ignorieren, oder "mergen". Beim Mergen werden die gesperrten Einstellungen (s.u.) aus Schritt 2 übernommen, während für änderbare Einstellungen die eigenen Ini-Dateien hergenommen werden.
Anpassung ans Grid
In den gridspezifischen Konfigurations-XML Dateien kann jeder Wert einzeln gesperrt werden, dann kann er in der Bedienoberfläche nicht geändert werden. Dies empfiehlt sich zum Beispiel für die Webadressen des Grids. Nur später in der Lasche "Advanced" denke ich an einen Haken, mit dem man die Sperre dort (und nur dort) entriegeln kann.
Eingaben durch die Benutzer
Alle notwendigen Felder, die bisher noch nicht gefüllt wurden, sind farbig markiert und müssen manuell befüllt werden. Anderenfalls können die neuen Ini-Dateien nicht generiert werden. Alle änderbaren Felder können verändert werden. Die gesperrten Felder können in der normalen Bedienoberfläche nicht verändert werden. Profis können beliebige Parameter weiterhin direkt in den Ini-Dateien ändern, und später ihre Änderungen durch "mergen" (s.o.) übernehmen.
Auf der "Optional-Seite" wird man nur jenen OSSL Funktionen Berechtigungen zuordnen können, die in der Arriba noch als individuell konfigurierbar übrig geblieben sind. Ein generelles Hochschalten des Threat-Levels ist nicht vorgesehen (viel zu gefährlich), und alle über 100 Funktionen einzeln einstellbar machen würde jede Bedienoberfläche überladen.
Später mal wird es auf der "Advanced-Seite" möglich sein, beliebige Werte zu verstellen. Dies dann aber ohne Gegenprüfung auf den Sinngehalt, wer einen Parameter "BlaBlubb = 1234" erfindet, bekommt den in die Ini geblasen. (Größere Mengen von Spezialeinstellungen wird man aber eh besser direkt in den Ini-Dateien machen.)
Priorisierung
- Im ersten Wurf wird nur eine Region konfigurierbar sein. Sind mehrere Regionen in der Regions.ini, dann ist die erste konfigurierbar.
- Im ersten Wurf wird das Tool noch nicht selber auf dem Rechner nach vorhandenen Datenbanken suchen.
- Remotebetrieb wird erst implementiert, wenn der Lokalbetrieb funktional ist.
- Standalones werden erst berücksichtigt, wenn das Programm für Grids funktional ist (einschließlich remote).
--------------------------------------------
Bereits implementiert
- Interne Datenhaltung der Konfigurationsparameter
- Operationen auf den Parametern: Hinzufügen, löschen, ändern, sperren, Vermeidung von "Doppelten", ...
- Laden der Konfigurations-XML
- Zwei Beispiel-XML (Metropolis Vanilla und Metropolis Arriba)
- Laden der Ini-Dateien
- Priorisierung nach Anwenderwunsch einschließlich "Mergen"
- Einfaches Popup für Fehlermeldungen bei fehlgeschlagenem Syntaxcheck und Konfigurationshinweise
- Ein paar wenige Eingabefelder
- Mehrsprachigkeit über separate Ressourcendateien
Zeitplan
- Den ersten Wurf möchte ich spätestens am Ende der Weihnachtsferien veröffentlichen.
Liebe Grüße,
Mareta
ich melde mich mal mit einem Zwischenstand.
Das Konzept im Groben
Erzeugung der Vorbelegung
1) Vorbelegung der notwendigen Parameter mit programminternen Defaults, soweit möglich.
2) Falls eine gridspezifische Konfigurations-XML geladen wird, überschreibt diese die Vorbelegung aus dem ersten Schritt.
3) Falls Ini-Dateien gefunden werden, gibt es zwei Möglichkeiten. Entweder ignorieren, oder "mergen". Beim Mergen werden die gesperrten Einstellungen (s.u.) aus Schritt 2 übernommen, während für änderbare Einstellungen die eigenen Ini-Dateien hergenommen werden.
Anpassung ans Grid
In den gridspezifischen Konfigurations-XML Dateien kann jeder Wert einzeln gesperrt werden, dann kann er in der Bedienoberfläche nicht geändert werden. Dies empfiehlt sich zum Beispiel für die Webadressen des Grids. Nur später in der Lasche "Advanced" denke ich an einen Haken, mit dem man die Sperre dort (und nur dort) entriegeln kann.
Eingaben durch die Benutzer
Alle notwendigen Felder, die bisher noch nicht gefüllt wurden, sind farbig markiert und müssen manuell befüllt werden. Anderenfalls können die neuen Ini-Dateien nicht generiert werden. Alle änderbaren Felder können verändert werden. Die gesperrten Felder können in der normalen Bedienoberfläche nicht verändert werden. Profis können beliebige Parameter weiterhin direkt in den Ini-Dateien ändern, und später ihre Änderungen durch "mergen" (s.o.) übernehmen.
Auf der "Optional-Seite" wird man nur jenen OSSL Funktionen Berechtigungen zuordnen können, die in der Arriba noch als individuell konfigurierbar übrig geblieben sind. Ein generelles Hochschalten des Threat-Levels ist nicht vorgesehen (viel zu gefährlich), und alle über 100 Funktionen einzeln einstellbar machen würde jede Bedienoberfläche überladen.
Später mal wird es auf der "Advanced-Seite" möglich sein, beliebige Werte zu verstellen. Dies dann aber ohne Gegenprüfung auf den Sinngehalt, wer einen Parameter "BlaBlubb = 1234" erfindet, bekommt den in die Ini geblasen. (Größere Mengen von Spezialeinstellungen wird man aber eh besser direkt in den Ini-Dateien machen.)
Priorisierung
- Im ersten Wurf wird nur eine Region konfigurierbar sein. Sind mehrere Regionen in der Regions.ini, dann ist die erste konfigurierbar.
- Im ersten Wurf wird das Tool noch nicht selber auf dem Rechner nach vorhandenen Datenbanken suchen.
- Remotebetrieb wird erst implementiert, wenn der Lokalbetrieb funktional ist.
- Standalones werden erst berücksichtigt, wenn das Programm für Grids funktional ist (einschließlich remote).
--------------------------------------------
Bereits implementiert
- Interne Datenhaltung der Konfigurationsparameter
- Operationen auf den Parametern: Hinzufügen, löschen, ändern, sperren, Vermeidung von "Doppelten", ...
- Laden der Konfigurations-XML
- Zwei Beispiel-XML (Metropolis Vanilla und Metropolis Arriba)
- Laden der Ini-Dateien
- Priorisierung nach Anwenderwunsch einschließlich "Mergen"
- Einfaches Popup für Fehlermeldungen bei fehlgeschlagenem Syntaxcheck und Konfigurationshinweise
- Ein paar wenige Eingabefelder
- Mehrsprachigkeit über separate Ressourcendateien
Zeitplan
- Den ersten Wurf möchte ich spätestens am Ende der Weihnachtsferien veröffentlichen.
Liebe Grüße,
Mareta
