Wie verwaltet Ihr Anwendungseinstellungen?

[scrat1979]

Hallo zusammen,

ich habe mal eine kleine Frage, bevor ich mir zu viel Arbeit mache. Ich habe - wie die meisten hier :) - ein Programm geschrieben. Nun möchte ich einige Dinge den Benutzer einstellen lassen (e-Mail Adresse, Farben [nicht die GUI, sondern Markierungen in einem Grid], sonstige Dinge).

Meine generelle Frage wäre, wie löst ihr das - also mit dem Programmeinstellungen? ich würde mir eine Klasse TAppSettings o.ä. schreiben und hier die ganzen Einstellungen verwalten. Natürlich würde auch die Klasse das Speichern (Registry oder INI oder wo auch immer) übernehmen. Generell muss ich sagen, scheint es doch einiges an Aufwand zu sein (bei ca. 20-30 Einstellungen lokale Variable, Getter, Setter und property...), deshalb die Frage ob Ihr das auch bei Euch so löst bzw. lösen würdet! WO man die Einstellungen dann speichert, soll erst einmal sekundär sein. Da gehen die Meinungen ja sehr auseinander :P

Für Vorschläge Besten Dank!

[SirThornberry]

Ich mache es ebenso. Getter und Setter brauchst du gar nicht. Denn eigentlich legt man einfach nur die Daten in der Klasse ab und ruft zu geeigneter Zeit LoadFromFile/LoadFromStream/... etc. auf.

[Sherlock]

Wir speichern Anwendungseinstellungen an unterschiedlichen Stellen. Die gute alte Ini-Datei ist eigentlich immer noch hervorragend für anwenderspezifische Dinge geeignet (im korrekten Pfad natürlich). Einstelungen, die den gesamten Standort betreffen werden in der Datenbank abgelegt.

Das ganze wird in einen "Konfigurationsobjekt" verwaltet, wo die jeweiligen Getter und Setter mit der Zeit dazugekommen sind. Ist aufwändig aber sauber.

Registryeinträge vermeide ich bewusst. Den Sumpf tu ich mir nicht an. Am Ende vergess ich noch was da wieder rauszulöschen, und reihe mich in die lange Liste der peinlichen Entwickler ein, die die mit Unsinn zumüllen.

Sherlock

[Daniel]

Ich nutze üblicherweise auch ein spezielles Config-Objekt dafür.
Ich finde das mit den Settern gar nicht so schlecht, denn dann kann sicher sein, dass auch neue Parameter immer noch mal kurz auf ihre Gültigkeit hin geprüft werden. Und unter Umständen gibt es ja bei Änderungen irgendwen zu benachrichtigen.

[stahli]

Ich würde für solche Dinge auch Ini´s nutzen.

[Nersgatt]

Wir nutzen momentan auch eine Ini. Allerdings ist mittelfristig geplant, einige Einstellungen in der Datenbank zu speichern, die unsere Anwendung sowieso benutzt. Da wir eine eigene Userverwaltung in unsere Software haben, ist es doch toll, wenn alle Einstellungen des Users vorhanden sind, egal an welchem PC er sich an der Anwendung anmeldet. Da wollen wir hin.
Natürlich kann man das nicht mit allen Einstellungen machen. Einige sind auch vom PC abhängig. z.B. benutzen einige Programmteile Barcodescanner. Es muss eingestellt werden an welchen COM-Port der Scanner hängt. Das muss man natürlich weiterhin auf dem Arbeitsplatz speichern.

[generic]

-da hat sich das Internet verschluckt.

[generic]

Lustig, über das Thema schreibe ich gerade einen Artikel.

Gibt verschiedene Ansätze:
* Struktur-Dateien
* Textdateien im Key/Value Prinzip
* Ini-Dateien
* DFM-Prinzip (automatische Serialisierung)
* XML-Dateien
* Registry

