Re: Überlegungen für variables Speichern der Konfiguration
Um die Klasse generisch zu machen, vermisse ich persönlich die Option der Verschlüsselung. Meiner Ansicht nach ist es grob fahrlässig Optionen unverschlüsselt abzulegen, insbesondere wenn man irgendwelche Arten von persönlichen Daten ablegen möchte (Email Adressen, Serials, Kennwörter etc.). Eine - zumindest optionale - Verschlüsselung wäre daher nicht nur sinnvoll sondern meiner Ansicht nach fast schon Pflicht.
|
Re: Überlegungen für variables Speichern der Konfiguration
Dafür gibt es ja die Streamspeicherung, da kannst du ja hineinspeichern was du möchtest. Und du kannst es ja auch verschlüsseln. Die Klasse stellt ja nur die Grundlagen zur Verfügung, ob du die Daten vorher verschlüsselst oder nicht hat mit der Verwaltung des Speicherortes ja nichts zu tun.
|
Re: Überlegungen für variables Speichern der Konfiguration
Hallo Sebastian,
danke, dass du es so schnell zur Verfügung gestellt hast. Es ist (vor allem für eine Beta) schon schön gemacht. Noch eine Frage zum Handling bei einer Installation per Setup: Wenn das Programm bereits im Programmordner liegt, sollte ja keine portable-Version mehr möglich sein. Planst du eine Abfrage einzubauen, ob ein Verzeichnis Admin-Rechte braucht, so dass die Option "portable Version" deaktiviert ist? Die Einstellungen eines Programm sollen grundsätzlich in den Eigenschaften von TAppConfig, habe ich das richtig verstanden? Schade ist, dass man für jede Art des Speichern / Ladens die Implementierung erweitern muss, bei einer abgeleiteten Version kommen ja noch die Sicherheitsabfragen hinzu. Ich arbeite bei mir zur Zeit mit einer Xml-Datei. Deren Werte können - wenn sie einmal an einer Stelle definiert sind - automatisch als Stream, als Datei oder als Wert in die Registry geschrieben / geladen werden. Gruß Jürgen |
Re: Überlegungen für variables Speichern der Konfiguration
Zitat:
Die Unit an sich soll wirklich nur bei der Verwaltung des Speicherortes helfen. Heißt: Welche Optionen du dem Benutzer anbietest und welche ggf. deaktivierst, liegt an dir. Du könntest ja, wenn der Benutzer die portable Option anklickt, vorher kurz eine Datei im Exeverzeichnis anlegen um zu schauen ob das geht bevor du die Seite umschaltest. Ich schaue einmal ob ich eine schönere allgemeine Lösung sehe, aber ich denke so einfach ist das nicht (Stichwort Netzwerkverzeichnisse, usw.). Zitat:
Und wie in dem Beispiel TAppData musst du dich ja sonst auch um die Speicherung kümmern, nur dass du so dich nicht darum kümmern musst, dass die Datei geöffnet wird usw. und wo diese liegt. Im Grunde musst du nur die Zeilen mit TryReadString bzw. WriteString duplizieren. Die Abfragen müssen nicht jedesmal wiederholt werden! Beispiel:
Delphi-Quellcode:
Weitere Abfragen kannst du jetzt direkt da hineinpacken.
begin
if Ini.SectionExists('Userinfo') then begin fUserName := TryReadString('Userinfo', 'Username'); end else raise ELoadConfigException.Create(Format(sErrorLoadingConfig + sDLB + sIniSectionNotFound, ['Userinfo'])); end;
Delphi-Quellcode:
Mir ist da keine universellere Lösung eingefallen. ;-)
begin
if Ini.SectionExists('Userinfo') then begin fUserName1 := TryReadString('Userinfo', 'Username1'); fUserName2 := TryReadString('Userinfo', 'Username2'); fUserName3 := TryReadString('Userinfo', 'Username3'); fUserName4 := TryReadString('Userinfo', 'Username4'); fUserName5 := TryReadString('Userinfo', 'Username5'); fUserName6 := TryReadString('Userinfo', 'Username6'); ... end else raise ELoadConfigException.Create(Format(sErrorLoadingConfig + sDLB + sIniSectionNotFound, ['Userinfo'])); if Ini.SectionExists('UserDataXYZ') then begin fUserData1 := TryReadString('UserDataXYZ', 'UserData1'); fUserData2 := TryReadString('UserDataXYZ', 'UserData2'); fUserData3 := TryReadString('UserDataXYZ', 'UserData3'); fUserData4 := TryReadString('UserDataXYZ', 'UserData4'); fUserData5 := TryReadString('UserDataXYZ', 'UserData5'); fUserData6 := TryReadString('UserDataXYZ', 'UserData6'); ... end else raise ELoadConfigException.Create(Format(sErrorLoadingConfig + sDLB + sIniSectionNotFound, ['UserDataXYZ'])); end; Ich könnte höchstens die TryReadString mit weiteren Typen mit in SJConfigUtils.pas nehmen, aber ich fand das da sinnvoller. Zitat:
// EDIT: Weitere Demos mit Streams und so werden natürlich noch folgen, aber das ist halt ein wenig Arbeit noch. :mrgreen: |
Re: Überlegungen für variables Speichern der Konfiguration
Vielen Dank für Deine Erklärungen und natürlich Deine prima Arbeit.
Ich werde mich in den nächsten Tagen mal intensiver damit beschäftigen. Gruß Jürgen |
Re: Überlegungen für variables Speichern der Konfiguration
Zitat:
|
Re: Überlegungen für variables Speichern der Konfiguration
Zitat:
Denn einfach ins Anwendungsverzeichnis zu schreiben ist eben äußerst schlechter Stil und inakzeptabel, wenn es sich nicht um eine explizit portable Version handelt. Und deshalb durchsuche ich eben die verschiedenen Positionen und stelle die Verwaltung automatisch zur Verfügung. Die Einstellungen selbst sind nicht so einfach automatisch zu verwalten. |
Re: Überlegungen für variables Speichern der Konfiguration
Beim Starten überprüft die Anwendung, ob im Installationsordner eine "Dummy-Datei" vohanden ist:
Falls JA: Die Anwendung verhält sich so, als ob sie installiert wäre (Konfiguration wird z.B. in %Appdata% gespeichert) Falls NEIN: Die Anwendung verhält sich "portable" (Konfiguration wird im Programmordner gespeichert). Das Installationsprogramm der Anwendung installiert automatisch die "Dummy-Datei" mit. KISS (Keep It Simple, Stupid) :wink: |
Re: Überlegungen für variables Speichern der Konfiguration
Du denkst zu kompliziert. ;-)
Bei deiner Vorgehensweise würde es separate Pakete geben, ein Setup zur Installation und eine Zip-Datei für die portable Nutzung. Man kann aber nicht ohne weiteres die installierte Version auf einen Stick kopieren oder die Zip-Datei auspacken und installiert nutzen. Genau das geht aber mit meiner Lösung, da nicht an gespeicherten Daten (der Dummydatei) die Unterscheidung gemacht wird... Zudem kann man sehr einfach eine Option zur Verschiebung der Einstellungen einbauen (z.B. auf einen Stick ins eigene Verzeichnis), da nur eine Methode aufgerufen werden muss. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz