Objektorientiertes TIniFile-Replacement mit Unicode-Fähigkeit

[TiGü]

Zitat:

Zitat von Codehunter (Beitrag 1189028)

Ja Unicode und echte Objektorientierung ohne Abhängigkeit vom WinAPI.

Was heißt denn jetzt Unicode-Fähigkeit?
Das Unicode-Strings ins Ini-File abgespeichert werden?
Das ist in TMemIniFile (ab Delphi 2009) gegeben, es wird mit den Typ String gearbeitet.

Auch verwendet TMemIniFile nicht die WinAPI-Funktionen GetPrivateProfileString/WritePrivateProfileString sondern setzt auf hierarchische String-Listen.

Bitte bei Gelegenheit einen Blick auf die Doku und/oder Code werfen.

Vielleicht reicht es schon wenn du deine Klasse davon ableitest?!

[Codehunter]

Das mag ja alles richtig sein. Aber zum ersten solltest du mal einen Blick auf meine Delphi-Version werfen und zum zweiten den ganzen Thread durchlesen. Ich halte T(Mem)IniFile für strukturell in manchen Szenarien schlichtweg ungeeignet.

Unter ähnlichen Voraussetzungen ist damals auch TVirtualTreeView entstanden. Da gabs bestimmt auch einige, die der Ansicht waren, der Standard-VCL-Treeview wäre vollkommen ausreichend. Es gibt aber immer Anwndungsfälle, wo TVirtualTreeview dem TTreeView haushoch überlegen ist.

Schaut euch den Quelltext wirklich mal praktisch an und vorallem nicht den Teil den ich nur zur Kompatibilität mit TIniFile eingebaut habe sondern den objektorientierten Teil.

Delphi-Quellcode:

with TUniObjectIni.Create('C:\Test.ini') do begin
  try
    Sections['TheSection']['TheIdent'].Str:= 'ABC';
    Sections['TheSection']['TheIdent'].Int:= 123;
    Sections['TheSection']['TheIdent'].DateTime:= Now;
    {....}
  finally
    Free.
  end;
end;

[Popov]

Man sollte nie fragen wozu etwas gut ist.

Ich hatte mit einem anderen Delphianer mal vor eine Datenbank auf Grundlage der Ini zu entwickeln, so just4fun. Es ist natürlich klar, dass die Ini dazu nicht taugt, aber es wäre schon lustig gewesen mit den Datenbankkomponenten auf eine Ini zuzugreifen. Die Verwaltung hätte ich schon hinbekommen, aber mir fehlte das Wissen bezüglich der Schnittstelle, was ich vor allem für ein anderes Projekt brauchte.

Damals, als kein Schwein noch etwas von PHP oder MySQL hörte, bzw. man seine Seiten statisch ins Web stellte, hat mich einer gebeten mir was für statische Seiten auszudenken. Ich hab das auch in einem Projekt umgesetzt und es klappte sehr gut, nur eben ohne die Datenbankkomponenten. Die Begeisterung anderer Programmierer hielt sich in Grenzen: die vorhandenen Datenbanken sehr gut sind und zurzeit besteht kein Bedarf an etwas neuem.

Übrigens, was ich da programmiert habe sah in etwa so aus:

Code:

<db=name>Anna</db> <db=nachname>Wegener</db>

Browser ignorieren Tags die sie nicht kennen. Jede Html-Seite ein Datensatz. Die Ausgabe wäre

Code:

Anna Wegener

. Die Daten sind in der Webseite versteckt und man könnte sie jederzeit auslesen und ändern. Heute ist das nichts, aber damals wurden damit paar hundert Artikel verwaltet.

[Codehunter]

Sagen wir mal so: Wenn man es mal auf die Basics runterbricht, dann ist eine INI jetzt schon eine Datenbank. Theoretisch könnte man auf Basis meiner Klasse sogar jetzt schon transaktionale Zugriffe realisieren denke ich. Aber ganz ehrlich: Eine INI halte ich nicht für eine gute Basis für eine Datenbank.

Aber wenn ich eines gelernt habe: Es ist nicht immer schlecht, wenn man gelegentlich ein Rad neu erfindet. Denn nur weil die Mehrheit das alte Rad schon für perfekt hält, warum nicht überlegen ob es tatsächlich so ist. Man kann sich dabei auch irren. So oder so lernt man was dabei :-)

[Codehunter]

Update: Bösen bösen Bug entfernt, wodurch es nicht möglich war, Boolsche Werte als FALSE (="OFF") zu speichern, es kam immer ein "ON" in der Ini an. Genauer gesagt war der Fehler im Parsing der Metadaten zu finden.

[Codehunter]

Update: Noch so einen Bösling entfernt, der bei Strings mit Zeilenumbrüchen endlose Backslash-Ketten produzierte.

[Codehunter]

Update: Verbesserungen bei Values mit Steuerzeichen (Zeilenumbrüche etc.)