Alle haben ihre Vor- und Nachteile.
Meine Programme haben bist jetzt die Registry genutzt.
Die nächsten Programme werden wohl XML-Dateien im Benutzerprofil speichern.

Über die RTTI speichern und laden sich meine Objekte selbstständig.

[Nersgatt]

Hallo Bernd,

wo wird der Artikel denn zu lesen sein?

[joachimd]

Zitat:

Zitat von generic (Beitrag 1077936)

Die nächsten Programme werden wohl XML-Dateien im Benutzerprofil speichern.

Da ich gerade exzessiv mit JSON rumhantiere: das Format ist weitaus einfacher als XML und es gibt eine Komponente namens SuperObject (http://www.progdigy.com), die die Verarbeitung mehr als einfach erledigt. Ein einfaches

Delphi-Quellcode:

SO(json_text)

liefert eine Instanz basierend auf der JSON-Repräsentation,

Delphi-Quellcode:

so_instanz.AsString

liefert die JSON-Repräsentation der Objekt-Hierarchie.
Für mich in Zukunft das Mittel zum Speichern komplexer Objekt-Bäume.

[turboPASCAL]

Um die Einstellungen in den Programmen zu Verwalten nutze ich in der VCL sowie auch in der nonVCL eine Klasse in
Verbindung mit einem Record oder eben nur einen Record. Es ist imho immer die Frage wie viele Daten man speichern
möchte, ob die Angelegenheit erweiterbar gestaltet werden soll und oder ob die gespeicherten Daten manuell
bearbeitbar sein soll.

Ich verwende gern Ini-Dateien, der Vorteil ist das man seine Programme dadurch leicht portabel bekommt.
Manchmal nutze ich auch gern eigene binäre Konfigurationsdateien in denen ich einfach einen Rekord abspeichere.
Die kleinste Konfig.-datei ist gerade mal ein Byte gross mit acht enthaltenen Infos. :stupid:
Registry kommt für mich nur in Frage, wenn man auf Systemdaten zugreifen will oder seine Daten bzw.
Einstellungen global auf dem Windowssystem verfügbar machen möchte.
XML und der gleichen nutze ich hingegen ungern bzw. sogut wie nie da mir der Aufwand zu gross und meine Programme
zu klein dafür sind.

[mirage228]

Zitat:

Zitat von generic (Beitrag 1077936)

Über die RTTI speichern und laden sich meine Objekte selbstständig.

Genau so mache ich es auch ;)

Ich habe alle meine Einstellungen in einem oder mehreren Objekten. Beim Speichern und Laden werden sie bei meinen meisten Programmen in/aus ein(em) XML-Dokument serialisiert. Der Vorteil ist, dass ich mich nicht selbst um das Speichern neuer Attribute kümmern muss.

Viele Grüße

[Assarbad]

Registry und INI-Datei. Ansonsten (aber eher selten) auch mal hier und da ne Datenbank (bspw. SQLite).

Noch was für ganz clevere: Lua kann man, wie schon bei FarCry gesehen, auch als Konfigurationsdateien mißbrauchen.

[scrat1979]

Vielen Dank für die zahlreichen Antworten. Dann werde ich dann wohl die Mühe auf mich nehmen und das ganze in einem Objekt kapseln. Ist zwar aufwendig aber - wie bereits angemerkt - sauber und erweiterbar.

Da die Frage zum Topic passt: Wo speiche ich eigentlich Konfigurationsdateien (z.B. INI) jetzt ab? Es gibt ja da verschiedene Aussagen.

[SirThornberry]

Ich glaube hier ging es gar nicht so darum wo die Daten letztendlich abgelegt werden als vielmehr ob man sich die Arbeit macht über ein Objekt darauf zu zugreifen.
Ich bevorzuge den Zugriff über ein Objekt weil man dann wirklich nur die Laden- und Speichern-Methode ändern muss wenn sich der Ablageort/-Typ für die Daten ändern soll.

[Aphton]

