Objektorientiertes TIniFile-Replacement mit Unicode-Fähigkeit

[Popov]

Nun ja, INI ist eigentlich sowieso schon veraltet, aber ich hab den Schritt zu XML auch noch nicht geschafft. Dazu ist INI einfach zu einfach.

Was Spotlight angeht, lag das Problem vor allem an Peter. Als er mit dem Forum anfing, hat man Forensoftware genutzt, zuletzt hat sich die Boardsoftware durchgesetzt. Und da stand er mit einer proprietären Software die anfing Geld für Pflege zu kosten. Er hätte den nächsten Schritt wagen und mit einem vBulletin Forum neu anfangen sollen. Das alte Forum Readonly. Die Leute wären schon geblieben. Auch bei einem anderen Punkt hat er nicht den Sprung in die Neuzeit geschafft: einfach Moderatoren bestimmen die nach dem Rechten gucken und das Forum wäre ein Selbstläufer. Dazu hat er den Leuten wohl nicht genug vertraut. Nicht alles selbst kontrollieren müssen, bzw. einen Angestellten dafür abstellen. Das hätte er auch aus einem Krankenbett managen können. Zuletzt hat er sich mehr Arbeit gemacht als nötig war. Geendet hat es mit eine Art Burnout.

[Codehunter]

Ich habe sogar einige Zeit XML zur Konfiguration genutzt. Für Client-Server-Kommunikation nutze ich bis heute SOAP, was ja eine Unterart von XML ist. Doch dann bin ich zu der Meinung gekommen (wird jetzt ein bisschen weltfremd klingen) dass sich XML langfristig gar nicht durchsetzen wird.

Warum? Zum einen ist die Parserei zu aufwendig. Klar gibt es MSXML aber das will einerseits nicht jeder nutzen, aus verschiedensten Gründen (Lizenzpolitik, nicht X-Plattform etc.). Eigene Parser schreiben ist irgendwie hirnrissig. Third-Party-Parser sind meist kostenpflichtig und teuer.

Zum zweiten produziert XML Unmengen Overhead. Es kommt ja nicht von Ungefähr dass die großen Softwareschmieden ihre XML-Metadaten nochmal in ZIP umverpacken. Ich nenne da nur OOXML und Corel CDR als Beispiele. Microsoft hat fast 10 Jahre gebraucht bis sie in ihrem eigenen Office den hauseigenen Standard OOXML vollständig unterstützt haben. Das spricht in meinen Augen Bände.

Drittens zeigt sich schon langsam ein Trend gegen XML. Da wäre z.B. das W3C, das sich zuletzt bei HTML5 gegen eine Weiterentwicklung von XHTML und für ein Superset von HTML4 entschieden hat. Dann hat SOAP mit REST einen Konkurrenten bekommen, der technisch näher an INI als an XML dran ist. Auch erschließt sich mir nicht, warum man für seine Konfigurationsdaten ein Austauschformat wie XML verwenden sollte. Außer der eigenen wird sich in den meisten Fällen keine andere Software mit den Daten befassen.

Daher denke ich, kann man ruhig bei INI bleiben für Konfig-Zwecke. XML sollte man in neuen Projekten unter Umständen schon gar nicht mehr einsetzen.

Tja und Spotlight... Ich fand Spotlight gerade wegen der Baumstruktur gut. Das war auch sowas wie eine Hausmarke. vBulletins und phpBBs findet man wie Sand am Meer, die meisten sind auch noch schludrig aufgesetzt und nie über das Standard-Theme hinaus gekommen. Möglicherweise war die Baumstruktur in mancherlei Punkten sogar übersichtlicher als die Brettstruktur.

Was ich nie verstand: Peter hatte auf der SL-Startseite ein wirklich ansprechendes Layout, doch kaum dass man in die Unterseiten ging kam der dicke Stilbruch und man fühlte sich optisch zu Netscape-Browser und HTML3 zurückversetzt.

Problematisch war wohl die proprietäre Perl-Software mit der hoffnungslos und ersatzlos veralteten Datenbank - Sybase wenn ich mich recht erinnere. Peter war wohl irgendwann der Programmierer abhanden gekommen der das Ding aus einer gekauften Lösung weiter entwickelt hatte und so musste er sich notgedrungen selbst damit befassen.

Ich hatte ihm sogar mal angeboten, die Software kostenlos in PHP und MySQL neu zu schreiben, aber das kam wohl zu spät, da war der Burnout schon in vollem Gange. Oder er hat nicht geglaubt dass man das in 4 Wochen machen kann mit heutigen Frameworks. Obwohl er gesehen hatte dass ich mit "Twilight SL" damals schon einen moderneren Reader für sein veraltetes Forum geschrieben hatte - in anderthalb Wochen.

