Mit XPath Knoten auswählen liefert alle Knotenwerte

[Luckie]

Zitat:

Zitat von Sascha L

Am Anfang ist es normal beim Umstieg von Delphi nach C#, dass man die alten Gewohnheiten weiterpflegt. Wenn man aber erstmal das Konzept von C# verstanden hat, wird man nie wieder Delphi benutzen wollen ;-)

Das fürchte ich auch. Mit dem VS läuft das alles so schön geschmeidig von der Hand, macht richtig Spass. Delphi kommt einem da fast etwas unbeholfen und schwerfällig vor. :?

[Khabarakh]

Sascha, ich kann deine Argumentation leider nicht ganz nachvollziehen ;) . Erst einmal ist XPathDocument genau für solche Zwecke gedacht, bei denen man kein fettes DOM benötigt, sondern nur einen kleinen schnellen read-only Parser.

Zitat:

Zitat von Sascha L

Geht mich ja nichts an, aber "MoveNext" ist absolut unschön und fehlerträchtig. Überhaupt das durchgehen durch den XML-Baum.

Wer sagt, foreach funktioniere nur mit XmlDocument ;) ? Hier eine etwas schönere Variante meines Codes:

Code:

      static void XPathDoc()
      {
         var productList = new List<ProductItem>();

         var nav = new XPathDocument(new StringReader(xml)).CreateNavigator();
         foreach (XPathNavigator itemNav in nav.Select("/Catalog/Categories/Category[@name=\"" + name + "\"]/items/*")) {
            ProductItem prodItem = new ProductItem {
               Name = itemNav.GetAttribute("name", ""),
               ShortDescription = itemNav.SelectSingleNode("shortdescription").Value,
               LongDescription = itemNav.SelectSingleNode("longdescription").Value,
               ItemIdentifier = itemNav.SelectSingleNode("itemIdentifier").Value,
            };
            productList.Add(prodItem);
         }
      }

Den Code könnte man natürlich auch auf das Element-fehlt-Handling von dir umstellen, aber das muss Luckie wissen.
Und ich sehe auch nicht, dass du im Gegensatz zu uns etwas anderes machst als "das durchgehen durch den XML-Baum", oder wo du "komplett auf XPATH" setzt - genaugenommen sinds bei uns doch sogar 3 XPaths mehr :mrgreen: .

Zitat:

Zitat von Sascha L

Aber da selektiert man mit XPATH die Nodes oder den Node, [...]

Wie ich schon schrob, man benutzt heute eher XLinq - wenns einem gefällt :stupid: .

Code:

      static void LinqToXML()
      {
         var cat = XElement.Parse(xml).Element("Categories").Elements("Category").Single(node => node.Attribute("name").Value == name);

         var productList =
         (from item in cat.Element("items").Elements()
          select new ProductItem {
             Name = item.Attribute("name").Value,
             ShortDescription = item.Element("shortdescription").Value,
             LongDescription = item.Element("longdescription").Value,
             ItemIdentifier = item.Element("itemIdentifier").Value
          }).ToList();
      }

Manchen dürfte die Verbosity nicht gefallen, aber man kann immer noch entgegnen "hmmm, und wo genau in deinem Code ist nun ein Schutz gegen XPath-Injection?" :mrgreen: . Und in Sachen Performance ist nicht alles von 3.0+ miserabel...

Code:

   1. LinqToXML                         132 µs
2. XmlDoc                            186 µs
3. XPathDoc                          245 µs

Getestet mit 20 Produkten. Bei wenigern wird XPathDocument zweiter, mein Eingangssatz über dessen Performance dürfte damit trotzdem widerlegt sein :stupid: .

Um die Verwirrung zu komplettieren, sollte man noch Linq To XSD im Auge behalten. 6 Wege zum gleichen Ziel, _das_ ist .Net!

[Sascha L]

Ja, der erste Code von dir ist nun besser. Natürlich fehlt noch - wie du selbst sagtest - die Überprüfung, ob die Nodes und Attribute überhaupt existieren.

Aber der Urpsprungscode mit MoveNext() war nicht so gut, da man ja nie weiß wo ma da landet. Alleine schon wegen des "*" am Ende der XPath-Abfrage würde man theoreitsch alle möglichen Child-Nodes durchgehen, obwohl man ja nur "item" in "items" haben will.

Auch wenn ich die XML-Datei selbst erstelle, würde ich das ganze immer allgemein programmieren. Da ist man dann flexibler, wenn man später doch noch mal das ein oder andere an der XML-Datei ändert - was meines erachtens zu 99% der Fall sein wird :D

Zitat:

Zitat von Luckie

Das fürchte ich auch. Mit dem VS läuft das alles so schön geschmeidig von der Hand, macht richtig Spass. Delphi kommt einem da fast etwas unbeholfen und schwerfällig vor. :?

Wieso "fürchtest" du das auch? Delphi ist nun mal leider ausgestorben, auch wenn es viele nicht wahrhaben wollen. Delphi war wirklich ne tolle Sprache. Ich habe damit fast 10 Jahre programmiert, aber mittlerweile ist sie einfach zu alt. Delphi ist nicht mehr leistungsstark, bietet keine modernen Features und das Angebot an Komponenten von Drittherstellern kann man an einer Hand abzählen. Des Weiteren weiß jeder, wieder schlecht die IDE ist.

