himXML (gesprochen himix ML)

[Dawn87]

Super Sache! Werde leider wohl erst morgen oder Freitag zum Ausprobieren kommen.

Hier ändern sich die Prioritäten zurzeit schneller als mir lieb ist.

[himitsu]

Kenn ich irgendwie.

Ich versuche immernoch mein Basissstem aufzufräumen, bzw. ich alles komplett neu aufzubauen (mit Übernahme paar "überarbeiteter" Altcodes).
Alle File-Parser wollte ich dann darauf aufbauen lassen und überall eine einheitliche Speicherverwaltung vorallem gemeinsame Grundfunktionen nuzten.
Also alle Datei- und Datenlesefunktionen dann intern gleich/ähnlich haben. (XML, CompressedXML, JSON, INI, SQL, SVG, AnimatedCursors, PDF, XPS, OXPS, ZIP, VVFS usw.)

Einziges Problem für "dich": Ich schmeiße allen Legacy-Code raus und verwende neure CompilerFeatures/RTLFunktionen ... aktuell sieht es so aus, als wenn dann das Meiste nur noch XE3 XE7 und Neueres unterstützt.

[romber]

Hallo himitsu,

nutze himXML in allen meinen XML-Projekten. Tolle Arbeit, nochmals vielen Dank!
Gibt es mittlerweile eine neuere Version?

[CodeX]

Ich werde bei einem größeren Projekt mittelfristig wohl von INI auf XML wechseln müssen. Habe deshalb gerade ein wenig ausgelotet, welche Möglichkeiten da so bestünden und finde himXML rein von der Beschreibung und von der Entwicklung ziemlich gut. Super Arbeit, himitsu!

Nun scheint ja OmniXml in Form von OXml ja wieder auferstanden zu sein und wird aktuell weiterentwickelt. Ein "lebendiges" Projekt ist natürlich immer irgendwie angenehmer, wenn man sowieso frisch einsteigen möchte.

Kann jemand vom aktuellen Stand aus sagen, ob himXML und OXml irgendetwas stark unterscheidet? (Vor-/Nachteile)

himitsu, hast Du vor, himXML noch weiter zu entwickeln? Wäre es denkbar, die Verschlüsselungsfuntion von einzelnen Knoten auf die gesamte Datei zu erweitern?

[a.def]

Dann klinke ich mich aus Interesse auch mal ein

Der Wechsel von Ini nach XML interessiert mich auch sehr. Nur warum sollte man das tun? Welche Gründe müssen/sollten für einen so radikalen Wechsel erfüllt sein?
Was Ini ja auszeichnet ist, dass der Benutzer die Datei leicht bearbeiten kann.
Gegen Ini spricht diese komische ... 64 KB (?) Grenze.
Ich habe eine 59KB große Ini-Datei und keine Probleme. Was ab 64 KB passiert weiß ich nicht.

Was spricht aber für XML und gegen Ini?

Ich selbst würde beim Wechsel nicht himXML nehmen sondern das hier... habe ich vor Jahren schon oft benutzt und hatte nie Probleme:
http://www.swissdelphicenter.ch/de/showcode.php?id=2269
Schön, klein, keine DLL.

[jfheins]

Für xml spricht, dass der Benutzer es sehr leicht bearbeiten kann.

Zudem ermöglicht die hierarchische Struktur einfache Listen, komplexere Objekte und Validierung.

Beispielweise:

Code:

<friends xmlns="http://schemas.microsoft.com/office/outlook/2010/06/socialprovider.xsd">
  <person>
    <userID>4667647</userID>
    <firstName>Melissa</firstName>
    <lastName>MacBeth</lastName>
    <nickname></nickname>
    <birthday>1979-08-09</birthday>
    <emailAddress>[e-mail]</emailAddress>
    <address>
    <!-- etc -->
    </address>
  </person>
</friends>

Hier kannst du zum Beispiel erstmal das ganze validieren. Also die legst eine xsd danaben und
1. Der Benutzer/Bearbeiter weiß damit genau, welche Werte erlaubt sind. (Ja nach Qualität der xsd)
2. In deinem Programm kannst du EINE Validierung durchführen um zu prüfen, ob die ganze Datei i.O. ist.
3. Du kannst den Code um die Adresse zu parsen einmal definieren (Adress-Klasse) und einfach wiederverwenden.

[a.def]

Nur Ini ist doch um einiges leichter zu bearbeiten, speziell für Laien.

[CodeX]

Zitat von a.def:

Was spricht aber für XML und gegen Ini?

Naja, es gibt viele Gründe (Mehrzeilige Texte, Inline-Binärdaten, ...), aber in meinem Fall ist die Struktur das ausschlaggebende Kriterium. Versuch mal einen Baum (VirtualTree o.ä.) in einer Ini abzubilden.

Zitat von a.def:

Ich selbst würde beim Wechsel nicht himXML nehmen sondern das hier... habe ich vor Jahren schon oft benutzt und hatte nie Probleme:
http://www.swissdelphicenter.ch/de/showcode.php?id=2269
Schön, klein, keine DLL.

Das ist ja lediglich eine Kapselung von TXMLDocument und somit weder schnell noch klein (Du vergisst den eigentlichen Code von TXMLDocument).
Das kannst Du ja um jede XML-Komponente nach Deinen Vorstellungen drumherumbasteln. Würde ich sowieso machen, um eben abgestimmt auf meine Anwendung kompakter damit arbeiten zu können.

[CodeX]

Irgendwie dachte ich, es geht hier um himXML und nicht um die möglichen Nachteile von INIs!?
Ich hatte diesen Thread zwecks Fragen zu himXML "aufgeweckt" und nun gehen diese leider durch Off-Topic unter.
Ich hole es daher nochmal rauf:

Zitat von CodeX:

Ich werde bei einem größeren Projekt mittelfristig wohl von INI auf XML wechseln müssen. Habe deshalb gerade ein wenig ausgelotet, welche Möglichkeiten da so bestünden und finde himXML rein von der Beschreibung und von der Entwicklung ziemlich gut. Super Arbeit, himitsu!
Nun scheint ja OmniXml in Form von OXml ja wieder auferstanden zu sein und wird aktuell weiterentwickelt. Ein "lebendiges" Projekt ist natürlich immer irgendwie angenehmer, wenn man sowieso frisch einsteigen möchte.

Kann jemand vom aktuellen Stand aus sagen, ob himXML und OXml irgendetwas stark unterscheidet? (Vor-/Nachteile)
himitsu, hast Du vor, himXML noch weiter zu entwickeln? Wäre es denkbar, die Verschlüsselungsfuntion von einzelnen Knoten auf die gesamte Datei zu erweitern?

[p80286]

@nahpets
das kommt davon wenn man sich nicht mehr tagesaktuell mit etwas beschäftigt. In einer Ansi-Umgebung halte ich Umlaute immer noch für tödlich, spätestens wenn du abweichende Codepages nutzt.

Gruß
K-H