"Objekteditor" für INI-files

[MacWomble]

Ich mache mir eben Gedanken zu einem Editor für Ini-Dateien:

1. Aufbau wie der Objekteditor in Lazarus
2. Für jeden INI-Abschnitt einen eigenen TAB
3. Über externe Datei konfigurierbar (z.B. xml, inkl. der Angabe des Editors z.B. Directory, Number (Bereich), Auswahl versch. (String-)Werte etc)

Die Frage ist nun, ob es vielleicht so etwas bereits gibt. Alles was ich gefunden habe ist der ValueListEditor und das TTIPropertieGird, welche die Basis für das ganze darstellen könnten.
Eine Komponente hierfür wäre m.E. wirklich eine Bereicherung, aber ich habe leider noch keinerlei Erfahrung mit der Erstellung von Komponenten.

[mischi]

Werden ini-Dateien nicht zunehmend durch xml-Dateien ersetzt? Auch auf Windows und Linux?

[MacWomble]

Werden ini-Dateien nicht zunehmend durch xml-Dateien ersetzt? Auch auf Windows und Linux?

Das spielt nicht wirklich eine Rolle, sondern der 'Objekteditor', also dass man in seinen Projekten die Einstellungen einfach und flexibel editieren kann, ohne jedesmal alles von Null auf zu programmieren.

[theo]

Werden ini-Dateien nicht zunehmend durch xml-Dateien ersetzt? Auch auf Windows und Linux?

MMn eher JSON.

Ein JSON Editor ist bei Lazarus dabei (tools/jsonviewer).
Den kann man noch verbessern, aber das wäre mMn der richtige Weg.

[wp_xyz]

Ich mache mir eben Gedanken zu einem Editor für Ini-Dateien:

Ich weiß natürlich nicht, was genau in den ini-Dateien gespeichert ist. Bei mir sind es immer Programmeinstellungen, wie Fenstergrößen, selektierte Combobox-Einträge etc, also Einstellungen, die die Anwendung selbst speichert. Hier würde ich es soweit wie möglich vermeiden, dass der User selbst diese Einstellungen verändern kann - ok, ini ist eine Textdatei, aber ich würde ihm auf jeden Fall kein Tool zur Hand geben, mit dem er das einfach bewerkstelligen kann. Denn da tut sich eine Vielzahl neuer Fehlermöglichkeiten auf: Was, wenn für Combobox.ItemIndex ein Wert >= Combobox.Items.Count eingetragen wird? Was, wenn die Breite eines Fensters als negative Zahl erscheint? Usw. - Ich würde die Finger von einem Ini-Editor lassen.

[MacWomble]

Bei Mir sind es Pfade zu Dokumentenablage und DB-Einstellungen und versch. kleinere Sachen (Standardsteuersatz etc.), welche durchaus durchd en Nutzer einstellbar sein sollen. Alle andere Sachen liegen nicht im Nutzerzugriff und werden über die DB abgedeckt:

Code: Alles auswählen

 
[Pfade]
Dokumente=/Server/CTR-BOSS/Dokumente
Anbinden=/home/Dokumente/Anbinden
Scans=/home/Dokumente/Anbinden/Scans
Faxe=/home/Dokumente/Anbinden/Faxeingang
Email=/home/Dokumente/Anbinden/Posteingang
Anrufe=/home/Dokumente/Anbinden/Anrufe
Autovorlage=/Server/CTR-BOSS/Vorlagen
Reports=/Server/CTR-BOSS/Reports
DBBackup=/Backupserver/CTR-BOSS/DBB
Startordner=Sonstige
Temp=/home/CTR-BOSS/.Temp
MailTemp=/home/CTR-BOSS/TempMail
Beamail=/Server/CTR-BOSS/Dokumente/BEAMail
Einstellungen=/Server/CTR-BOSS/Data
 
[Tools]
Mutool=mutool draw
 
[Base]
Database=BOSS
Hostname=localhost
Port=3306
User=****************
Password=***********************
MaxBackup=5
NextBackup=4
BackupUser=Test
 
[GUI]
Startmodul=3
 
[Mail]
SubjectAkte=Kundenname -  Unterlagen zu Ihrem Vorgang
SubjectAuftrag=Kundenname - Unterlagen zu Ihrem Auftrag
 
[EigeneMails]
Mail=xxx@web.de
Mail=xxx@yyy.net
 
[Auftrag]
Steuersatz=1
Steuerart=2
Zahlungsbedingung=2
ZBProjekt=0
ZBAngebot=0
ZBLieferschein=0
ZBRechnung=3
ZBTeilrechnung=6
 

[marcov]

.INI lässt sich nicht beliebig Ebenen nesten. XML und DFM streaming können das schon.

Ich hatte das Problem auch einmal (etwa in 2000), und habe dan configfile geschrieben das das emuliert mit [[xx]] für die zweite Ebene usw. Aber das hatte noch immer Probleme. Nicht alle Konfigurationen sind möglich, und es ist nicht Standard.

[wp_xyz]

