Benutzerdefinierte Compiler-Warnungen

[Scurra]

Zitat:

Soweit ich sehe unterstützt NativeXML aber kein Xpath, oder irre ich mich?

Dazu kann ich leider noch nichts sagen, da ich XPath gerade zum ersten Mal höre So wie ich das auf die Schnelle gelesen habe, stellt XPath Funktionen bereit, um durch xml-Dokumente zu navigieren. Ist das richtig so?

Zitat:

Dein Chef hat Recht. Wenn du nicht gerade ein XML-Validierungs-Import-Export-Programm schreibst, dann gehört der Umgang mit den XML-Dateien an den Rand der Anwendung und nicht in den Kern (obwohl, selbst dann sogar )

Na ja, ich ging bisher immer davon aus, dass ein xml-Parser nichts anderes macht, als den Inhalt eines xml-Dokuments in sein eigenes Speichermodell (wie auch immer das aussehen mag) liest. Wenn ich mir selbst einen Parser schreiben würde, dann würde ich das zumindest auf diese Weise machen, d. h. die .xml-Datei wie als Text-Datei betrachten und mir die Knoten, die Struktur usw. mit Listen o. ä. in den Speicher einlesen (mit einer Methode wie LoadFromFile) und wenn ich dann mit Methoden wie "GetNode(Integer)" o. ä. würde ich dann in meinem Speichermodell operieren. Insofern ist mir nicht ganz klar, warum das Arbeiten direkt mit xml-Dateien/xml-Dokumenten langsamer sein soll.

Aber mir fällt auch gerade auf, dass wir durch diese xml-Geschichte vom eigentlichen Thema abkommen

[alda]

Zitat von Scurra:

Zitat:

Soweit ich sehe unterstützt NativeXML aber kein Xpath, oder irre ich mich?

Dazu kann ich leider noch nichts sagen, da ich XPath gerade zum ersten Mal höre So wie ich das auf die Schnelle gelesen habe, stellt XPath Funktionen bereit, um durch xml-Dokumente zu navigieren. Ist das richtig so?

XPath ist eine Querylanguage und hat somit eine entsprechende Syntax zum abfragen von XML Strukturen. Schau Dir dazu einfach mal ein Tutorial an (z.B. w3schools)

Zur Veranschaulichung mal ein kleines Beispiel anhand deines Anwendungsfalls:

Gegeben sei folgende XML Struktur

Code:

<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
  <book category="COOKING"/>
  <book category="CHILDREN"/>
  <book category="WEB"/>
  <book category="WEB"/>
  <usedbooks>
    <book category="WEB"/>
    <book category="COOKING"/>
    <book category="MISC"/>
  </usedbooks>
</bookstore>

XPath Query um ..

• alle Knoten books mit der category "WEB" zu erhalten, allerdings nicht rekursiv (also nur auf bookstore Ebene):
  //bookstore/book[@category="WEB"]
• alle Knoten books mit der category "WEB" zu erhalten, allerdings rekursiv (somit auch im usedbooks Knoten)
  //bookstore//book[@category="WEB"]

[Sir Rufo]

Zitat von Scurra:

Zitat:

Dein Chef hat Recht. Wenn du nicht gerade ein XML-Validierungs-Import-Export-Programm schreibst, dann gehört der Umgang mit den XML-Dateien an den Rand der Anwendung und nicht in den Kern (obwohl, selbst dann sogar )

Na ja, ich ging bisher immer davon aus, dass ein xml-Parser nichts anderes macht, als den Inhalt eines xml-Dokuments in sein eigenes Speichermodell (wie auch immer das aussehen mag) liest. Wenn ich mir selbst einen Parser schreiben würde, dann würde ich das zumindest auf diese Weise machen, d. h. die .xml-Datei wie als Text-Datei betrachten und mir die Knoten, die Struktur usw. mit Listen o. ä. in den Speicher einlesen (mit einer Methode wie LoadFromFile) und wenn ich dann mit Methoden wie "GetNode(Integer)" o. ä. würde ich dann in meinem Speichermodell operieren. Insofern ist mir nicht ganz klar, warum das Arbeiten direkt mit xml-Dateien/xml-Dokumenten langsamer sein soll.