Die Sache mit den Moderatoren hab ich genauso gesehen und ihm auch mehrfach vorgeschlagen. Aber er hat es nie als ernsthafte Möglichkeit in Erwägung gezogen. Ich denke, weil er die Nase viel zu tief in Gesetzen und Paragraphen stecken hatte und überall nur noch Abmahnungen und Anwälte gesehen hat. Vermutlich hatte er selbst keinen guten, internet-fähigen Hausanwalt, sodass ihm zwei oder drei Abmahnungen richtig viel Geld gekostet haben. Tatsächlich war es aber schon damals so dass er höchstens als Mitstörer haftbar gmacht werden konnte da die Inhalte ja nachweislich nicht von ihm selbst stammten.

Und so ist die vielleicht beste deutschsprachige Community ganz jämmerlich zum Teufel gegangen. Denn die Leute die da waren, das war ein unschätzbares Kapital und Peter hats nach meiner Ansicht nicht erkannt.

[Codehunter]

So, Version 1.0.1 ist fertig. Ich hab mal eure Anregungen mit einfließen lassen. Steuerzeichen im String werden jetzt besser escaped und für die Typkonvertierungen wird jetzt TFormatSettings verwendet. Eine neue Idee von mir ist noch dazu gekommen: Die FormatSettings können jetzt als Metadaten mit in die INI gespeichert werden. So kann man sicher sein dass die Datei auf jedem System wieder richtig ausgelesen wird, egal welche Regionaleinstellungen man gemacht hat. Kleinere Bugfixes hab ich auch noch gemacht, das eine oder andere Memleak raus und einige Inkonsistenzen beim Thema Unicode.

Um die Metadaten zu verwenden kann man entweder den optionalen boolschen Parameter im Konstruktor angeben (TUniObjectIni.Create(Filename, UseMetadata) oder aber nachträglich die Eigenschaft HandleMetaData:= TRUE setzen. Letzteres wirkt sich aber logischerweise nicht auf den Dateiinhalt aus, der bereits durch den Konstruktor geladen wurde, sondern erst beim Speichern.

[Codehunter]

Update: Bugfix für das wilde Duplizieren von Sections in der INI.

[Codehunter]

Update: Property Section.Ident.Default hinzugefügt.

[himitsu]

Du solltest den Thread mal verschieben lassen. (einfach auf den Meldebutton bei einem der Posts hier klicken und 'nen Mod darum bitten)

z.B. ins Projekte-Forum
Dort darfst du deinen ersten Post unbegrenzt editieren und kannst somit immer die aktuelle Version/Datei gleich (übersichtlich) am Anfang positionieren.

[Codehunter]

Mal schauen... Ich denke ein richtiges Projekt ist es noch nicht. Es gibt noch Bugs und konzeptionelle Ungereimtheiten. Außerdem fehlt noch ein richtiges Demo-Projekt. Wenns soweit ist kann ich ja einen neuen Eintrag bei den Projekten machen und den Thread hier schließen. Bis dahin wäre ich über das ein oder andere Feedback hier dankbar.

[TiGü]

Zitat:

Zitat von Codehunter (Beitrag 1187627)

Dabei hat mich eigentlich immer gestört, dass TIniFile[LIST=3][*] keinen direkten Zuriff auf Einträge in der Ini bietet sondern mehr oder weniger nur eine in eine Klasse verpackte prozedurale Programmierung hat

Am Rande bemerkt verwendet TUniObjectIni nicht das Windows-API für die Dateigeschichten (Stichwort WritePrivateProfileString) sondern arbeitet komplett mit einer StringList. Dadurch sollte der Code auch relativ leicht zu Lazarus portierbar sein. Es wird aber nur beim Laden und Speichern von Dateien auf der StringList rumfuhrwerkt, alles andere passiert komplett im Speicher.

Gab es TMemIniFile in Delphi 7 noch nicht?
http://docwiki.embarcadero.com/Libra...es.TMemIniFile

[Popov]

Ich hab mir den Code zwar nicht näher angeguckt, aber ich glaube Codehunter geht es im speziellen um Unicode-Fähigkeit.

[Codehunter]

Ja Unicode und echte Objektorientierung ohne Abhängigkeit vom WinAPI. Prozedurale Programmierung schön und gut, aber ist auch nicht mehr das gelbe vom Ei...

Darüber hinaus haben sich inzwischen ein paar Features ergeben, die über T(Mem)IniFile hinaus gehen. In meiner aktuellen Beta z.B. ein Changed-Property sodass man erkennen kann ob der Inhalt modifiziert wurde.