In meinem Bekanntenkreis habe ich bisher noch jeden Delphi-User dazu bringen können, dauerhaft zu C# zu wechseln und bei uns in der Firma haben wir diesen Schritt nun auch vollzogen.

Bereits in 5min wird einem klar, dass C# und VS besser ist:
- Visual Studio ist SOFORT gestartet. Man brauch nicht mehr wie beim Developer Studio erst noch ne Tasse Kaffee trinken
- Die Auswahl an Controls von Fremdanbietern ist überwältigend
- Wenn ich überlege, wie oft ich umständlich Klassen in Delphi anlegen musste und total viel Code schreiben musste, nur um eine Liste von einem eigenen Typ zu haben! In .NET nimmt man einfach List<TYP> und gut ist. Das ist eines der Killerkriterien!
- foreach ist super
- die ganzen Konvertierungen á la ".ToString()
- settings.settings! NIE wieder Registry, Ini und man muss sich nie wieder Gedanken machen wie man bestimmte Objekte speichern und laden kann
- Man hat viel leicht Zugriff auf bestimmte APIs, Funktionen des Betriebsystems, etc.
- im MSDN befindet sich zu allem auch ein C#-Beispiel (Wie oft musste man mühsehlig den Code nach Delphi übersetzen?!)
- Datenbankanbindung, Lynq, usw
- .NET ist immer auf dem neuesten Stand: z.B. Vista-Unterstützung (Glass-Effekte, etc.)
- Ich programmiere EIN Programm, welches ohne weiteres auf dem PC und auf Windows Mobile (CompactFramework) läuft!!!

Da wir grad in der Firma ein Programm in .NET komplett neu machen, können wir sehr schön den Unterschied sehen: Der C#-Code ist nur ein Bruchteil so lang wie jener von Delphi damals.

[Luckie]

Zitat:

Zitat von Khabarakh

Wer sagt, foreach funktioniere nur mit XmlDocument ;) ? Hier eine etwas schönere Variante meines Codes:

Code:

      static void XPathDoc()
      {
         var productList = new List<ProductItem>();

         var nav = new XPathDocument(new StringReader(xml)).CreateNavigator();
         foreach (XPathNavigator itemNav in nav.Select("/Catalog/Categories/Category[@name=\"" + name + "\"]/items/*")) {
            ProductItem prodItem = new ProductItem {
               Name = itemNav.GetAttribute("name", ""),
               ShortDescription = itemNav.SelectSingleNode("shortdescription").Value,
               LongDescription = itemNav.SelectSingleNode("longdescription").Value,
               ItemIdentifier = itemNav.SelectSingleNode("itemIdentifier").Value,
            };
            productList.Add(prodItem);
         }
      }

Den Code könnte man natürlich auch auf das Element-fehlt-Handling von dir umstellen, aber das muss Luckie wissen.

Jupp, die wird benötigt. Ich habe das jetzt mal auf deinen obigen Code umgestellt. Wie kann ich da reagieren, wenn ein Element fehlt?

[Sascha L]

Genau wie bei meiner Variante:

Code:

XMLNode Node = itemNav.SelectSingeNode("...");
if (Node != null)

[Luckie]

OK, dann habe ich es ja richtig gemacht.

[Luckie]

Jetzt habe ich schon wieder das Problem. :wall:

XML-Datei:

XML-Code:

<businessRelationship id="1">
    <businessSupplier id="1">
        <company>
            <companyName>DATAWERK</companyName>
            <websiteList>
                <website primary="true">www.datawerk.de</website>
                <website>www.datawerk.com</website>
            </websiteList>
            <addressList>
                <address primary="true" id="1">
                    <street>Friedrich-Ebert-Straße</street>

Und ich will jetzt das Element [i]companyName" auslesen:

Code:

        public void GetCompanyDetails()
        {
            try
            {
                XPathNavigator nav = pathDoc.CreateNavigator();
                XPathNodeIterator nodeIter = nav.Select("company");
                nodeIter.MoveNext();
                XPathNodeIterator companyItem = nodeIter.Current.Select("companyName");
                companyItem.MoveNext();
                if (companyItem != null)
                {                   
                    companyName = companyItem.Current.Value;                    
                }
            }
            catch(Exception e)
            {
                throw(e);
            }
        }

Aber ich bekomme wieder die Werte aller Unterelemente in einem String. :evil:

[Khabarakh]

Der erste XPath kann so nicht funktionieren: Ohne angegebene Achse sucht er in den Kindern des derzeitigen Knotens, der Wurzel. Und dort gibt es kein "company". Was ich allerdings noch nicht verstanden habe: Anstatt eine Exception zu werfen oder ähnliches, gibt er einfach die Wurzel zurück :shock: ? Damit zeigt Current im inneren Block immer noch auf die Wurzel und du bekommst den Text des gesamten Dokuments zurück.
Als ersten Ausdruck könntest du stattdessen "//company" benutzen. Ich würde aber zur Sicherheit den vollen Pfad von der Wurzel aus angegben, also "/A/B/...". Wie du siehst, bin ich aber auch nicht ganz per Du mit XPath, und bei solchen Schauermärchen habe ich es in nächster Zeit auch nicht vor :duck: .

[Luckie]

Oh Gott, es funktioniert mit "//". Was hat den das für eine Bedeutung?

[marabu]

Hallo Michael,

der Double-Slash erweitert den Suchraum auf einen SubTree. "/root/test" findet alle Knoten "test" auf level 2, "//test" findet alle Knoten "test", egal auf welchem Level.

Freundliche Grüße