Bei Mir sind es Pfade zu Dokumentenablage und DB-Einstellungen und versch. kleinere Sachen (Standardsteuersatz etc.), welche durchaus durchd en Nutzer einstellbar sein sollen. Alle andere Sachen liegen nicht im Nutzerzugriff und werden über die DB abgedeckt:

Aber dafür muss der User doch nicht die ini-Datei editieren. Bei Editieren der gesamten ini-Datei würde er auch die in deinem Beispiel gezeigten Anmeldedaten zu Gesicht bekommen. Was, wenn der unbedarfte User da etwas ändert?

[MacWomble]

Die DB-Daten kämen da raus, so ist es aber derzeit noch. die Pfade und sonstigen Einstellungen sind nötig und werden auch noch deutlich erweitert in Zukunft.
Die Frage war nicht nach Sinn und Zweck von INI und/oder XML o.ä., sondern wie ob es nicht Sinn machen würde, einen Editor al Objekteditor für solche Zwecke zu haben, welcher eventuell über eine externe Datei gesteuert werden kann. So bräuchte man dann nicht jedesmal wenn man einen neuen Eintrag in die Konfig packt, das Programm noch zusätzlich im Bereich der Einstellungen anpacken und könnte auch Vorgaben für die Einstellungen mit geben.

Also nach dem Motto:

vorgabe.dat (Diese Datei wird vom Anwender nicht verändert!)

Pfade,Dokumentenpfad,Directory,./
Pfade,Startordner,String,Test
Abschnitt2,Name,Test

Erzeugt im Einstellen-Dialog:

Pfade | Abschnitt2 <== Tabs
Dokumente ./ ...
Startordner Test

und ruft den PropertyFileDirectory-Dialog auf, wenn man auf ... klickt.

datei.ini sieht dann so aus:
[Pfade]
Dokumente=./
Startordner=Test

[Abschnitt2]
Name=Test

Nachtrag:
Die vorgabe.dat macht Sinn, weil diese nicht auf jedem Rechner/System gleich ist und hier nicht unterschiedliche Programmversionen verwaltet werden sollen!

Die INI-Datei reicht vollkommen aus, eine XMl oder json wäre oversized, da man nur zwei Ebenen benötigt (Abschnitt und Key)

[charlytango]

Die Frage war .....ob es nicht Sinn machen würde, einen Editor al Objekteditor für solche Zwecke zu haben, welcher eventuell über eine externe Datei gesteuert werden kann.

Grundsätzlich hätte so ein INI-Editor schon einen gewissen Charme (für mich).
Nur führen mich derartige Überlegungen schnell weiter, wie Einstellungswerte in der Anwendungsentwicklung grundsätzlich verwaltet werden sollten/könnten.

unterschiedliche Aspekte wären da abzuwägen. Sicherheit, Wartbarkeit, Schnelligkeit der Implementierung, Codegrößen etc.

Es wird Werte geben die in (einem oder mehreren) INI bzw XML/JSON Dateien im Anwendungsverzeichnis (oder einem eigenen INI-Verzeichnis) liegen.
Und es wird Werte geben die besser in einer DB-Tabelle aufgehoben sind (allgemeine Einstellungswerte des Programms, solche die der User einstellen kann bzw solche die Userspezifisch sein können).

Dazu kommen vielleicht noch Erklärungs- bzw Hilfetexte pro einzelnem Wert, Standardwerte (auf die bei Misskonfiguration zurückgesetzt werden kann), Wertelisten die zur Auswahl stehen etc. Vielleicht sogar ein kleines Tool f den Entwickler damit er die üblichen Werte nicht immer neu schreiben muss, sondern irgendwie aus einem individuellen Wertepool "kopieren" könnte.
Und nicht zuletzt die ansprechende grafische Präsentation und Editiermöglichkeit.

"Config"-Dateien im Anwendungsverzeichnis würde ich in Dateien zum DB-Zugriff und solchen mit anderen Werten trennen. Je nach Anwendung und Userverhalten wären diese Dateien auch (zumindest leicht) verschlüsselt und bei jeder Änderung würde eine einstellbare Anzahl v Backups erzeugt, um bei Misskonfiguration zurückgehen zu können.

Man ist schnell bei etlichen Werten die man einstellen möchte. Leider hab ich nichts gefunden was diesen Anforderungen entspricht, obwohl sie eigentlich jeder Entwickler irgendwann (für sich selbst) "neu erfindet". Klar ist eben jede einzelne Anwendung immer "ein bisschen anders", aber vielleicht lässt sich auch dieses Problem mit der geballten Forumskraft lösen.

Ich würde bei so einem Projekt durchaus mit meinen bescheidenen Ressourcen mitarbeiten.
Mein Plot f Werteverwaltung: Eine INI-Datei mit Werten zum DB-Zugriff im Anwendungsverzeichnis, Rest in Tabelle.

Ähnliche Themen wären: Benutzer/Rechteverwaltung, DB-Erstellung und Änderung, DB-Backup und Restore

Just my 3 cents...

[MacWomble]

Du hast den Kern der Sache getroffen. Genau so stelle ich mir das im Prinzip vor.

