Ich bin lange genug in der Frontend-Entwicklung tätig, um im Laufe der Jahre einen Trend zu erkennen: Jüngere Entwickler arbeiten mit einem neuen Paradigma der Programmierung, ohne den historischen Kontext davon zu verstehen. Es ist natürlich völlig verständlich, etwas nicht zu wissen. Das Internet ist ein sehr großer Ort mit vielfältigen Fähigkeiten und Spezialgebieten, und wir wissen nicht immer, was wir nicht wissen. Lernen in diesem Bereich ist eine fortlaufende Reise und nicht etwas, das nur einmal geschieht und endet. Ein typisches Beispiel: Jemand in meinem Team hat gefragt, ob es möglich sei, festzustellen, ob Benutzer von einer bestimmten Registerkarte in der Benutzeroberfläche weg navigieren. Ich habe auf das beforeunload-Ereignis von JavaScript hingewiesen. Aber diejenigen, die sich schon einmal damit befasst haben, wissen, dass dies möglich ist, da sie auf anderen Websites mit Warnungen über nicht gespeicherte Daten konfrontiert wurden, für die „Beforeunload“ ein typischer Anwendungsfall ist. Zur Sicherheit habe ich meinen Kollegen auch auf die Ereignisse „pageHide“ und „visibilityChange“ hingewiesen. Woher wusste ich davon? Weil es in einem anderen Projekt aufgetaucht ist, nicht weil ich es beim ersten Erlernen von JavaScript studiert habe. Tatsache ist, dass moderne Frontend-Frameworks auf den Schultern der Technologiegiganten stehen, die ihnen vorausgingen. Sie abstrahieren Entwicklungspraktiken, oft für eine bessere Entwicklererfahrung, die die Notwendigkeit reduziert oder sogar eliminiert, die traditionell wesentlichen Front-End-Konzepte zu kennen oder anzufassen, die wahrscheinlich jeder kennen sollte. Betrachten Sie das CSS Object Model (CSSOM). Man könnte erwarten, dass jeder, der mit CSS und JavaScript arbeitet, über umfangreiche praktische CSSOM-Erfahrung verfügt, aber das wird nicht immer der Fall sein. Es gab ein React-Projekt für eine E-Commerce-Site, an dem ich gearbeitet habe, bei dem wir ein Stylesheet für den aktuell ausgewählten Zahlungsanbieter laden mussten. Das Problem bestand darin, dass das Stylesheet auf jeder Seite geladen wurde, obwohl es nur auf einer bestimmten Seite wirklich benötigt wurde. Der damit beauftragte Entwickler hatte noch nie ein Stylesheet dynamisch geladen. Auch dies ist völlig verständlich, wenn React den traditionellen Ansatz, den Sie vielleicht gewählt haben, abstrahiert. Das CSSOM ist wahrscheinlich nichts, was Sie in Ihrer täglichen Arbeit benötigen. Aber es ist wahrscheinlich, dass Sie irgendwann einmal damit interagieren müssen, auch in einem einmaligen Fall. Diese Erfahrungen haben mich dazu inspiriert, diesen Artikel zu schreiben. Es gibt viele vorhandene Webfunktionen und -technologien, mit denen Sie in Ihrer täglichen Arbeit möglicherweise nie direkt in Berührung kommen. Vielleicht sind Sie noch relativ neu in der Webentwicklung und kennen sie einfach nicht, weil Sie in der Abstraktion eines bestimmten Frameworks versunken sind, für das Sie keine tiefen oder überhaupt keine Kenntnisse darüber haben müssen. Ich spreche speziell von XML, von dem viele von uns wissen, dass es sich um eine alte Sprache handelt, die HTML nicht völlig unähnlich ist. Ich spreche dies an, weil in der WHATWG kürzlich in Diskussionen darüber diskutiert wurde, dass ein erheblicher Teil des XML-Stacks, der als XSLT-Programmierung bekannt ist, aus Browsern entfernt werden sollte. Dies ist genau die Art von älterer, vorhandener Technologie, die wir seit Jahren haben und die für etwas so Praktisches wie die CSSOM-Situation, in der sich mein Team befand, verwendet werden könnte. Haben Sie schon einmal mit XSLT gearbeitet? Mal sehen, ob wir uns stark auf diese ältere Technologie stützen und ihre Funktionen außerhalb des XML-Kontexts nutzen, um aktuelle Probleme der realen Welt anzugehen. XPath: Die zentrale API Die wichtigste XML-Technologie, die außerhalb einer reinen XML-Perspektive vielleicht am nützlichsten ist, ist XPath, eine Abfragesprache, die es Ihnen ermöglicht, jeden Knoten oder jedes Attribut in einem Markup-Baum mit einem Wurzelelement zu finden. Ich habe eine persönliche Vorliebe für XSLT, aber das hängt auch von XPath ab, und persönliche Zuneigung muss bei der Rangfolge der Wichtigkeit außer Acht gelassen werden. Das Argument für die Entfernung von XSLT erwähnt XPath nicht, daher gehe ich davon aus, dass es immer noch zulässig ist. Das ist gut, denn XPath ist die zentrale und wichtigste API in dieser Suite von Technologien, insbesondere wenn man versucht, etwas zu finden, das außerhalb der normalen XML-Nutzung verwendet werden kann. Dies ist wichtig, da CSS-Selektoren zwar zum Auffinden der meisten Elemente auf Ihrer Seite verwendet werden können, jedoch nicht alle. Darüber hinaus können CSS-Selektoren nicht verwendet werden, um ein Element anhand seiner aktuellen Position im DOM zu finden. XPath kann. Nun kennen einige von Ihnen, die dies lesen, vielleicht XPath, andere vielleicht nicht. XPath ist ein ziemlich großes Technologiegebiet, und ich kann in einem einzigen Artikel wie diesem nicht wirklich alle Grundlagen vermitteln und Ihnen auch coole Dinge zeigen, die man damit machen kann. Ich habe tatsächlich versucht, diesen Artikel zu schreiben, aber die durchschnittliche Veröffentlichung im Smashing Magazine umfasst nicht mehr als 5.000 Wörter. Ich war schon bei mehr als2.000 Wörter, während die Grundlagen erst zur Hälfte durchgearbeitet sind. Also werde ich anfangen, coole Sachen mit XPath zu machen und Ihnen einige Links geben, die Sie für die Grundlagen verwenden können, wenn Sie diese Dinge interessant finden. Kombination von XPath und CSS XPath kann viele Dinge tun, die CSS-Selektoren beim Abfragen von Elementen nicht können. Aber CSS-Selektoren können auch ein paar Dinge tun, die XPath nicht kann, nämlich Elemente nach Klassennamen abzufragen.

