Überlegungen für variables Speichern der Konfiguration

[Pfoto]

Hallo zusammen,

ich habe vor ein paar Tagen die Umsetzung zu einer "jetzt aber wirklich
sinnvollen und durchdachten Vorhaltung der Konfiguration" vorgenommen. ;-)

Es existiert ein globales Objekt, das eine spezielle Xml-Klasse enthält,
die in einfacher Weise Daten vorhält und variabel Daten in den
verschiedenen Systemordner oder der Registry speichern soll.

Dem Programm wird grundsätzlich ein Speicherort zugewiesen, aber der
User sollte auch im Nachhinein (oder vielleicht doch durch eine Installation?)
bequem daraus z.B. eine portable Version machen können.

Aber wie und wo könnte ich diese Definition vornehmen?

• Sollte er die Konfigurationdatei per Hand in das Programmverzeichnis
  kopieren, so dass die Anwendung dann automatisch portabel ist?
• Sollte die Exe mit einem entsprechenden Parameter aufgerufen werden?
  (aber dann müsste es ja immer Verknüpfungen geben)
• Sollte die Anwendung automatisch ermitteln, ob sie sich im Windows-Programmordner
  oder auf einem USB-Stick befindet? (und geht das überhaupt in zuverlässiger Weise?)
• Sollte ich in das Programm eine Option für "Erstelle portable Anwendung" integrieren,
  die alles direkt z.B. auf USB-Stick kopiert und eine Konfigurations-Datei anlegt?
• Oder kann man vielleicht ganz auf eine allgemeine Konfigurations-Datei verzichten,
  weil einfach alles im gleichen Ordner des Projektes gespeichert wird?
  (wobei es dann keine Liste der zuletzt geöffneten Projekte geben kann und
  neue Projekte immer wieder im Default-Modus starten müssten)

Wenn ich dem User eine Auswahl gebe (beim ersten Programmstart) dann muss diese
Auswahl ja auch wieder irgendwo gespeichert werden und somit lege ich (vielleicht
ohne Wollen des Users) wieder etwas in der Registry oder einem Ordner an.

Was würdet ihr zu den Vorschlägen sagen oder gibt es da vielleicht schon was Bewährtes?

Danke für jede Meinung

Jürgen

[quendolineDD]

Es gibt Projekte, da werden direkt 2 unterschiedliche Versionen angeboten, wobei die Eine eine normale und die Andere eine portable Version darstellt.
Eine variabel gestaltete Installation wäre IMO die benutzerfreundlichste Variante. Ob es überhaupt notwendig ist, eine Installation durchzuführen ist die andere Frage, aber dann wäre o.g. der bessere Weg.

[Mithrandir]

jaenicke hat sich dazu schonmal seine Gedanken gemacht.

[jaenicke]

Und ich bin auch schon weiter, ich bin (endlich) fast fertig mit der Verwaltungsklasse. Diese nimmt die ganze Arbeit ab und fordert ggf. auf den Einstellungswizard anzuzeigen, wenn sie keine Einstellungen vorfindet. Man kann durch simples Setzen des Ortes für die Einstellungen diese dorthin verschieben lassen (wobei diese natürlich erst dann am alten Ort gelöscht werden, wenn sie am neuen erfolgreich geschrieben wurden).

Ich setze mich da gleich nochmal dran, dann kann ich nachher eine erste Alphaversion veröffentlichen.

[Mithrandir]

Zitat:

Zitat von jaenicke

Ich setze mich da gleich nochmal dran, dann kann ich nachher eine erste Alphaversion veröffentlichen.

:firejump:

[Pfoto]

@quendolineDD:

zwei Installationen bedeuten ja leider wieder etwas mehr Aufwand -- für eine eigentlich gleiche Anwendung.
Gibt es Installer, die denn einen Auswahldialog während der Installation zulassen, so dass man
während der Installation eine Config-Datei im Anwendungsverzeichnis anlegen kann oder eben nicht?


@Daniel G,
@jaenicke:

Die Gedanken von jaenicke zu dem Thema hatte ich schon gelesen und auch daraus lernen können.
Aber: Hier wird ja von einer Überprüfung der Einstellungsdatei im Anwendungsordner gelesen -
aber wie kommt die dort hinein?

Denn nach der Installation kann ich nichts mehr in den Programmordner schreiben ohne Admin-Rechte,
zudem sollte die Datei ja erst dort liegen, wenn das Programm auch wirklich in einem porablen bzw.
schreibbaren Ordner liegt.


Gruß
Jürgen

[jaenicke]

Der Punkt ist: Wenn du in der Reihenfolge prüfst, dann musst du nirgends speichern, wo die Einstellungen liegen. Denn bei einer portablen Version werden zuerst die im Anwendungsverzeichnis gefunden. Bei einer normal installierten Version liegen dort keine, also werden die im Anwendungsdatenverzeichnis gefunden und benutzt.

Wenn jetzt eine Version portabel gespeichert werden soll, dann muss in dem Einstellungsfenster nur ein Knopf sein, der die Einstellungen aus dem Anwendungsdatenverzeichnis portabel ins eigene Verzeichnis holt. (Und ggf. auch das ganze Programm auf einen Stick speichert inkl. Einstellungen.)

// EDIT:
Ach ja: Ich bin soweit fertig, ich muss es nur noch testen und überprüfen, nicht dass da was schief geht.

[himitsu]

@jaenicke:
Ideal wäre es aber, wenn man auch noch per Parameter angeben kann welcher Speicherort genutzt werden soll. Eventuell auch mit zusätlicher mannueller Vergabe von Dateiname und/oder Verzeichnis.

(notfalls auch nur über Properties auswählbar und der Programmier wertet die Parameter selber aus)

So könnte man eine Installation auch mit unterschiedlichen Einstellungen nutzen, auch innerhalb eines Accounts.

[jaenicke]

Zitat:

Zitat von himitsu

So könnte man eine Installation auch mit unterschiedlichen Einstellungen nutzen.

Stimmt, an eine parallele Nutzung mehrerer Profile auf einem Benutzerkonto habe ich nicht gedacht. Allerdings ist das wohl eher der Ausnahmefall.

Ich habe vor allem berücksichtigt, dass sich eine installierte und mehrere portable Versionen nicht stören.

[jaenicke]

So, eine Alphaversion hänge ich einmal an, bisher funktioniert die Demo noch nicht komplett, aber portabel und automatisch (lokales Anwendungsdatenverzeichnis) funktionieren. Der Rest ist nicht viel, aber erst einmal muss ich die Buildskripts und Projektorganisation machen, danach kümmere ich mich dann um Verbesserungen und die Fertigstellung der Demo.

Zudem muss ich die Unit in meine eigenen Open Source Projekte einbauen und diese damit endlich aus dem Betastatus herausbringen. :mrgreen:

// EDIT:
Vorstellungsthread im DF, hier folgt ein entsprechender Thread auch bald:
http://www.delphi-forum.de/viewtopic.php?p=562996

[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:

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:

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:

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. :mrgreen:

[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:

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:

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) :wink:

[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.