Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   XML (https://www.delphipraxis.net/46-xml/)
-   -   Delphi MSXML-Parser, aber welcher? (https://www.delphipraxis.net/143611-msxml-parser-aber-welcher.html)

himitsu 19. Nov 2009 13:10

Re: MSXML-Parser, aber welcher?
 
Die Codes dort genannten Codes sollten sich doch auch in Delphi umsetzen lassen?
http://msdn.microsoft.com/en-us/library/ms753779.aspx
http://social.msdn.microsoft.com/for...f-653691edc4cc

Alaitoc 19. Nov 2009 13:19

Re: MSXML-Parser, aber welcher?
 
Achso ja gut , mehrere Validierungsfehler zu ermitteln sind nicht "mehr" das Problem.
Da war noch das Problem das ich soweit ich mich recht erinner :gruebel: nicht die Position der Fehler ausgeben konnte...

Das Problem mit den mehreren Fehlern war bei dem Parsevorgang, also allgemeine XML-Kompatibilität. Da bricht MSXML ( eigentlich sinnvollerweise ) bei dem ersten Parsefehler halt ab und gibt nur diesen aus...wobei ich dabei am liebsten alle Parse-Fehler sehen würde...

Wenn ich z.b. eine neue Datei in meinem Editor erstelle und dort irgendwas reinklatsche, dann würde er mir nur den ersten Parse-fehler anzeigen und erst wenn ich den korrigiert habe den nächsten Fehler.
Natürlich könnte man sich da mit viel Aufwand etwas eigenes basteln...jedoch ist das zur Zeit leider nicht drin ^_^


Also

Parsefehler = Fehler während des Parsevorgangs.
Validierungsfehler = Fehler während der Validierung mit einem Schema.

MfG Alaitoc

Anmerkung an mich selbst: Erst immer alles ganz genau lesen...

himitsu 19. Nov 2009 13:40

Re: MSXML-Parser, aber welcher?
 
Zitat:

wobei ich dabei am liebsten alle Parse-Fehler sehen würde...
OK, daß er bei Parsefehlern abbricht ist schon OK, denn ansonsten würde man vermutlich Folgefehler erhalten, welche Keine sind oder einige andere Fehler könnten übersehn werden.
z.B. wenn ein > vergessen wurde oder zuviel vorhanden ist, dann stimmt danach fast nix mehr, vorallem bei den Node-Verschachtelungen.

War auch schon kurz davor, solche bei meinem himXML mit anzeigen zu wollen, aber hab es aus oben genanntem Grund dann gelassen.
Das Einzige wo sowas möglich/sinnvoll wäre, wenn es ein reparierender Parser wäre,
also einer, welcher Fehler versucht zu ignorieren und dann dieses entpsrechend zu behandeln/reparieren.
(wie z.B. die HTML-Parser den Browsern)

Alaitoc 19. Nov 2009 13:46

Re: MSXML-Parser, aber welcher?
 
Jepp stimmt schon, wäre halt nur schön gewesen wenn man es sich in gewisser Weise aussuchen könnte.
Naja manchmal kann man nicht alles haben ^^ ... habe es ja wenigstens hingekriegt das die Validierungsfehler
angezeigt wurden, wobei das auch viel Arbeit war ... zumindest nachträglich das Dokument mit denen zu verknüpfen ohne Änderungen an den Knoten zu machen. Jedoch fehlt da halt die Positionsangabe.

MfG Alaitoc

AndiOnline 20. Nov 2009 10:45

Re: MSXML-Parser, aber welcher?
 
Zitat:

Zitat von Alaitoc
Unter Delphi 2k9 kann man die Typbibiliothek über "Komponente\Komponente importieren" hinzufügen.
Einfach im Assistenten "Typbibliothek importieren" auswählen und dann nach MSXML suchen und die
gewünschte Version auswählen.

Damit sollte man zumindest mehr Möglichkeiten haben als mit der TXMLKomponente.
[/delphi]

Zitat:

Zitat von Alaitoc
Wenn man die TXML-Komponente verwendet ist es aber im Endeffekt egal welche MSXML Version man auf dem Rechner hat, solange man zumindest die 2.6er installiert hat. Sie bietet dafür aber auch meines Wissens nach nur wirklich die Standard - Funktionalitäten.

Ich benutze die TXMLDocument-Komponente und validiere damit die xml-Datei mit einem Schema. Über die Datenbindung (GetDocBinding) kann ich dann sehr einfach auf die Werte zugreifen. Das funktioniert auch soweit sehr gut.

Wenn ich das jetzt richtig verstanden habe :
Benutze ich die TXMLDocument-Komponente wird max. der MSXML4.0-Parser von Delphi verwendet (siehe Eingangspost).
Will ich MSXML6 verwenden, muss ich eine neue Typbibliothek importieren und Komponenten, bzw. Objekte aus dieser Datei verwenden.

Das heißt dann auch, ich muss in meinem Fall bei Verwendung der TXML-Komponente nur darauf achten, dass der Anwender am besten MSXML4.0 installiert hat (hier funktioniert die Validierung mit einem Schema), und muss eigentlich nicht auf MSXML 6.0 updaten (nach dem Motto : never change a running system...?)

Gruß Andi

himitsu 20. Nov 2009 12:57

Re: MSXML-Parser, aber welcher?
 
Um TXMLDocument mit MSXML 6.0 nutzen zu können müßte man doch nur irgendwie (z.B. über XML.DOMVendor) den CLASS_DOMDocument60 übergeben.
Die älteren Basisinterfaces dürften doch auf die neuere Version anwendbar sein ... nur daß eben einige Neuerungen nicht direkt nutzbar wären, da sie ja unbekannt sind.

Alaitoc 20. Nov 2009 15:53

Re: MSXML-Parser, aber welcher?
 
Genau theorethisch möglich, weil man ( eigentlich) aber nicht mehr Funktionen als mit der MSXML 4.0 Version hat, da da scheinbar die TXMLDocument - Komponente drauf aufgelegt ist, kann man sich das mit der MSXML 6.0 Version auch sparen.

Wirkliche Änderungen sollten dabei nicht sichtbar sein, weil die älteren Basisinterfaces ja nicht die neuen Funktionen kennen. Was ich mir vorstellen könnte und vielleicht irgendwo in meiner Linksammlung verborgen ist ^_° , dass es z.b. weniger Sicherheitslücken oder so gibt. Jedoch kann ich da atm nur spekulieren...

Mein Fazit: Im Endeffekt ist es bei der TXMLDocument - Komponente nicht nötig auf MSXML 6.0 umzusteigen.


MSXML 6.0 sollte nur interessant sein wenn man z.b. über die Typenbibliothek arbeitet und die neuen Funktionen benötigt.

MfG Alaitoc

shmia 23. Nov 2009 13:04

Re: MSXML-Parser, aber welcher?
 
Nach meinen Erfahrungen sind nur die Versionen 4 und 6 brauchbar.
Version 3 hat zu wenig Funktionalität und zuviele Bugs (z.B. funktioniert XMLHTTPRequest nicht immer richtig).
Bei MSXML 4.0 sollte man auf jeden Fall das SP3 installieren (und zuvor SP1 und SP2 deinstallieren).
Ohne Servicepack kann es passieren, dass z.B. das Attribut xmlns doppelt geschrieben wird,
was natürlich tödlich für den folgenden Parser ist.

stahli 10. Aug 2010 21:35

AW: MSXML-Parser, aber welcher?
 
Ich will das Thema nochmal aufgreifen:

Für meine ersten Versuche nutze ich derzeit eine TXMLDocument (da man die schnell mal auf den Designer ziehen kann :wink:).

Dann greife ich über eine Konvertierung mit XPath zu:
Delphi-Quellcode:
(XML.DOMDocument as IDOMNodeSelect).selectNode(XPath).childNodes[0].nodeValue := FieldValue;


Dabei gibt es zwei Probleme:
- es gibt keine Eigenschaft ".Text"
- es darf kein "Leerstring" als Text gespeichert sein, dann gibt es einen Zugriffsfehler
- es gibt keine ParentNodes etc

Was ist die beste Lösung, die diese Probleme vermeidet? IXMLDOMDocument?
Ich möchte XPath und Leertexte nutzen und möglichst in den Knoten "navigieren".

Die Datei muss nur zum Speichern und Laden meiner Daten dienen, externe Konventionen spielen für mich keine Rolle.

stahli 11. Aug 2010 21:05

AW: MSXML-Parser, aber welcher?
 
Ich beschäftige mich jetzt schon ein paar Tage mit XML-Parsern aber das ist schon etwas verwirrend ;-(

TXMLDocument ist recht einfach und komfortabel zu nutzen, bietet aber wohl auch einige Einschränkungen.
Daher habe ich es jetzt mit IXMLDOMDocument versucht.

Hier sind einmal die wesentlichen Punkte zu sehen:

Delphi-Quellcode:
uses
  msxml;
...
var
  xml: IXMLDOMDocument = nil;
  xmlNode, xmlRootNode: IXmlDomNode;
  xmlNodeList: IXmlDomNodeList;
...
  xml := coDOMDocument.Create; // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
...
procedure CreateNewDatabase;
var
  xmlRoot: IXMLDomElement;
  xmlPI: IXMLDomProcessingInstruction;
const
  CodePage = 'UTF-8';
begin
  xml := CoDOMDocument.Create; // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
//  xml.PreserveWhiteSpace := True; //??
  xmlPI := xml.CreateProcessingInstruction('xml', Format('version="1.0" encoding="%s"', [codepage]));
  xml.AppendChild(xmlPI);
  xmlRoot := xml.CreateElement('Wurzelknoten');
  xml.AppendChild(xmlRoot);
  xml.Save(DatabaseFileName);
end;
...
procedure OpenXml;
begin
  xml.Load(DatabaseFileName);
  xmlRootNode := xml.DocumentElement;
end;
...
function GetCompleteXPath(XPath, NodeName, IDName, IDValue, FieldName: String): String;
var
  S: String;
begin
  S := '';
  if (NodeName <> '') and (FieldName <> '') then
  begin
    S := XPath + NodeName;
    if (IDName <> '') and (IDValue <> '') then
      S := S + '[@' + IDName + '="' + IDValue + '"]';
    S := S + '/' + FieldName;
  end;
  Result := S;
end;
...
function xmlRead (XPath, NodeName, IDName, IDValue, FieldName: String): String;
var
  Node: IXmlDomNode;
begin
  XPath := GetCompleteXPath(XPath, NodeName, IDName, IDValue, FieldName);
  try
    Node := xmlRootNode.SelectSingleNode(XPath);
  except
    Node := nil;
  end;
  if Assigned(Node) then
    Result := Node.Text
  else
    Result := '';
end;
...
procedure xmlWrite(XPath, NodeName, IDName, IDValue, FieldName, FieldValue: String);
var
  Node: IXmlDomNode;
begin
  XPath := GetCompleteXPath(XPath, NodeName, IDName, IDValue, FieldName);
  try
    Node := xmlRootNode.SelectSingleNode(XPath);
  except
    Node := nil;
  end;
  if Assigned(Node) then
    Node.Text := FieldValue
  else
    AutomatischerNeuerKnotenAnDer-XPath-Position!? // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  RefreshXmlCtrlList;
end;
Meine Fragen:
1) Was ist an coDOMDocument60.Create besser? Und wo finde ich das???
2) Kann ich es irgendwie bewerkstelligen, dass beim Schreiben eines Textes (der Knoten ist mit XPath angegeben) AUTOMATISCH der bzw. die fehlenden Knoten erzeugt werden?
3) Gibt es alternativ Funktionen, die fehlende Knoten anhand eines XPath nachträglich generieren?

Das Lesen eines nicht existierenden Knotens liefert mit meiner xmlRead einfach '' zurück.
Jetzt suche ich eine Möglichkeit immer unproblematisch neue Inhalte in die XML zu schreiben (ähnlich wie bei einer Ini, da wird ja auch ggf. ein Eintrag neu erzeugt).


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:17 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz