Vorgehensweise beim Laden und Speichern von Programmeinstellungen | Benutzerabhängig

[Headbucket]

Hallo miteinander,

ich habe ein paar allgemeine Fragen zur Vorgehensweise beim Laden und Speichern von Programmeinstellungen. Die Thematik scheint simpel, doch ich zerbreche mir schon eine ganze Weile den Kopf darüber und hoffe nun frischen Input zu erhalten .

Bisherige Vorgehensweise

Zur Zeit speichere ich meine Daten auf 3 verschiedene Art und Weisen:

• INI-Dateien | Recht selten geworden, aber es soll dem Benutzer möglich sein manche Einstellungen selbst zu ändern, welche nicht unbedingt über Dialoge im Programm zu ändern sind.
• XML-Dateien | Komplexere Speicherstrukturen, welche nicht vom Benutzer geändert werden sollen. Es soll jedoch trotzdem möglich sein mal etwas "nachzuschauen".
• SQLite-Dateien | Alle sonstigen "unwichtigen" Einstellungen, die man in der Oberfläche verändern kann (Farbeinstellungen, usw). Außerdem verschiedene Texte usw.

Von jedem Dateityp gibt es mehrere Dateien. Jede Datei steht dann für eine bestimmte Thematik. Die Einstellungen werden übrigens im Programm immer genau dann geladen, wenn sie benötigt werden. So werden Sie z.B. einmal im Einstellungsdialog geladen, wo ich auch einige Einstellungen verändern kann. Werden die Einstellungen dann im späteren Programm benötigt, dann werde sie auch nochmal geladen. So kann es natürlich vorkommen, dass ich Einstellungen mehrmals lade.

Wünsche

Nun habe ich zwei große Wünsche, welche sich mit meiner bisherigen Vorgehensweise wohl nicht so ganz umsetzen lassen:

(1) Ich möchte verschiedene Einstellungen benutzerabhängig machen. So soll es z.B. neben den globale Einstellungen, welche zuerst geladen werden, auch benutzerabhängige Einstellungen geben, welche ggf. die globalen Einstellungen überschreiben (ähnlich Linux- oder GIT-Konfigurationsdateien).

(2) Mein Programm gibt nach der Ausführung eine Ergebnisdatei aus (XML-Datei). Hier möchte ich gerne alle Programmeinstellungen mitspeichern. Das mag jetzt erstmal etwas übermütig klingen, macht für meinen Anwendungsfall aber durchaus Sinn.

Lösungsfindung

Beide Wünsche würden sich einigermaßen leicht umsetzen lassen, wenn ich wirklich nur EINE Konfigurationsdatei habe. Diese wird dann in meinem Programm am Anfang global geladen (zunächst mit den globalen Einstellungen und danach mit den benutzerabhängigen). Dann müsste ich aber erstens alle Einstellungen in eine Datei packen (sehr unübersichtlich) und außerdem müsste ich alle Einstellungen am Anfang global laden - anderenfalls wird es wohl komplizierter umsetzbar.

Mich würden deshalb mal eure Konzepte zum Laden und Speichern von Einstellungen interessieren. Wie speichert ihr? Habt ihr auch benutzerabhängige Einstellungen? Und wie ist dann eure Handhabung im Delphi? Habt ihr für Konfigurationseinstellungen vllt sogar extra Klassen in extra Units?
Leider habe ich zu diesem Thema auch kaum Literatur im Internet gefunden. Vllt habe ich aber auch einfach nach den falschen Begriffen gesucht.

Wahrscheinlich wird es auf eine oder mehrere Units hinauslaufen, welche verschiedene Klassen implementieren, wo die Einstellungen gelesen und geschrieben werden können. Hier stellt sich mir dann aber direkt die Frage, ob man solche Klassen dann global erstellt oder doch lieber nur bei Bedarf. Dann kann es natürlich vorkommen, dass ich große Klassen mehrmals erzeugen muss.

Vielen Dank fürs durchlesen und die Hilfe!

Grüße
Headbucket

[haentschman]

Hallöle...

Zitat:

Habt ihr für Konfigurationseinstellungen vllt sogar extra Klassen in extra Units?

...du sagst es.

Vorher eine Frage an dich... (nicht böse gemeint ) Sagen dir die Begriffe Vererbung etwas? Wenn nicht, solltest du damit anfangen.

Wenn du das innerlicht hast, dann kann man die komplexeren Fragen beantworten.

Beispiel:
1. Klasse aus verschiedenen Basis Klassen abgeleitet.
2. z.B. aus verschieden INI laden.
3. Einstellungen die immer da sind (globale) und progammspezifische in einer Klasse

[dGeek]

Zitat von haentschman:

Beispiel:
1. Klasse aus verschiedenen Basis Klassen abgeleitet.
2. z.B. aus verschieden INI laden.
3. Einstellungen die immer da sind (globale) und progammspezifische in einer Klasse

Wieso so kompliziert mit Klassen und alle dem?

[DeddyH]

Wieso keine Interfaces? Dann ließe sich die Applikation recht einfach erweitern, ohne dass man auf der GUI-Ebene eine Zeile Code ändern müsste.

[haentschman]

Moin...

Aus verschieden Gründen:
1. eine Klasse kapselt den Code für eine AUFGABE
2. Erweiterung einer Klasse für die AUFGABE mit anderen OPTIONEN
3. Eine Klasse ist WIEDERVERWENDBAR
4. Klasse ist OOP ...

...usw.

Zitat:

Wieso keine Interfaces?

...ich glaube das das zu weit führt.

[dGeek]

Nur wo werden dann z.B. für eine ini-Datei die Sections und Idents übergeben?
Das ist dann doch außerhalb. Dann ist diese Klasse ja nix anderes als ein Wrapper?

Oder ich verstehe es nicht

[DeddyH]

Was interessiert es denn den "Speichernden", wie die eigentliche Speicherung implementiert ist? Der muss nix von Idents und Sections wissen, dafür ist die Speicherklasse zuständig.

[dGeek]

Zitat von DeddyH:

Was interessiert es denn den "Speichernden", wie die eigentliche Speicherung implementiert ist? Der muss nix von Idents und Sections wissen, dafür ist die Speicherklasse zuständig.

Das meinte ich nicht. Ich frage mich nur, wie die Klasse wiederverwendbar sein soll.
Denn wenn ich Sections und Idents doch eh außerhalb der Klasse "angebe" / von außerhalb der Klasse übergebe, wofür dann noch eine Klasse und all der Aufwand?

[DeddyH]

Von welcher Klasse redest Du jetzt?

[haentschman]

Zitat:

Nur wo werden dann z.B. für eine ini-Datei die Sections und Idents übergeben

Versuche dich zu lösen. Deinem Programm soll es es wurst sein WOHER z.B. die Hintergrundfarbe kommt. Ob aus einer INI oder aus Nachbars Garten. Das regelt die "Speicherklasse".
Wenn du eine INI verwendest dann mußt du auch den Code impementieren.