Aber mir fällt auch gerade auf, dass wir durch diese xml-Geschichte vom eigentlichen Thema abkommen

Es ist nicht gesagt, dass der alles im Speicher halten muss, kann ja. Um das herauszufinden, müsstest du dir die Implementierung ansehen.

Egal, wie und was, mit ein paar leichtgewichtigen Klassen kannst du die Struktur wesentlich einfacher abbilden und musst nicht den ganzen XML-Ballast mit dir herumschleppen.

Statt dich hier durchzukämpfen um ein Buch anzuhängen:

XML-Code:

<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
  <newbooks>
    <book category="COOKING"/>
    <book category="CHILDREN"/>
    <book category="WEB"/>
    <book category="WEB"/>
  </newbooks>
  <usedbooks>
    <book category="WEB"/>
    <book category="COOKING"/>
    <book category="MISC"/>
  </usedbooks>
</bookstore>

erstellst du dir (hier zwei) Klassen um die benötigte Struktur abzubilden:

Delphi-Quellcode:

TBook = class
  property Category: string;
end;

TBookstore = class
  property NewBookes: TList<TBook>;
  property UsedBooks: TList<TBook>;
end;

Und dann hast du einen Serializer/Desrializer, der dann beim Import/Export zu Tragen kommt:

Delphi-Quellcode:

// Holen
LBookstore := TXmlSerializer.Deserialize<TBookstore>( XmlData );

// Wildeste Verarbeitungen durchführen
LBookstore.NewBooks.Add( TBook.Create() );

// Und so bekommen wir das wieder in eine XML-Datei
TXmlSerializer.Serialize( LBookstore, XmlData );

Nur so vom Anschauen: Was ist deiner Meinung nach schneller (und sogar noch einfacher) in der Verarbeitung?

[Dejan Vu]

Tippfehler: Statt property NewBookes: TList<TBook>; lieber property NewBooks: TList<TBook>; .

[Scurra]

@alda: Danke für die kurze Einführung. Es hat noch etwas gedauert, bis ich verstanden habe, in welcher Weise man die Such-Anweisungen in den Delphi-Code einbinden muss. Sind die Anfragen mit XPath denn im Allgemeinen schneller als mit (den meisten) anderen Xml-Parsern wie z. B. TXmlDocument?

Zitat:

Nur so vom Anschauen: Was ist deiner Meinung nach schneller (und sogar noch einfacher) in der Verarbeitung?

Ich gehe mal davon aus, dass es eine rethorische Frage ist, denn so sieht dein Code natürlich schneller aus. Allerdings ist dein Code weniger allgemein. Wenn man nun ein anderes xml-Dokument hätte, dann müsste/sollte man andere Klassen bauen. Ich würde es folgendermaßen aufbauen:

Delphi-Quellcode:

TXmlNode = class
private
  FText: string;
  FAttributes: TDictionary<string, string>;
  FChildNodes: TList<TXmlNode>;
  ...
end;

TXmlDoc = class
private
  FRoot: TXmlNode
public
  LoadFromFile(aFileName: string);
  SaveToFile(aFileName: string);
end;

Man müsste dann eben noch Properties zu den Feldern ergänzen und Methoden zum Durchsuchen anbieten. Der Code soll jetzt ja auch nur meine Idee darstellen. In LoadFromFile müsste dann der Wurzel-Knoten inkl. aller Childnodes etc. eingelesen werden. Wenn man es sich ganz einfach machen möchte, verwendet man hier einfach einen bereits vorhandenen Parser (wie z. B. NativeXml, TXmlDocument o. ä.) und liest dann lediglich alle Daten in "meine" Struktur ein.

@Dejan Vu: Ich habe den Tippfehler überlesen

[alda]

Zitat von Scurra:

@alda: Danke für die kurze Einführung. Es hat noch etwas gedauert, bis ich verstanden habe, in welcher Weise man die Such-Anweisungen in den Delphi-Code einbinden muss. Sind die Anfragen mit XPath denn im Allgemeinen schneller als mit (den meisten) anderen Xml-Parsern wie z. B. TXmlDocument?