CSS XPath .myClass /*[enthält(@class, „myClass“)]

In diesem Beispiel fragt CSS Elemente ab, die einen .myClass-Klassennamen enthalten. Währenddessen fragt das XPath-Beispiel Elemente ab, die eine Attributklasse mit der Zeichenfolge „myClass“ enthalten. Mit anderen Worten: Es wählt Elemente mit myClass in jedem Attribut aus, einschließlich Elementen mit dem Klassennamen .myClass – sowie Elemente mit „myClass“ in der Zeichenfolge, wie z. B. .myClass2. XPath ist in diesem Sinne umfassender. Also, nein. Ich schlage nicht vor, dass wir CSS wegwerfen und anfangen sollten, alle Elemente über XPath auszuwählen. Darum geht es nicht. Der Punkt ist, dass XPath Dinge tun kann, die CSS nicht kann und dennoch sehr nützlich sein könnte, auch wenn es sich um eine ältere Technologie im Browser-Stack handelt und auf den ersten Blick möglicherweise nicht offensichtlich erscheint. Lassen Sie uns die beiden Technologien zusammen nutzen, nicht nur, weil wir es können, sondern weil wir dabei etwas über XPath lernen und es zu einem weiteren Tool in Ihrem Stack machen – eines, von dem Sie vielleicht nicht wussten, dass es die ganze Zeit da war! Das Problem besteht darin, dass die Methode document.evaluate von JavaScript und die verschiedenen Abfrageauswahlmethoden, die wir mit den CSS-APIs für JavaScript verwenden, nicht kompatibel sind. Um uns den Einstieg zu erleichtern, habe ich eine kompatible Abfrage-API erstellt, allerdings habe ich mir zugegebenermaßen nicht viele Gedanken darüber gemacht, da es sich um eine Abweichung von dem handelt, was wir hier tun. Hier ist ein ziemlich einfaches Arbeitsbeispiel eines wiederverwendbaren Abfragekonstruktors: Siehe den Pen queryXPath [forked] von Bryan Rasmussen. Ich habe dem Dokumentobjekt zwei Methoden hinzugefügt: queryCSSSelectors (im Wesentlichen querySelectorAll) und queryXPaths. Beide geben ein queryResults-Objekt zurück:

{ queryType: Knoten | Zeichenfolge | Nummer | boolescher Wert, Ergebnisse: any[] // HTML-Elemente, XML-Elemente, Strings, Zahlen, Boolesche Werte, queryCSSSelectors: (query: string, amend: boolean) => queryResults, queryXpaths: (query: string, amend: boolean) => queryResults }

Die Funktionen queryCSSSelectors und queryXpaths führen die Abfrage, die Sie ihnen geben, über die Elemente im Ergebnisarray aus, natürlich solange das Ergebnisarray vom Typ Knoten ist. Andernfalls wird ein queryResult mit einem leeren Array und einem Knotentyp zurückgegeben. Wenn die Amend-Eigenschaft auf „true“ gesetzt ist, ändern die Funktionen ihre eigenen queryResults. Unter keinen Umständen sollte dies in einer Produktionsumgebung verwendet werden. Ich mache das nur, um die verschiedenen Auswirkungen der gemeinsamen Verwendung der beiden Abfrage-APIs zu demonstrieren. Beispielabfragen Ich möchte einige Beispiele verschiedener XPath-Abfragen zeigen, die einige ihrer leistungsstarken Funktionen veranschaulichen und zeigen, wie sie anstelle anderer Ansätze verwendet werden können. Das erste Beispiel ist //li/text(). Dadurch werden alle li-Elemente abgefragt und deren Textknoten zurückgegeben. Wenn wir also den folgenden HTML-Code abfragen würden:

  • eins
  • zwei
  • drei

…das wird zurückgegeben:

{"queryType": "xpathEvaluate", "results":["one", "two", " three"], "resultType": "string"}

Mit anderen Worten, wir erhalten das folgende Array: [„eins“, „zwei“, „drei“]. Normalerweise würden Sie die li-Elemente abfragen, um diese zu erhalten, das Ergebnis dieser Abfrage in ein Array umwandeln, das Array zuordnen und den Textknoten jedes Elements zurückgeben. Aber mit XPath können wir das prägnanter machen: document.queryXPaths("//li/text()").results.

Beachten Sie, dass der Weg, einen Textknoten zu erhalten, darin besteht, text() zu verwenden, was wie eine Funktionssignatur aussieht – und das ist es auch. Es gibt den Textknoten eines Elements zurück. In unserem Beispiel enthält das Markup drei li-Elemente, die jeweils Text enthalten („eins“, „zwei“ und „drei“). Schauen wir uns ein weiteres Beispiel einer text()-Abfrage an. Angenommen, dies ist unser Markup: Anmelden

Schreiben wir eine Abfrage, die den Wert des href-Attributs zurückgibt: document.queryXPaths("//a[text() = 'Sign In']/@href").results.

Dies ist eine XPath-Abfrage für das aktuelle Dokument, genau wie im letzten Beispiel, aber dieses Mal geben wir das href-Attribut eines Links (eines Elements) zurück, das den Text „Sign In“ enthält. Die tatsächlich zurückgegebeneErgebnis ist ["/login.html"]. Übersicht über XPath-Funktionen Es gibt eine Reihe von XPath-Funktionen, mit denen Sie wahrscheinlich nicht vertraut sind. Es gibt meiner Meinung nach mehrere, über die es sich zu informieren lohnt, darunter die folgenden:

Starts-mitWenn ein Text mit einem bestimmten anderen Textbeispiel beginnt, gibt Starts-mit(@href, 'http:') true zurück, wenn ein href-Attribut mit http: beginnt. enthältWenn ein Text ein bestimmtes anderes Textbeispiel enthält, gibt contains(text(), „Smashing Magazine“) „true“ zurück, wenn ein Textknoten irgendwo die Wörter „Smashing Magazine“ enthält. countGibt einen Zähler zurück, der angibt, wie viele Übereinstimmungen es für eine Abfrage gibt. Beispielsweise gibt count(//*[starts-with(@href, 'http:']) eine Zählung zurück, wie viele Links im Kontextknoten Elemente mit einem href-Attribut haben, das den Text enthält, der mit http: beginnt. Teilzeichenfolge Funktioniert wie JavaScript-Teilzeichenfolge, außer dass Sie die Zeichenfolge als Argument übergeben. Beispielsweise gibt substring("my text", 2, 4) „y t“ zurück. substring-beforeGibt den Teil eines Strings vor einem anderen String zurück. Beispielsweise gibt substing-before("mein Text", " ") "mein" zurück. Ebenso gibt substring-before("hi","bye") einen leeren String zurück. substring-afterGibt den Teil eines Strings nach einem anderen String zurück. Beispielsweise gibt substing-after("my text", " ") "text" zurück. Ebenso gibt substring-after("hi","bye") einen leeren String zurück. normalize-spaceGibt die Argumentzeichenfolge mit normalisiertem Leerzeichen zurück, indem führende und nachfolgende Leerzeichen entfernt und Sequenzen von Leerzeichen durch ein einzelnes Leerzeichen ersetzt werden. notGibt einen booleschen Wert „true“ zurück, wenn das Argument falsch ist, andernfalls „false“. trueGibt den booleschen Wert true zurück. falseGibt den booleschen Wert false zurück. concatDas Gleiche wie JavaScript concat, außer dass Sie es nicht als Methode für einen String ausführen. Stattdessen geben Sie alle Zeichenfolgen ein, die Sie verketten möchten. string-lengthDies ist nicht dasselbe wie die JavaScript-string-length, sondern gibt die Länge des Strings zurück, der als Argument angegeben wird. TranslateThis nimmt einen String und ändert das zweite Argument in das dritte Argument. Beispielsweise gibt Translate("abcdef", "abc", "XYZ") XYZdef aus.

Abgesehen von diesen speziellen XPath-Funktionen gibt es eine Reihe anderer Funktionen, die genauso funktionieren wie ihre JavaScript-Gegenstücke – oder Gegenstücke in praktisch jeder Programmiersprache – und die Sie wahrscheinlich ebenfalls nützlich finden würden, wie z. B. Boden, Decke, Runde, Summe usw. Die folgende Demo veranschaulicht jede dieser Funktionen: Siehe die Pen XPath Numerical Functions [forked] von Bryan Rasmussen. Beachten Sie, dass viele der numerischen Funktionen, wie die meisten String-Manipulationsfunktionen, eine einzige Eingabe erfordern. Das liegt natürlich daran, dass sie zum Abfragen verwendet werden sollen, wie im letzten XPath-Beispiel: //li[floor(text()) > 250]/@val

Wenn Sie sie verwenden, wie es in den meisten Beispielen der Fall ist, führen Sie sie am Ende auf dem ersten Knoten aus, der mit dem Pfad übereinstimmt. Es gibt auch einige Typkonvertierungsfunktionen, die Sie wahrscheinlich vermeiden sollten, da JavaScript bereits seine eigenen Typkonvertierungsprobleme hat. Es kann jedoch vorkommen, dass Sie eine Zeichenfolge in eine Zahl umwandeln möchten, um sie mit einer anderen Zahl zu vergleichen. Funktionen, die den Typ von etwas festlegen, sind Boolescher Wert, Zahl, Zeichenfolge und Knoten. Dies sind die wichtigen XPath-Datentypen. Und wie Sie sich vorstellen können, können die meisten dieser Funktionen für Datentypen verwendet werden, die keine DOM-Knoten sind. Beispielsweise nimmt substring-after einen String entgegen, wie wir bereits besprochen haben, es könnte sich aber auch um den String aus einem href-Attribut handeln. Es kann auch nur eine Zeichenfolge sein:

const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");

Offensichtlich wird uns dieses Beispiel das Ergebnisarray als ["Welt"] zurückgeben. Um dies in Aktion zu zeigen, habe ich eine Demoseite erstellt, die Funktionen für Dinge verwendet, die keine DOM-Knoten sind: Siehe den Pen queryXPath [forked] von Bryan Rasmussen. Sie sollten den überraschenden Aspekt der Übersetzungsfunktion beachten: Wenn Sie ein Zeichen im zweiten Argument (d. h. in der Liste der Zeichen, die Sie übersetzen möchten) haben und kein passendes Zeichen zum Übersetzen vorhanden ist, wird dieses Zeichen aus der Ausgabe entfernt. Also das:

Translate('Hallo, mein Name ist Inigo Montoya, du hast meinen Vater getötet, bereite dich auf den Tod vor','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')

…ergibt die Zeichenfolge, einschließlich Leerzeichen: [" * * ** "]

Das bedeutet, dass der Buchstabe „a“ in ein Sternchen (*) übersetzt wird, aber jedes andere Zeichen, das in der Zielzeichenfolge keine Übersetzung hat, vollständig entfernt wird. Das Leerzeichen ist alles, was uns noch bleibtzwischen den übersetzten „a“-Zeichen. Dann wieder diese Abfrage:

Translate('Hallo, mein Name ist Inigo Montoya, du hast meinen Vater getötet, bereite dich auf den Tod vor','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','**************************************************')")

…hat das Problem nicht und gibt ein Ergebnis aus, das so aussieht:

„***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***“

Möglicherweise fällt Ihnen auf, dass es in JavaScript keine einfache Möglichkeit gibt, genau das zu tun, was die XPath-Übersetzungsfunktion tut, obwohl in vielen Anwendungsfällen „replaceAll“ mit regulären Ausdrücken damit umgehen kann. Sie könnten den gleichen Ansatz verwenden, den ich demonstriert habe, aber das ist nicht optimal, wenn Sie nur die Zeichenfolgen übersetzen möchten. Die folgende Demo umschließt die Übersetzungsfunktion von XPath, um eine JavaScript-Version bereitzustellen: Siehe die Stiftübersetzungsfunktion [forked] von Bryan Rasmussen. Wo könnte man so etwas verwenden? Betrachten Sie die Caesar-Cipher-Verschlüsselung mit einem dreistelligen Offset (z. B. Spitzenverschlüsselung aus dem Jahr 48 v. Chr.):

Translate("Caesar plant, den Rubikon zu überschreiten!", „ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz“, „XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw“)

Der Eingabetext „Caesar plant, den Rubikon zu überschreiten!“ ergibt „Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!“ Um ein weiteres schnelles Beispiel für verschiedene Möglichkeiten zu geben, habe ich eine Metal-Funktion erstellt, die eine Zeichenfolgeneingabe entgegennimmt und mithilfe einer Übersetzungsfunktion den Text zurückgibt, einschließlich aller Zeichen, die Umlaute akzeptieren. Siehe die Pen-Metal-Funktion [forked] von Bryan Rasmussen.

const Metal = (str) => { return translator(str, "AOUaou","ÄÖÜäöü"); }

Und wenn der Text „Motley Crüe regiert, rockt Jungs!“ angezeigt wird, wird „Mötley Crüe rüles, röck ön düdes!“ zurückgegeben. Offensichtlich kann man diese Funktion auf alle möglichen Arten parodieren. Wenn das auf Sie zutrifft, dürfte Ihnen dieser TVTropes-Artikel jede Menge Inspiration bieten. Verwenden von CSS mit XPath Denken Sie an unseren Hauptgrund für die Verwendung von CSS-Selektoren zusammen mit XPath: CSS versteht ziemlich genau, was eine Klasse ist, während das Beste, was Sie mit XPath machen können, Stringvergleiche des Klassenattributs sind. Das wird in den meisten Fällen funktionieren. Aber wenn Sie jemals in eine Situation geraten würden, in der beispielsweise jemand Klassen mit den Namen .primaryLinks und .primaryLinks2 erstellt hat und Sie XPath verwenden, um die Klasse .primaryLinks abzurufen, dann würden Sie wahrscheinlich auf Probleme stoßen. Solange es nichts Unsinniges gibt, würden Sie wahrscheinlich XPath verwenden. Aber ich muss mit Bedauern berichten, dass ich an Orten gearbeitet habe, an denen Leute solche dummen Dinge tun. Hier ist eine weitere Demo, in der CSS und XPath zusammen verwendet werden. Es zeigt, was passiert, wenn wir den Code verwenden, um einen XPath auf einem Kontextknoten auszuführen, der nicht der Knoten des Dokuments ist. Sehen Sie sich das Pen-CSS und XPath zusammen [geforkt] von Bryan Rasmussen an. Die CSS-Abfrage ist .relatedarticles a, die die beiden a-Elemente in einem div abruft, dem eine .latedarticles-Klasse zugewiesen ist. Danach folgen drei „schlechte“ Abfragen, d. h. Abfragen, die nicht das tun, was wir von ihnen erwarten, wenn sie mit diesen Elementen als Kontextknoten ausgeführt werden. Ich kann erklären, warum sie sich anders verhalten, als Sie vielleicht erwarten. Die drei fraglichen schlechten Abfragen sind:

//text(): Gibt den gesamten Text im Dokument zurück. //a/text(): Gibt den gesamten Text innerhalb von Links im Dokument zurück. ./a/text(): Gibt keine Ergebnisse zurück.

Der Grund für diese Ergebnisse ist, dass es sich bei Ihrem Kontext zwar um ein von der CSS-Abfrage zurückgegebenes Element handelt, // jedoch gegen das gesamte Dokument verstößt. Das ist die Stärke von XPath; CSS kann nicht von einem Knoten nach oben zu einem Vorfahren und dann zu einem Geschwister dieses Vorfahren gehen und zu einem Nachkommen dieses Geschwisters hinuntergehen. Aber XPath kann. In der Zwischenzeit fragt ./ die untergeordneten Knoten des aktuellen Knotens ab, wobei der Punkt (.) den aktuellen Knoten darstellt und der Schrägstrich (/) den Übergang zu einem untergeordneten Knoten darstellt – ob es sich um ein Attribut, ein Element oder einen Text handelt, wird durch den nächsten Teil des Pfads bestimmt. Es gibt jedoch kein untergeordnetes Element, das von der CSS-Abfrage ausgewählt wurde, sodass diese Abfrage auch nichts zurückgibt. In dieser letzten Demo gibt es drei gute Abfragen:

.//text(), ./text(), normalize-space(./text()).

Die Normalize-Space-Abfrage demonstriert die Verwendung der XPath-Funktion, behebt aber auch ein in den anderen Abfragen enthaltenes Problem. Der HTML-Code ist wie folgt aufgebaut:

Automatisieren Sie Ihre Funktionstests mit Selenium WebDriver

Die Abfrage gibt einen Zeilenvorschub am Anfang und Ende des Textknotens zurück.und normalize-space entfernt dies. Die Verwendung einer beliebigen XPath-Funktion, die mit einem Eingabe-XPath etwas anderes als einen booleschen Wert zurückgibt, gilt auch für andere Funktionen. Die folgende Demo zeigt einige Beispiele: Sehen Sie sich die Beispiele für Pen xpath-Funktionen [forked] von Bryan Rasmussen an. Das erste Beispiel zeigt ein Problem, auf das Sie achten sollten. Konkret der folgende Code:

document.queryXPaths("substring-after(//a/@href,'https://')");

…gibt einen String zurück:

„www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/“

Es macht doch Sinn, oder? Diese Funktionen geben keine Arrays zurück, sondern einzelne Strings oder einzelne Zahlen. Wenn Sie die Funktion an einer beliebigen Stelle mit mehreren Ergebnissen ausführen, wird nur das erste Ergebnis zurückgegeben. Das zweite Ergebnis zeigt, was wir wirklich wollen:

document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");

Gibt ein Array aus zwei Zeichenfolgen zurück:

["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]

XPath-Funktionen können wie Funktionen in JavaScript verschachtelt werden. Wenn wir also die URL-Struktur von Smashing Magazine kennen, könnten wir Folgendes tun (die Verwendung von Vorlagenliteralen wird empfohlen): `übersetzen( Teilzeichenfolge( substring-after(./@href, ‚www.smashingmagazine.com/‘) ,9), '/','')`

Dies wird insofern etwas zu komplex, als dass Kommentare erforderlich sind, die beschreiben, was es tut: Nehmen Sie die gesamte URL aus dem href-Attribut nach www.smashingmagazine.com/, entfernen Sie die ersten neun Zeichen und übersetzen Sie dann den Schrägstrich (/) in nichts, um den abschließenden Schrägstrich zu entfernen. Das resultierende Array:

["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]

Weitere XPath-Anwendungsfälle XPath kann beim Testen wirklich glänzen. Der Grund ist nicht schwer zu erkennen, da XPath verwendet werden kann, um jedes Element im DOM von jeder Position im DOM abzurufen, während dies mit CSS nicht möglich ist. Sie können sich nicht darauf verlassen, dass CSS-Klassen in vielen modernen Build-Systemen konsistent bleiben, aber mit XPath können wir unabhängig von einer sich ändernden DOM-Struktur zuverlässigere Übereinstimmungen hinsichtlich des Textinhalts eines Elements herstellen. Es wurden Techniken erforscht, mit denen Sie belastbare XPath-Tests durchführen können. Nichts ist schlimmer, als dass Tests ausfallen und fehlschlagen, nur weil ein CSS-Selektor nicht mehr funktioniert, weil etwas umbenannt oder entfernt wurde. XPath eignet sich auch hervorragend zur Extraktion mehrerer Locators. Es gibt mehr als eine Möglichkeit, XPath-Abfragen zum Abgleichen eines Elements zu verwenden. Dasselbe gilt auch für CSS. Aber XPath-Abfragen können die Dinge gezielter untersuchen, wodurch die zurückgegebenen Ergebnisse begrenzt werden, sodass Sie eine bestimmte Übereinstimmung finden können, obwohl es möglicherweise mehrere mögliche Übereinstimmungen gibt. Beispielsweise können wir XPath verwenden, um ein bestimmtes h2-Element zurückzugeben, das in einem Div enthalten ist, das unmittelbar auf ein Geschwister-Div folgt, das wiederum ein untergeordnetes Bildelement mit einem data-testID="leader"-Attribut darauf enthält:

Verstehe diese Überschrift nicht

Verstehen Sie diese Schlagzeile auch nicht

Der Header für das Leitbild

Dies ist die Abfrage: document.queryXPaths(` //div[ Following-sibling::div[1] /img[@data-testID='leader'] ] /h2/ text() `);

Schauen wir uns eine Demo an, um zu sehen, wie das alles zusammenpasst: Siehe die Pen Complex H2-Abfrage [geforkt] von Bryan Rasmussen. Also, ja. Mit XPath gibt es viele mögliche Pfade zu jedem Element in einem Test. XSLT 1.0 veraltet Ich habe bereits erwähnt, dass das Chrome-Team plant, die XSLT 1.0-Unterstützung aus dem Browser zu entfernen. Das ist wichtig, da XSLT 1.0 XML-fokussierte Programmierung für die Dokumenttransformation verwendet, die wiederum auf XPath 1.0 basiert, das in den meisten Browsern zu finden ist. Wenn das passiert, verlieren wir eine Schlüsselkomponente von XPath. Aber angesichts der Tatsache, dass sich XPath wirklich hervorragend zum Schreiben von Tests eignet, halte ich es für unwahrscheinlich, dass XPath als Ganzes in absehbarer Zeit verschwinden wird. Allerdings ist mir aufgefallen, dass sich Leute für eine Funktion interessieren, wenn sie weggenommen wird. Und das gilt sicherlich auch für den Fall, dass XSLT 1.0 veraltet ist. Bei Hacker News gibt es eine ganze Diskussion voller Argumente gegen die Ablehnung. Der Beitrag selbst ist ein großartiges Beispiel für die Erstellung eines Blogging-Frameworks mit XSLT. DuIch kann die Diskussion selbst lesen, aber es geht darum, wie JavaScript als Unterlage für XLST verwendet werden könnte, um solche Fälle zu bewältigen. Ich habe auch Vorschläge gesehen, dass Browser SaxonJS verwenden sollten, eine Portierung zu den Saxon XSLT-, XQUERY- und XPath-Engines von JavaScript. Das ist eine interessante Idee, insbesondere da Saxon-JS die aktuelle Version dieser Spezifikationen implementiert, während es keinen Browser gibt, der eine Version von XPath oder XSLT über 1.0 hinaus implementiert, und keinen, der XQuery implementiert. Ich habe mich an Norm Tovey-Walsh von Saxonica gewandt, dem Unternehmen hinter SaxonJS und anderen Versionen der Saxon-Engine. Er sagte: „Wenn ein Browser-Anbieter daran interessiert wäre, SaxonJS als Ausgangspunkt für die Integration moderner XML-Technologien in den Browser zu nutzen, würden wir uns freuen, dies mit ihm zu besprechen.“ – Norm Tovey-Walsh

Aber auch hinzugefügt: „Ich wäre sehr überrascht, wenn jemand denken würde, dass es der ideale Ansatz wäre, SaxonJS in seiner aktuellen Form zu übernehmen und es unverändert in den Browser-Build zu integrieren. Ein Browser-Anbieter könnte aufgrund der Tatsache, dass er den Browser erstellt, die Integration auf einer viel tieferen Ebene angehen, als wir es „von außen“ können.“ – Norm Tovey-Walsh

Es ist erwähnenswert, dass Tovey-Walshs Kommentare etwa eine Woche vor der Ankündigung der XSLT-Abschaffung kamen. Fazit Ich könnte immer so weitermachen. Ich hoffe jedoch, dass dies die Leistungsfähigkeit von XPath demonstriert und Ihnen viele Beispiele gegeben hat, die zeigen, wie Sie damit Großes erreichen können. Es ist ein perfektes Beispiel für ältere Technologie im Browser-Stack, die auch heute noch viele nützliche Funktionen bietet, selbst wenn Sie nie wussten, dass sie existiert, oder nie darüber nachgedacht haben, danach zu greifen. Weiterführende Literatur

„Enhancing the Resiliency of Automated Web Tests with Natural Language“ (ACM Digital Library) von Maroun Ayli, Youssef Bakouny, Nader Jalloul und Rima Kilany. Dieser Artikel enthält viele XPath-Beispiele zum Schreiben robuster Tests. XPath (MDN) Dies ist ein ausgezeichneter Ausgangspunkt, wenn Sie eine technische Erklärung zur Funktionsweise von XPath wünschen. XPath-Tutorial (ZVON)Ich habe festgestellt, dass dieses Tutorial dank einer Fülle von Beispielen und klaren Erklärungen für mein eigenes Lernen am hilfreichsten ist. XPatherMit diesem interaktiven Tool können Sie direkt mit dem Code arbeiten.

You May Also Like

Enjoyed This Article?

Get weekly tips on growing your audience and monetizing your content — straight to your inbox.

No spam. Join 138,000+ creators. Unsubscribe anytime.

Create Your Free Bio Page

Join 138,000+ creators on Seemless.

Get Started Free