![]() |
Re: MSXML-Parser, aber welcher?
Die Codes dort genannten Codes sollten sich doch auch in Delphi umsetzen lassen?
![]() ![]() |
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... |
Re: MSXML-Parser, aber welcher?
Zitat:
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) |
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 |
Re: MSXML-Parser, aber welcher?
Zitat:
Zitat:
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 |
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. |
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 |
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. |
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. |
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:
Meine Fragen:
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; 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 01:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz