Jeg har været i frontend-udvikling længe nok til at se en tendens gennem årene: yngre udviklere, der arbejder med et nyt paradigme for programmering uden at forstå den historiske kontekst af det. Det er selvfølgelig helt forståeligt ikke at vide noget. Nettet er et meget stort sted med et mangfoldigt sæt af færdigheder og specialer, og vi ved ikke altid, hvad vi ikke ved. Læring i dette felt er en vedvarende rejse snarere end noget, der sker én gang og ender. Eksempel: Nogen på mit team spurgte, om det var muligt at se, om brugere navigerer væk fra en bestemt fane i brugergrænsefladen. Jeg påpegede JavaScripts beforeunload-begivenhed. Men dem, der har tacklet dette før, ved, at dette er muligt, fordi de er blevet ramt af advarsler om ikke-gemte data på andre websteder, som før unload er en typisk brugssag. Jeg påpegede også siden Skjul og synlighedChange-begivenheder til min kollega for en god ordens skyld. Hvordan vidste jeg det? Fordi det kom op i et andet projekt, ikke fordi jeg studerede det, da jeg først lærte JavaScript. Faktum er, at moderne front-end-frameworks står på skuldrene af de teknologigiganter, der gik forud for dem. De abstraherer udviklingspraksis, ofte for en bedre udvikleroplevelse, der reducerer eller endda eliminerer behovet for at vide eller røre ved, hvad der traditionelt har været essentielle frontend-koncepter, som alle sandsynligvis burde kende. Overvej CSS Object Model (CSSOM). Du kan forvente, at alle, der arbejder i CSS og JavaScript, har en masse praktisk CSSOM-erfaring, men det vil ikke altid være tilfældet. Der var et React-projekt for en e-handelsside, jeg arbejdede på, hvor vi skulle indlæse et stylesheet for den aktuelt valgte betalingsudbyder. Problemet var, at stylearket blev indlæst på hver side, når det kun var virkelig nødvendigt på en bestemt side. Udvikleren, der havde til opgave at få dette til at ske, havde aldrig indlæst et stylesheet dynamisk. Igen, dette er fuldstændig forståeligt, når React abstraherer den traditionelle tilgang, du måske er nået efter. CSSOM er sandsynligvis ikke noget, du har brug for i dit daglige arbejde. Men det er sandsynligt, at du bliver nødt til at interagere med det på et tidspunkt, selv i et enkelt tilfælde. Disse oplevelser inspirerede mig til at skrive denne artikel. Der er mange eksisterende webfunktioner og -teknologier i naturen, som du måske aldrig rører direkte i dit daglige arbejde. Måske er du ret ny inden for webudvikling og er simpelthen ikke klar over dem, fordi du er gennemsyret af abstraktionen af en specifik ramme, der ikke kræver, at du kender det dybt eller overhovedet. Jeg taler specifikt om XML, som mange af os ved er et ældgammelt sprog, der ikke er helt ulig HTML. Jeg bringer dette op på grund af nylige WHATWG-diskussioner, der foreslår, at en betydelig del af XML-stakken kendt som XSLT-programmering skal fjernes fra browsere. Det er præcis den slags ældre, eksisterende teknologi, vi har haft i årevis, som kunne bruges til noget så praktisk som den CSSOM-situation, mit team var i. Har du arbejdet med XSLT før? Lad os se, om vi læner os meget ind i denne ældre teknologi og udnytter dens funktioner uden for XML-sammenhæng til at tackle problemer i den virkelige verden i dag. XPath: Den centrale API Den vigtigste XML-teknologi, der måske er den mest nyttige uden for et lige XML-perspektiv, er XPath, et forespørgselssprog, der giver dig mulighed for at finde enhver node eller attribut i et markup-træ med ét rodelement. Jeg har en personlig hengivenhed til XSLT, men det afhænger også af XPath, og personlig hengivenhed skal lægges til side i rangordenens betydning. Argumentet for at fjerne XSLT nævner ikke XPath, så jeg formoder, at det stadig er tilladt. Det er godt, fordi XPath er den centrale og vigtigste API i denne suite af teknologier, især når man prøver at finde noget at bruge uden for normal XML-brug. Det er vigtigt, fordi mens CSS-vælgere kan bruges til at finde de fleste af elementerne på din side, kan de ikke finde dem alle. Desuden kan CSS-vælgere ikke bruges til at finde et element baseret på dets aktuelle position i DOM. XPath kan. Nogle af jer, der læser dette, kender måske XPath, og nogle måske ikke. XPath er et ret stort område af teknologi, og jeg kan ikke rigtig lære alt det grundlæggende og også vise dig seje ting at gøre med det i en enkelt artikel som denne. Jeg prøvede faktisk at skrive den artikel, men den gennemsnitlige Smashing Magazine-udgivelse rækker ikke over 5.000 ord. Jeg var allerede på mere end2.000 ord, mens du kun er halvvejs igennem det grundlæggende. Så jeg vil begynde at lave seje ting med XPath og give dig nogle links, som du kan bruge til det grundlæggende, hvis du finder disse ting interessant. Kombinerer XPath og CSS XPath kan gøre mange ting, som CSS-vælgere ikke kan, når de forespørger på elementer. Men CSS-vælgere kan også gøre et par ting, som XPath ikke kan, nemlig forespørge elementer efter klassenavn.
CSS XPath .myClass /*[indeholder(@klasse, "minKlasse")]
I dette eksempel forespørger CSS elementer, der indeholder et .myClass-klassenavn. I mellemtiden forespørger XPath-eksemplet på elementer, der indeholder en attributklasse med strengen "myClass". Med andre ord, den vælger elementer med myClass i enhver attribut, inklusive elementer med .myClass-klassenavnet — såvel som elementer med "myClass" i strengen, såsom .myClass2. XPath er bredere i den forstand. Så nej. Jeg foreslår ikke, at vi skal smide CSS ud og begynde at vælge alle elementer via XPath. Det er ikke meningen. Pointen er, at XPath kan gøre ting, som CSS ikke kan og stadig kan være meget nyttige, selvom det er en ældre teknologi i browserstakken og måske ikke virker indlysende ved første øjekast. Lad os bruge de to teknologier sammen, ikke kun fordi vi kan, men fordi vi vil lære noget om XPath i processen, hvilket gør det til endnu et værktøj i din stak - et du måske ikke vidste har været der hele tiden! Problemet er, at JavaScripts document.evaluate-metode og de forskellige forespørgselsvælgermetoder, vi bruger med CSS API'erne til JavaScript, er inkompatible. Jeg har lavet en kompatibel forespørgsels-API for at få os i gang, men jeg har indrømmet, at jeg ikke har tænkt meget over det, da det er en afvigelse fra det, vi laver her. Her er et ret simpelt eksempel på en genanvendelig forespørgselskonstruktør: Se Pen-queryXPath [forked] af Bryan Rasmussen. Jeg har tilføjet to metoder på dokumentobjektet: queryCSSSelectors (som i det væsentlige er querySelectorAll) og queryXPaths. Begge disse returnerer et queryResults-objekt:
{ queryType: noder | streng | nummer | boolsk, resultater: alle[] // html-elementer, xml-elementer, strenge, tal, booleaner, queryCSSSelectors: (query: string, amend: boolean) => queryResults, queryXpaths: (query: string, amend: boolean) => queryResults }
Funktionerne queryCSSSelectors og queryXpaths kører den forespørgsel, du giver dem, over elementerne i resultatarrayet, så længe resultatarrayet selvfølgelig er af typen noder. Ellers vil det returnere et queryResult med et tomt array og en type noder. Hvis egenskaben amend er sat til sand, ændrer funktionerne deres egne queryResults. Dette må under ingen omstændigheder bruges i et produktionsmiljø. Jeg gør det på denne måde udelukkende for at demonstrere de forskellige effekter af at bruge de to forespørgsels-API'er sammen. Eksempelforespørgsler Jeg vil gerne vise nogle få eksempler på forskellige XPath-forespørgsler, der viser nogle af de kraftfulde ting, de kan gøre, og hvordan de kan bruges i stedet for andre tilgange. Det første eksempel er //li/text(). Dette forespørger alle li-elementer og returnerer deres tekstnoder. Så hvis vi skulle forespørge på følgende HTML:
- én
- to
- tre
… dette er hvad der returneres:
{"queryType":"xpathEvaluate","results":["one","to","three"],"resultType":"string"}
Med andre ord får vi følgende array: ["en","to","tre"]. Normalt ville du forespørge efter li-elementerne for at få det, omdanne resultatet af forespørgslen til et array, kortlægge arrayet og returnere tekstnoden for hvert element. Men vi kan gøre det mere kortfattet med XPath: document.queryXPaths("//li/text()").results.
Bemærk, at måden at få en tekstnode på er at bruge text(), som ligner en funktionssignatur - og det er den. Det returnerer tekstnoden for et element. I vores eksempel er der tre li-elementer i markeringen, som hver indeholder tekst ("én", "to" og "tre").
Lad os se på endnu et eksempel på en tekst()-forespørgsel. Antag, at dette er vores markup:
Lad os skrive en forespørgsel, der returnerer href-attributværdien: document.queryXPaths("//a[text() = 'Log på']/@href").results.
Dette er en XPath-forespørgsel på det aktuelle dokument, ligesom det sidste eksempel, men denne gang returnerer vi href-attributten for et link (et element), der indeholder teksten "Sign In". Den faktiske vendte tilbageresultatet er ["/login.html"]. Oversigt over XPath-funktioner Der er en række XPath-funktioner, og du er sandsynligvis ikke bekendt med dem. Der er flere, synes jeg, der er værd at vide om, herunder følgende:
starter-withHvis en tekst starter med et bestemt andet teksteksempel, starter-med(@href, 'http:') returnerer sandt, hvis en href-attribut starter med http:. containsHvis en tekst indeholder et bestemt andet teksteksempel, returnerer contains(text(), "Smashing Magazine") sandt, hvis en tekstnode indeholder ordene "Smashing Magazine" hvor som helst. countReturnerer en optælling af, hvor mange matches der er til en forespørgsel. For eksempel returnerer count(//*[starts-with(@href, 'http:']) en optælling af, hvor mange links i kontekstknuden, der har elementer med en href-attribut, der indeholder teksten, der begynder med http:. understreng Fungerer som JavaScript-understreng, bortset fra at du sender strengen som et argument. For eksempel returnerer substring("min tekst", 2, 4) "y t". substring-beforeReturnerer delen af en streng før en anden streng. For eksempel returnerer substing-before("min tekst", " ") "min". På samme måde returnerer substring-before("hej","bye") en tom streng. substring-after Returnerer delen af en streng efter en anden streng. For eksempel returnerer substing-after("min tekst", " ") "tekst". På samme måde returnerer substring-after("hej","bye") en tom streng. normalize-space Returnerer argumentstrengen med mellemrum normaliseret ved at fjerne indledende og efterfølgende mellemrum og erstatte sekvenser af mellemrumstegn med et enkelt mellemrum. returnerer ikke en boolesk sand, hvis argumentet er falsk, ellers falsk. true Returnerer boolesk sand. falseReturnerer boolesk false. concatDet samme som JavaScript concat, bortset fra at du ikke kører det som en metode på en streng. I stedet indsætter du alle de strenge, du vil sammenkæde. string-lengthDette er ikke det samme som JavaScript string-length, men returnerer snarere længden af strengen, den er givet som argument. translateThis tager en streng og ændrer det andet argument til det tredje argument. For eksempel, translate("abcdef", "abc", "XYZ") udsender XYZdef.
Bortset fra disse særlige XPath-funktioner er der en række andre funktioner, der fungerer på samme måde som deres JavaScript-modstykker - eller modstykker i stort set et hvilket som helst programmeringssprog - som du sandsynligvis også ville finde nyttige, såsom gulv, loft, rund, sum og så videre. Følgende demo illustrerer hver af disse funktioner: Se Pen XPath Numeriske funktioner [forked] af Bryan Rasmussen. Bemærk, at ligesom de fleste af strengmanipulationsfunktionerne tager mange af de numeriske en enkelt input. Dette er selvfølgelig fordi de skal bruges til forespørgsler, som i det sidste XPath-eksempel: //li[floor(text()) > 250]/@val
Hvis du bruger dem, som de fleste eksempler gør, ender du med at køre det på den første node, der matcher stien. Der er også nogle typekonverteringsfunktioner, du nok bør undgå, fordi JavaScript allerede har sine egne typekonverteringsproblemer. Men der kan være tidspunkter, hvor du vil konvertere en streng til et tal for at kontrollere det mod et andet tal. Funktioner, der angiver typen af noget, er boolean, tal, streng og node. Disse er de vigtige XPath-datatyper. Og som du måske forestiller dig, kan de fleste af disse funktioner bruges på datatyper, der ikke er DOM-noder. For eksempel tager substring-after en streng, som vi allerede har dækket, men det kan være strengen fra en href-attribut. Det kan også bare være en streng:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Dette eksempel vil naturligvis give os resultatarrayet tilbage som ["verden"]. For at vise dette i aktion har jeg lavet en demoside, der bruger funktioner mod ting, der ikke er DOM-noder: Se Pen-queryXPath [forked] af Bryan Rasmussen. Du bør bemærke det overraskende aspekt af oversættelsesfunktionen, som er, at hvis du har et tegn i det andet argument (dvs. listen over tegn, du vil have oversat) og intet matchende tegn at oversætte til, bliver det tegn fjernet fra outputtet. Altså dette:
translate('Hej, mit navn er Inigo Montoya, du dræbte min far, forbered dig på at dø','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
… resulterer i strengen, inklusive mellemrum: [" * * ** "]
Det betyder, at bogstavet "a" bliver oversat til en stjerne (*), men hvert andet tegn, der ikke har en oversættelse givet målstrengen, fjernes fuldstændigt. Det hvide mellemrum er alt, vi har tilbagemellem de oversatte "a"-tegn. Så igen denne forespørgsel:
translate('Hej, mit navn er Inigo Montoya, du dræbte min far, forbered dig på at dø','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*******************************************************')")
…har ikke problemet og udsender et resultat, der ser sådan ud:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Det vil måske slå dig, at der ikke er nogen nem måde i JavaScript at gøre præcis, hvad XPath-oversættelsesfunktionen gør, selvom replaceAll med regulære udtryk i mange tilfælde kan håndtere det. Du kunne bruge den samme tilgang, som jeg har demonstreret, men det er suboptimalt, hvis alt du vil er at oversætte strengene. Følgende demo ombryder XPaths oversættelsesfunktion for at give en JavaScript-version: Se Pen oversættelsesfunktionen [forked] af Bryan Rasmussen. Hvor kan du bruge sådan noget? Overvej Caesar Cipher-kryptering med en tre-plads offset (f.eks. top-of-the-line kryptering fra 48 f.Kr.):
translate("Cæsar planlægger at krydse Rubicon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Indtastningsteksten "Cæsar planlægger at krydse Rubicon!" resulterer i "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" For at give endnu et hurtigt eksempel på forskellige muligheder, lavede jeg en metalfunktion, der tager et strenginput og bruger en oversættelsesfunktion til at returnere teksten, inklusive alle tegn, der tager omlyd. Se Pen-metalfunktionen [forked] af Bryan Rasmussen.
const metal = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
Og hvis teksten "Motley Crue regler, rock on dudes!", returneres "Mötley Crüe rüles, röck ön düdes!" Det er klart, at man kan have alle mulige parodier af denne funktion. Hvis det er dig, så burde denne TVTropes-artikel give dig masser af inspiration. Brug af CSS med XPath Husk vores hovedårsag til at bruge CSS-vælgere sammen med XPath: CSS forstår stort set, hvad en klasse er, hvorimod det bedste du kan gøre med XPath er strengsammenligninger af klasseattributten. Det vil virke i de fleste tilfælde. Men hvis du nogensinde skulle løbe ind i en situation, hvor f.eks. nogen oprettede klasser ved navn .primaryLinks og .primaryLinks2, og du brugte XPath til at få .primaryLinks-klassen, så ville du sandsynligvis løbe ind i problemer. Så længe der ikke er noget dumt sådan, ville du sandsynligvis bruge XPath. Men jeg er ked af at fortælle, at jeg har arbejdet steder, hvor folk gør den slags fjollede ting. Her er en anden demo, der bruger CSS og XPath sammen. Det viser, hvad der sker, når vi bruger koden til at køre en XPath på en kontekstnode, der ikke er dokumentets node. Se Pen css og xpath sammen [forked] af Bryan Rasmussen. CSS-forespørgslen er .relatedarticles a, som henter de to a-elementer i en div, der er tildelt en .relatedarticles-klasse. Derefter er der tre "dårlige" forespørgsler, det vil sige forespørgsler, der ikke gør, hvad vi vil have dem til at gøre, når de kører med disse elementer som kontekstknudepunktet. Jeg kan forklare, hvorfor de opfører sig anderledes, end du måske forventer. De tre dårlige forespørgsler, der er tale om, er:
//text(): Returnerer al teksten i dokumentet. //a/text(): Returnerer al tekst inde i links i dokumentet. ./a/text(): Returnerer ingen resultater.
Årsagen til disse resultater er, at mens din kontekst er et element, der returneres fra CSS-forespørgslen, går // imod hele dokumentet. Dette er styrken ved XPath; CSS kan ikke gå fra en node op til en forfader og derefter til en søskende til denne forfader og gå ned til en efterkommer af denne søskende. Men det kan XPath. I mellemtiden forespørger ./ børnene på den aktuelle node, hvor prikken (.) repræsenterer den aktuelle node, og skråstregen (/) repræsenterer at gå til en underordnet node - om det er en egenskab, et element eller en tekst bestemmes af den næste del af stien. Men der er ikke noget underordnet et element, der er valgt af CSS-forespørgslen, så den forespørgsel returnerer heller ikke noget. Der er tre gode forespørgsler i den sidste demo:
.//text(), ./tekst(), normalize-space(./text()).
Normalize-space-forespørgslen demonstrerer XPath-funktionsbrug, men løser også et problem inkluderet i de andre forespørgsler. HTML er opbygget således:
Automatisering af din funktionstest med Selenium WebDriver
Forespørgslen returnerer et linjeskift i begyndelsen og slutningen af tekstnoden,og normalize-space fjerner dette. Brug af en hvilken som helst XPath-funktion, der returnerer noget andet end en boolean med en input-Xpath, gælder for andre funktioner. Følgende demo viser en række eksempler: Se eksemplerne på Pen xpath-funktioner [forked] af Bryan Rasmussen. Det første eksempel viser et problem, du skal være opmærksom på. Specifikt følgende kode:
document.queryXPaths("substring-after(//a/@href,'https://')");
… returnerer én streng:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Det giver mening, ikke? Disse funktioner returnerer ikke arrays, men snarere enkelte strenge eller enkelte tal. At køre funktionen hvor som helst med flere resultater returnerer kun det første resultat. Det andet resultat viser, hvad vi virkelig ønsker:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Som returnerer en matrix af to strenge:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath-funktioner kan indlejres ligesom funktioner i JavaScript. Så hvis vi kender Smashing Magazine URL-strukturen, kunne vi gøre følgende (det anbefales at bruge skabeloner): `oversæt( understreng( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Dette bliver en smule for komplekst i det omfang, at det har brug for kommentarer, der beskriver, hvad det gør: tag hele URL'en fra href-attributten efter www.smashingmagazine.com/, fjern de første ni tegn, og oversæt derefter skråstregen (/) til ingenting for at slippe af med den ende skråstreg. Det resulterende array:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
Flere XPath-brugssager XPath kan virkelig skinne i test. Årsagen er ikke svær at se, da XPath kan bruges til at hente hvert element i DOM, fra enhver position i DOM, hvorimod CSS ikke kan. Du kan ikke regne med, at CSS-klasser forbliver konsistente i mange moderne byggesystemer, men med XPath er vi i stand til at lave mere robuste matches til, hvad tekstindholdet i et element er, uanset en skiftende DOM-struktur. Der har været forskning i teknikker, der giver dig mulighed for at lave modstandsdygtige XPath-tests. Intet er værre end at få tests til at falde ud og mislykkes, bare fordi en CSS-vælger ikke længere virker, fordi noget er blevet omdøbt eller fjernet. XPath er også rigtig god til udtrækning af flere lokatorer. Der er mere end én måde at bruge XPath-forespørgsler til at matche et element. Det samme er tilfældet med CSS. Men XPath-forespørgsler kan bore i tingene på en mere målrettet måde, der begrænser, hvad der returneres, så du kan finde et specifikt match, hvor der kan være flere mulige matches. For eksempel kan vi bruge XPath til at returnere et specifikt h2-element, der er indeholdt i en div, der umiddelbart følger efter en søskende-div, der igen indeholder et underordnet billedelement med en data-testID="leader"-attribut på:
forstå ikke denne overskrift
Få heller ikke denne overskrift
Overskriften til lederbilledet
Dette er forespørgslen: document.queryXPaths(` //div[ følgende søskende::div[1] /img[@data-testID='leder'] ] /h2/ tekst() `);
Lad os se en demo for at se, hvordan det hele hænger sammen: Se Pen Complex H2 Query [forked] af Bryan Rasmussen. Så ja. Der er mange mulige stier til ethvert element i en test, der bruger XPath. XSLT 1.0 udfasning Jeg nævnte tidligt, at Chrome-teamet planlægger at fjerne XSLT 1.0-understøttelse fra browseren. Det er vigtigt, fordi XSLT 1.0 bruger XML-fokuseret programmering til dokumenttransformation, der igen er afhængig af XPath 1.0, som er det, der findes i de fleste browsere. Når det sker, mister vi en nøglekomponent i XPath. Men i betragtning af det faktum, at XPath er virkelig fantastisk til at skrive test, finder jeg det usandsynligt, at XPath som helhed forsvinder snart. Når det er sagt, har jeg bemærket, at folk bliver interesserede i en funktion, når den er taget væk. Og det er bestemt sandt i tilfælde af, at XSLT 1.0 er forældet. Der foregår en hel diskussion på Hacker News fyldt med argumenter imod afskrivningen. Selve indlægget er et godt eksempel på at skabe en bloggingramme med XSLT. Dukan læse diskussionen for dig selv, men det kommer ind på, hvordan JavaScript kan bruges som et shim for XLST til at håndtere den slags sager. Jeg har også set forslag om, at browsere skal bruge SaxonJS, som er en port til JavaScripts Saxon XSLT-, XQUERY- og XPath-motorer. Det er en interessant idé, især da Saxon-JS implementerer den nuværende version af disse specifikationer, hvorimod der ikke er nogen browser, der implementerer nogen version af XPath eller XSLT ud over 1.0, og ingen, der implementerer XQuery. Jeg nåede ud til Norm Tovey-Walsh hos Saxonica, firmaet bag SaxonJS og andre versioner af Saxon-motoren. Han sagde: "Hvis en browserleverandør var interesseret i at tage SaxonJS som udgangspunkt for at integrere moderne XML-teknologier i browseren, ville vi være glade for at diskutere det med dem." - Norm Tovey-Walsh
Men tilføjede også: "Jeg ville blive meget overrasket, hvis nogen mente, at det ville være den ideelle tilgang at tage SaxonJS i sin nuværende form og droppe det i browserbuilden uændret. En browserleverandør, i kraft af det faktum, at de bygger browseren, kunne nærme sig integrationen på et meget dybere niveau, end vi kan "udefra"." - Norm Tovey-Walsh
Det er værd at bemærke, at Tovey-Walshs kommentarer kom omkring en uge før XSLT-afskrivningsmeddelelsen. Konklusion Jeg kunne blive ved og ved. Men jeg håber, at dette har demonstreret kraften i XPath og givet dig masser af eksempler, der viser, hvordan du bruger det til at opnå store ting. Det er et perfekt eksempel på ældre teknologi i browserstakken, der stadig har masser af nytte i dag, selvom du aldrig har vidst, at den eksisterede eller aldrig har overvejet at række ud efter den. Yderligere læsning
"Enhancing the Resiliency of Automated Web Tests with Natural Language" (ACM Digital Library) af Maroun Ayli, Youssef Bakouny, Nader Jalloul og Rima KilanyDenne artikel giver mange XPath-eksempler til at skrive modstandsdygtige tests. XPath (MDN) Dette er et glimrende sted at starte, hvis du vil have en teknisk forklaring, der beskriver, hvordan XPath fungerer. XPath Tutorial (ZVON) Jeg har fundet denne tutorial for at være den mest nyttige i min egen læring, takket være et væld af eksempler og klare forklaringer. XPatherDette interaktive værktøj lader dig arbejde direkte med koden.
