Einfachere Methode, um an XML-Daten zu kommen?

[mensch72]

ich denke du willst einfach aus:

Code:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body>
    <u:GetCommonLinkPropertiesResponse xmlns:u="urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1">
      <NewWANAccessType>DSL</NewWANAccessType>
      <NewLayer1UpstreamMaxBitRate>0</NewLayer1UpstreamMaxBitRate>
      <NewLayer1DownstreamMaxBitRate>0</NewLayer1DownstreamMaxBitRate>
      <NewPhysicalLinkStatus>Down</NewPhysicalLinkStatus>
    </u:GetCommonLinkPropertiesResponse>
  </s:Body>
</s:Envelope>

nur die reinen "Daten" haben:

Code:

      DSL
      0
      0
      Down

Das klappt sogar per MicroControler ohne viel RAM... man beginnt im XML ab "<" einfach alles bis ">" zu ignorieren!
Wenn man weiß wie das "oft/hoffentlich konstante" XLS Format aufgebaut ist, dann klappt diese sehr simple Herangehensweise!

Wenn so doch einige wichtige Steuerinfortmationen zu den reinen Daten verloren gehen, dann filtere man diese vorher getrennt.
Auch wenn das nicht versionsstabil und selbstsicher bei Änderungen ist, diese simple Variante schlägt in der Praxis in bekannten Umfeld oft alle baumbasieren FullXML Parser!

[Dalai]

Zitat von mensch72:

ich denke du willst einfach aus:
[...]
nur die reinen "Daten" haben:

Korrekt. Das sagt ja aber nichts darüber aus, wie diese Daten vorliegen, woher sie kommen; eine Datei ist anders zu behandeln als ein String. Und ich schrieb ja im OP schon

Zitat:

Es gibt noch andere XML-Dokumente, die analog zu diesem aufgebaut sind - Rückgabe einer Fritzbox eben

Zitat von mjustin:

* Der Funktion GetEnvelope(Doc: IXMLDocument) kann ein XML Document übergeben werden dass nicht als Datei "auf der Platte" vorliegen muss.

Oh, das hab ich in der Tat übersehen . Mal sehen, was ich daraus basteln kann.

Zitat:

* Namespaces werden unterstützt

OK, ich führe es wohl doch noch etwas weiter aus, wo ich Probleme hatte, und warum ich diese Frage stellte. Ich begann mit LXMLDoc.ChildNodes['s:Envelope'].ChildNodes['s:Body'].ChildNodes['u:GetCommonLinkPropertiesResponse'] , bekam aber immer eine Exception mit dem Inhalt "Node ... not found". Der Node war nachvollziehbar vorhanden, zumal der Zugriff via ChildNodes[0] einwandfrei funktionierte. Also grenzte ich etwas ein, und fand heraus, dass das letzte ChildNodes der Auslöser der Exception war. Irgendwann schwante mir, dass die verschiedenen Namespaces der Knoten damit zu tun haben müssten. Deswegen die Änderung auf FindNode mit leerem Namespace wie im OP zu sehen.

Da ich in dem vom Wizard generierten Code außer der Konstanten TargetNamespace keinerlei Namespaces sehe, frage ich mich, wie das funktionieren soll, wenn Body und der Datenknoten darunter jeweils andere Namespaces verwenden. Geht das automatisch oder muss ich das explizit angeben, und wenn ja wie?

Zitat:

* das "Mehr an Code" wird ja nur einmal, automatisch, generiert. Ab dann spart es sehr viel Zeit für das Schreiben des Codes, um auf die gewünschten Elemente zuzugreifen

Stimmt, aber durch die bereits im OP genannte Auslagerung in eine Methode hab ich auch kaum mehr Schreibarbeit - ohne dieses Mehr an Code. OK, wahrscheinlich ist es nicht so "typsicher" wie der Code des Wizard.

Grüße
Dalai

[Dalai]