Zitat:

Zitat von scrat1979 (Beitrag 1077916)

(bei ca. 20-30 Einstellungen lokale Variable, Getter, Setter und property...)

Ein Datensatzregistrierungssystem mit "Textdateien im Key/Value Prinzip" (wie von Generic beschrieben) wäre meines Erachtens nach optimal!
Dadurch wäre das Ganze um einen Klacks abstrakter und könnte nun bei anderen Projekten verwendet werden!

[himitsu]

Zitat:

Zitat von turboPASCAL (Beitrag 1077949)

Die kleinste Konfig.-datei ist gerade mal ein Byte gross mit acht enthaltenen Infos. :stupid:

Ob nun 1 Byte oder 8 KB ist doch egal.

Ein Cluster ist heutzutage wohl schonmal durchschnittlich 4 KB bis zu 64 KB und eine Datei belegt immer ein Mehrfaches an ganzen Clustern. :stupid:

PS: XML gegenüber INI ist kein großer Unterschied ... es sind etwa die selbe Anzahl an Befehlen.

[mleyen]

Bei überschaubaren Progrämmchen haben meine einstellbaren Klassen oft eine Load/-SaveSettingsToStream()-Methode.
Bei größeren, oftmals eigene Settings-Klassen.

Wo?
Privat: Zu 80% in der Exe selber.
Ansonsten: Als Binärfile oder ini in %appdata%
Registry vermeid ich auch wo es geht.

[generic]

Zitat:

Zitat von Nersgatt (Beitrag 1077937)

Hallo Bernd,

wo wird der Artikel denn zu lesen sein?

Der Artikel wird voraussichtlich im
Entwickler Magazin 4.2011 Seite 68 ff.
erscheinen.

Einstellungssache - Anwendungsdaten und Einstellungen laden, verarbeiten und speichern

[jaenicke]

Ich habe zu dem Zweck eine fertige Lösung vorbereitet. Die sucht automatisch an den möglichen Stellen in der richtigen Reihenfolge und erlaubt es so dem Benutzer anzugeben wo die Einstellungen liegen sollen. Zudem kann man eine portable Version unabhängig von einer installierten Version einfach mal auf dem selben Rechner starten usw.

Du findest die Units plus Demo hier:
http://www.delphipraxis.net/917904-post.html
Sowie eine Erklärung zu den Hintergründen hier:
http://www.delphi-library.de/viewtopic.php?p=541637

[blackfin]

Mhm, ich fahre bei solchen Sachen meistens 4-gleisig, je nach Anwendung :-D

1) Der Installer (und zwar nur der Installer) schreibt den Installationspfad in die Registry. Das hilft beim leichteren Auffinden des Programms für einen Updater oder bei einem Support-Anruf, wenn der Kunde keine Ahnung hat, wo das Pogramm eigentlich liegt und / oder sein Icon / die Programmgruppe gelöscht hat etc. :-D

2) "Normale" Programm-Einstellungen liegen in einer kleinen embedded Firebird-Datenbank (Anm.: ich liebe diese Datenbank!) im AppData-Verzeichnis und können vom User im Programm selbst über einen Settings-Bildschirm geändert werden.
Ebenso liegen in der Datenbank interne Einstellungen, die nur der Entwickler selbst, das Installationsprogramm oder ein Updater ändern muss.

3) Erweiterte Programm-Einstellungen für den Benutzer, die man teilweise nur zu Endpoint-Debug-Zwecken braucht oder vom End-Anwender nur einmalig umgeändert werden müssen, liegen in einer kleinen INI-Datei im AppData-Verzeichnis der Applikation.

4) Hat die Applikation eine Lua-Schnittstelle, liegen die Config-Einstellungen auch teilweise in einem Lua-Table.