Zur tatsächlichen Geschwindigkeit kann ich nichts sagen, da ich das bisher nie evaluieren musste (bisher gab es keine Notwendigkeit dafür). Ich persönlich verwende dafür auch immer die Winapi.Msxml Implementierung. Das müsstest Du dann für deinen Anwendungsfall evaluieren bzw einfach mal debuggen, wo bei NativeXML ide Zeit verloren geht und warum.

Zitat von Scurra:

Ich gehe mal davon aus, dass es eine rethorische Frage ist, denn so sieht dein Code natürlich schneller aus. Allerdings ist dein Code weniger allgemein. Wenn man nun ein anderes xml-Dokument hätte, dann müsste/sollte man andere Klassen bauen.

Logisch, wenn sich das korrespondierende XML ändert, muss sich natürlich auch die Zugriffsklasse ändern.

Zitat von Scurra:

Ich würde es folgendermaßen aufbauen:

Delphi-Quellcode:

TXmlNode = class
private
  FText: string;
  FAttributes: TDictionary<string, string>;
  FChildNodes: TList<TXmlNode>;
  ...
end;

TXmlDoc = class
private
  FRoot: TXmlNode
public
  LoadFromFile(aFileName: string);
  SaveToFile(aFileName: string);
end;

Man müsste dann eben noch Properties zu den Feldern ergänzen und Methoden zum Durchsuchen anbieten. Der Code soll jetzt ja auch nur meine Idee darstellen. In LoadFromFile müsste dann der Wurzel-Knoten inkl. aller Childnodes etc. eingelesen werden. Wenn man es sich ganz einfach machen möchte, verwendet man hier einfach einen bereits vorhandenen Parser (wie z. B. NativeXml, TXmlDocument o. ä.) und liest dann lediglich alle Daten in "meine" Struktur ein.

Diese Ansatz wäre allerdings wieder allgemein und "untypisiert" (das macht ja schon jede XML-Lib so oder ähnlich). Das Beispiel von Sir Rufo ist typisiert auf die von dir verwendete XML-Struktur und ermöglicht dir einen objektorientierten Umgang mit den Daten in Form von Klassen und Objekten - man sieht also von Außen z.B. garnicht, dass diese Daten am Ende in einem XML landen. Vielleicht übersehe ich aber auch nur etwas in deinem Beispiel

[Sir Rufo]

@Scurra

Natürlich ist mein Code nicht mehr allgemein, sondern eben speziell.

Wenn du aber eine Anwendung schreibst, die in einer XML-Datei bestimmte Strukturen erwartet, kannst du dann jede allgemeine XML-Datei verwenden oder auch nur spezielle?

Wenn ich eine Kokosnuss essen möchte, dann kann ich mir

a) Zähne und Kiefer aus Titan einbauen lassen und kann dann sogar zum Nachtisch an einem T-Träger knabbern - wie praktisch

oder

b) mit geeignetem Hilfsmittel (z.B. Hammer) die Kokosnuss in eine leicht zu konsumierende Form umwandeln

Was ich weder bei a) oder b) hinbekomme ist natürlich der umgekehrte Weg zurück zur Kokosnuss.

[Scurra]

Ok, ich habe es vorher wohl falsch verstanden. Ich dachte, dass man durch solch eine Struktur, wie ich sie in meinem letzten Beitrag beschrieben habe, schneller arbeiten kann, als wenn man sich ein xml-Dokument nur z. B. mittels TXmlDocument im Speicher hält. Im Nachhinein denke ich, dass ich vllt. etwas naiv war, denn wenn man es so schneller implementieren könnte, dann hätte es sicherlich schon jemand gemacht

Jetzt habe ich aber die Idee verstanden, Strukturen zu verwenden, die speziell auf bestimmte xml-Dateien zugeschnitten sind, zu verwenden, um sich dadurch Zeit zu sparen.

Wieder etwas dazu gelernt Danke euch beiden!