Meine Befürchtung hat sich bestätigt: der Code funktioniert so nicht, weil die Namespaces nicht passen.

Delphi-Quellcode:

uses ..., GetCommonLinksPropertiesResponse;

var
  LXMLBody: IXMLBodyType;
  LXMLGCLP: IXMLGetCommonLinkPropertiesResponseType;
begin
    LXMLDoc:=      FRITZBox_SOAPDownload(FRITZBOX_UPNP_WANCommonIFC1_URL, FRITZBOX_URN_WANCOMMONIFC, cGCLP, False);
    LXMLBody:= GetCommonLinkPropertiesResponse.GetEnvelope(LXMLDoc).Body;
    LXMLGCLP:= LXMLBody.GetCommonLinkPropertiesResponse;

Bei der letzten Zeile rummst es mit "Node ... not found". Wahrscheinlich noch wichtig: Die Exception kommt nur, wenn LXMLDoc.ReadOnly:= True und LXMLDoc.Options den Wert doNodeAutoCreate nicht beinhaltet. Trifft beides nicht zu, werden leere Knoten in LXMLDoc angelegt, und logischerweise kommen so auch keine Werte für die Eigenschaften NewWANAccessType & Co zurück.

Die Sache muss also anders aufgebaut sein, damit sie funktioniert und den geänderten Namespace berücksichtigt. Da sind wir wieder zurück beim FindNode, oder wie würde man das normalerweise machen, wenn nicht damit?

Grüße
Dalai

[bra]

Du kannst auch einfach ohne FindNodes die Unter-Nodes rekursiv durchgehen und nach dem NodeNamen prüfen, also jeweils ChildNodes[0] bis [x] und davon wieder die ChildNodes[x]. Wäre das nicht einfacher?

[Dalai]

Da die Daten immer in derselben Ebene zu finden sind, habe ich mich entschieden, bei meiner Funktion zu bleiben. Nach etwas Überarbeitung sieht diese nun so aus:

Delphi-Quellcode:

function ValueOfElement(const AXMLNode: IXMLNode; const AResponseName, ANodeName: string): string;
var
  LNode: IXMLNode;
begin
    Result:= '';
    if Assigned(AXMLNode) then begin
        if AXMLNode.HasChildNodes then begin
            { ChildNodes[0] = s:Body }
            LNode:= AXMLNode.ChildNodes[0];
            if LNode.HasChildNodes then begin
                { u:<ResponseName> }
                LNode:= LNode.ChildNodes.FindNode(AResponseName, '');
                if Assigned(LNode) then begin
                    if LNode.HasChildNodes then begin
                        LNode:= LNode.ChildNodes.FindNode(ANodeName, '');
                        if Assigned(LNode) then begin
                            if LNode.IsTextElement then
                                Result:= LNode.Text;
                        end;
                    end;
                end;
            end;
            LNode:= nil;
        end;
    end;
end;

Der Aufruf erfolgt dann z.B. so:FConfigDSL.WANAccessType:= ValueOfElement(LXMLDoc.DocumentElement, FBACTION_RESPONSE_GCLP, 'NewWANAccessType'); wobei const FBACTION_RESPONSE_GCLP = 'GetCommonLinkPropertiesResponse'; ist. Mit den vielen if-Bedingungen sollte so ziemlich alles abgefangen sein, was schiefgehen könnte. Wenn eine andere Knotentiefe vorliegt, klappt das natürlich nicht mehr. Aber darum muss ich mir derzeit keine Gedanken machen, weil ich sowieso noch mitten in der Testphase stecke.

Eine rekursive Funktion habe ich zwar auch geschrieben (um Daten aus einem anderen Dokument zu ermitteln), habe es aber noch nicht hinbekommen, auf den Knotennamen des Knotens und den/die Knotennamen der Kinder desselben zu prüfen, ohne den Code massiv aufzublähen oder kompliziert zu machen. Baumstruktur ist nicht so ganz einfach.

Grüße
Dalai