1. DB-Zugriffsdaten in einer extra Datei ablegen (habe ich oben auch bereits erwähnt - am besten mit Verschlüsselung)
2. Alles in DBs speichern,was alle Benutzer betrifft
3. Einstellungen, welche sich auch pro Benutzer unterscheiden können (z.B. Pfade, wenn der Anwender stationär und mobil arbeitet, etc) in config-Datei(en)
4. Eine Datei Config-Default um die Standardwerte mit dem Programm mit zu geben. (Wenn man die Hilfetexte mit in Betracht zieht, wäre hier eine XML wohl sinnvoll)
5. Möglichst einfache Editiermöglichkeit für den Anwender / Eventuell auch ein Editor für den Entwickler
6. Einfaches aber logisches (ansprechendes) Design (auf der Anwenderseite)


Das ganze sollte über Klassen realisiert werden, so dass z.B. die Einstellung

Code: Alles auswählen

[Database]
User=Test
...

über Config.Database.User ausgelesen/gesetzt werden kann.


Die von dir angesprochenen Themen Benutzer/Rechteverwaltung, DB-Erstellung und Änderung, DB-Backup und Restore stehen auch auf meiner Liste, haben aber eine weniger hohe Priorität:

- Benutzer/Rechteverwaltung:

Code: Alles auswählen

Steht aktuell auch auf meiner Liste. Der Anwender soll sich am Programm (der DB) anmelden und die BenutzerID wird in allen Tabellen gespeichert, die er (zuletzt) erfasst/verändert hat (oder alternativ eine zusätzliche Historientabelle)

- DB-Erstellung und Änderung:

Code: Alles auswählen

Im moment mache ich das zu Fuß, d.h. beim Kunden wird eine SQL-Datei eingelesen (manuell)
In einem früheren Projekt mit VisualBasic hatte ich dies über eine externe Datei realisiert, welche ein Änderungsprotokoll der DB enthielt (also im Endeffekt auch SQL-Zeilen, aber mit Versionierung.
Aktuell habe ich hier noch nichts realisiert. 

- DB-Backup und Restore

Code: Alles auswählen

Mache ich derzeit über AProcess, welches bei Beendigung des Programms ausgeführt wird. Das funktioniert recht gut.
Wiederherstellung der Datenbank: manuell über SQL-Script (Das reicht in den meisten Fällen auch aus, da es kein Regelfall ist (zumindest nicht sein sollte)

[charlytango]

mit "Rechteverwaltung" meine ich eher dass sich jemand am Programm anmelden kann und gewisse Rechte (auch aus der oder den rechtegruppen denen er angehört) zugeordnet bekommt. Diese Rechte haben im wesentlichen Einfluss darauf was er in der GUI angezeigt bekommt oder nicht. bzw was er im Programm tun darf (auch im Hinblick auf View, Read, Write, Delete )

Änderungshistorie in der DB wäre f mich nochmal ein ganz anderer Brocken. Auch im Hinblick auf DSGVO

Vermutlich ist es schwierig einen Konsens bezüglich der nötigen Funktionen zu bekommen, wenn man dabei nur schreiben kann

[pluto]

Im Prinzip ist sowas "leicht" möglich. Es gibt da sogar schon eine Komponenten für Lazarus... ich meine auf der RTTI Seite. Jede Klasse sollte dabei von TPersistent abgeleitet sein.
Dank der RTTI ist das relativ leicht.... Es sind sogar OI-Editoren möglich....

TIPropertyGrid1 auf der RTTI Seite.....
Diesem kann man dann eine Klasse zuweisen.

Alternativ gibt es bei der TIniFile Klasse natürlich einige Methode, mit den man es recht Dynamisch machen könnte:
procedure ReadSections(Strings: TStrings); override;
procedure ReadSection(const Section: string; Strings: TStrings); override;
und soweiter....

[MacWomble]

Ich habe zu ini und rtti etwas gefunden und hier mal verlinkt, damit es nicht verloren geht:
http://forum.codecall.net/topic/76531-e ... ttributes/

nicht direkt zum Thema, aber auch gut:
https://www.youtube.com/watch?v=-RvlKysIOnQ

[mschnell]

Werden ini-Dateien nicht zunehmend durch xml-Dateien ersetzt? Auch auf Windows und Linux?

Idealer weise würde eine solche Komponente natürlich sowohl INI.-Dateien, als auch XML-Dateien, als auch Registry-Einrtäge editieren können

Außerdem gibt es im Prinzip drei Möglichkeiten, Konfigurations-Daten zu verwenden:
- Bei der Installation vorgenommene Konfigurationen, gelten für alle Benutzer des Programms und sind "global" und für das Programm i.a. Read-only
- Für jeden Benutzer einzeln geltende Einstellungen: "privat" (Read/write)
- Für alle Benutzer gemeinsam geltende Einstellungen: "global" und können zur Kommunikation unter den Benutzern des Programms verwendet werden (Read/write)

In Windows (>=7) gibt es jeweils verschiedene Directories für diese Dateien. Ob es in Linux da einen Standard gibt, weiß ich nicht.

-Michael