Überlegungen für variables Speichern der Konfiguration

[Fridolin Walther]

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.

[jaenicke]

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.

[Pfoto]

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

[jaenicke]

Zitat von Pfoto:

Planst du eine Abfrage einzubauen, ob ein Verzeichnis Admin-Rechte
braucht, so dass die Option "portable Version" deaktiviert ist?

Den Wizard und das Handling usw. wollte ich bewusst aus der Unit ausklammern und nur exemplarisch in der Demo zeigen, denn das lässt sich allgemein kaum machen. Das kann jeder selbst überlegen wie detailliert welche Optionen angeboten werden sollen und wie der entsprechende Dialog aussehen soll.

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 von Pfoto:

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.

Musst du ja nicht. Du musst nur die Implementierung von TAppData verändern, nicht die von SJConfigUtils.pas.
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:

begin
  if Ini.SectionExists('Userinfo') then
  begin
    fUserName := TryReadString('Userinfo', 'Username');
  end
  else
    raise ELoadConfigException.Create(Format(sErrorLoadingConfig + sDLB
      + sIniSectionNotFound, ['Userinfo']));
end;

Weitere Abfragen kannst du jetzt direkt da hineinpacken.

Delphi-Quellcode:

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;

Mir ist da keine universellere Lösung eingefallen.
Ich könnte höchstens die TryReadString mit weiteren Typen mit in SJConfigUtils.pas nehmen, aber ich fand das da sinnvoller.

Zitat von Pfoto:

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.

Wenn du einen Stream hast, kannst du ja direkt die Streammethoden verwenden und INI oder Registry erst gar nicht beachten. Und die Werte dann ausgelesen als Eigenschaften in TAppData zu definieren oder so ist ja kein Muss, das kannst du ja weiter wie bisher nutzen.

// EDIT:
Weitere Demos mit Streams und so werden natürlich noch folgen, aber das ist halt ein wenig Arbeit noch.

[Pfoto]

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

[Fridolin Walther]

Zitat von jaenicke:

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.

Wenn ich die Daten ohnehin selbst in einen Stream pack und danach selbst wieder raus popel, kann ich ihn auch selbst irgendwo hin schreiben und brauch dafür kein "Framework" . Aber ist wahrscheinlich Geschmackssache.

[jaenicke]

Zitat von 0xF30FC7:

Wenn ich die Daten ohnehin selbst in einen Stream pack und danach selbst wieder raus popel, kann ich ihn auch selbst irgendwo hin schreiben und brauch dafür kein "Framework" . Aber ist wahrscheinlich Geschmackssache.

Es geht ja hier gerade darum wo ich das dann hinspeichere.
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.

[invalid_operation]

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)

[jaenicke]

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.