Generell bin ich auch, aufgrund der Einfachheit, ein Freund der guten alten INI-Datei, XML hin oder her. INI's kann jeder Endanwender im Support-Fall leicht selbst editieren und muss sich nicht durch irgendwelche Registry-Einträge hangeln. Wichtig ist hier nur, dass die INI-Datei nicht mehr, wie es bei vielen jahrelang usus war, im Programm-Verzeichnis liegt, sondern im zugehörigen AppData-Verzeichnis. Hier hilft es auch, eine Verknüpfung zur INI-Datei mit dem Installationsprogramm im eigentlichen Applikations-Verzeichnis anzulegen, damit der Endanwender sich wiederum nicht zu den AppData-Verzeichnissen hangeln muss.
Ausserdem ein Vorteil von INIs (und auch XMLs): Man kann durch schlichtes Löschen der INI-Datei das Programm so auch leicht auf "Factory Reset" setzen, falls ein Endanwender es irgendwie geschafft hat, irgendwelche Form-Grössen oder Positionen völlig zu zerschiessen etc. und auch nicht editieren will :-D

XML ist zwar generell die "schönere" und modernere Variante der INI, aber ich habe es schon oft erlebt, dass ein Endkunde die XML mit einem schwindligen Editor geöffnet und editiert hat, der dann die UTF8-Kodierung der XML beim speichern komplett zerstört hat.
Deswegen nutze ich XML meist nur für interne Zwecke, Import / Export und dergleichen. Aber nie für Dinge, die der Endanwender auch mal mit einem Editor ändern muss.

[Zuck]

Zitat:

Zitat von joachimd (Beitrag 1077941)

Zitat:

Zitat von generic (Beitrag 1077936)

Die nächsten Programme werden wohl XML-Dateien im Benutzerprofil speichern.

Da ich gerade exzessiv mit JSON rumhantiere: das Format ist weitaus einfacher als XML und es gibt eine Komponente namens SuperObject (http://www.progdigy.com), die die Verarbeitung mehr als einfach erledigt. Ein einfaches

Delphi-Quellcode:

SO(json_text)

liefert eine Instanz basierend auf der JSON-Repräsentation,

Delphi-Quellcode:

so_instanz.AsString

liefert die JSON-Repräsentation der Objekt-Hierarchie.
Für mich in Zukunft das Mittel zum Speichern komplexer Objekt-Bäume.

So mache ich das auch. Ich find JSON genial. Man kann jede noch so komplexe Objektstruktur darstellen, was ja bei INI nicht möglich ist und bei XML doch bald mal in den Speicher gehen kann. Zusätzlich ist es mit JSON extrem leicht möglich, Einstellungen aus dem Internet zu laden (wir speichern einige Einstellungen auf unserem Firmenserver und einige Kunden haben doch noch recht langsame Verbindungen, bei denen jedes Byte Zeit kostet).

SuperObject muss ich mir mal anschauen - wir haben dafür mal was eigenes entwickelt, aber die Produkte von progdigy sind doch immer wieder ein Grund zur Freude.

Zuck

[himitsu]

Seit mindestens Delphi XE gibt es direkt im Delphi eine JSON-Implementierung,
aber gegen diese kranke Implementierung ist MSXML wesentlich einfacher
Uúnd über XPath auch wesentlich mächtiger.

[jaenicke]

JSON hat den Vorteil, dass es z.B. auch bei DataSnap verwendet wird. Man kann also die selben Daten auch gleich bei der Multi-Tier Entwicklung nutzen. Zum Beispiel, wenn man die selben Einstellungen z.B. auch an einen Thin-Client (z.B. mit JavaScript) schicken will.

Für rein lokal im Delphiprogramm benutzte Einstellungen ist XML aber besser geeignet, da bin ich der selben Meinung.

[Zuck]

Ja auf Windows alleine ohne Netzwerk ist XML sicher eine bessere Alternative. Einige Programme sind immer noch auf rein XML - aber wie gesagt, für die Kommunikation mit einem Webserver ist JSON IMHO allemal die bessere Wahl.

Zuck