Ik ben lang genoeg bezig met front-end-ontwikkeling om een trend door de jaren heen te zien: jongere ontwikkelaars die met een nieuw programmeerparadigma werken zonder de historische context ervan te begrijpen. Het is natuurlijk volkomen begrijpelijk dat je iets niet weet. Het internet is een zeer grote plaats met een gevarieerde reeks vaardigheden en specialiteiten, en we weten niet altijd wat we niet weten. Leren op dit gebied is een voortdurende reis in plaats van iets dat een keer gebeurt en eindigt. Voorbeeld: iemand in mijn team vroeg of het mogelijk was om te zien of gebruikers van een bepaald tabblad in de gebruikersinterface wegnavigeerden. Ik heb gewezen op de beforeunload-gebeurtenis van JavaScript. Maar degenen die dit eerder hebben aangepakt, weten dat dit mogelijk is omdat ze te maken krijgen met waarschuwingen over niet-opgeslagen gegevens op andere sites, waarvoor beforeunload een typisch gebruiksscenario is. Voor de goede orde heb ik mijn collega ook gewezen op de paginaVerberg en zichtbaarheidVerander gebeurtenissen. Hoe wist ik daarvan? Omdat het in een ander project ter sprake kwam, niet omdat ik er kennis van had genomen toen ik JavaScript voor het eerst leerde. Feit is dat moderne front-end-frameworks op de schouders staan van de technologiegiganten die hen voorgingen. Ze abstraheren ontwikkelingspraktijken, vaak voor een betere ontwikkelaarservaring die de noodzaak vermindert of zelfs elimineert om te weten of aan te raken wat van oudsher essentiële front-endconcepten zijn die iedereen waarschijnlijk zou moeten kennen. Overweeg het CSS Object Model (CSSOM). Je zou verwachten dat iedereen die met CSS en JavaScript werkt een heleboel praktische CSSOM-ervaring heeft, maar dat zal niet altijd het geval zijn. Er was een React-project voor een e-commercesite waaraan ik werkte, waarbij we een stylesheet moesten laden voor de momenteel geselecteerde betalingsprovider. Het probleem was dat de stylesheet op elke pagina werd geladen terwijl deze alleen echt nodig was op een specifieke pagina. De ontwikkelaar die dit moest realiseren had nog nooit een stylesheet dynamisch geladen. Nogmaals, dit is volkomen begrijpelijk als React de traditionele aanpak waar je misschien naar hebt gezocht, abstraheert. De CSSOM is waarschijnlijk niet iets dat u nodig heeft in uw dagelijkse werk. Maar het is waarschijnlijk dat u er op een gegeven moment mee zult moeten communiceren, zelfs in een eenmalig geval. Deze ervaringen inspireerden mij tot het schrijven van dit artikel. Er zijn veel bestaande webfuncties en technologieën in het wild die u in uw dagelijkse werk misschien nooit rechtstreeks zult aanraken. Misschien ben je vrij nieuw op het gebied van webontwikkeling en ben je je er eenvoudigweg niet van bewust, omdat je doordrenkt bent van de abstractie van een specifiek raamwerk waarvoor je het niet diepgaand of zelfs helemaal niet hoeft te kennen. Ik heb het specifiek over XML, waarvan velen van ons weten dat het een oude taal is die niet geheel verschilt van HTML. Ik breng dit ter sprake vanwege recente WHATWG-discussies die suggereren dat een aanzienlijk deel van de XML-stack, bekend als XSLT-programmering, uit browsers zou moeten worden verwijderd. Dit is precies het soort oudere, bestaande technologie die we al jaren hebben en die gebruikt zou kunnen worden voor zoiets praktisch als de CSSOM-situatie waarin mijn team zich bevond. Heeft u al eerder met XSLT gewerkt? Laten we eens kijken of we zwaar op deze oudere technologie leunen en de mogelijkheden ervan buiten de context van XML benutten om hedendaagse problemen in de echte wereld aan te pakken. XPath: de centrale API De belangrijkste XML-technologie die misschien wel het nuttigst is buiten een puur XML-perspectief is XPath, een querytaal waarmee je elk knooppunt of attribuut in een markup-boom met één hoofdelement kunt vinden. Ik heb een persoonlijke genegenheid voor XSLT, maar die is ook afhankelijk van XPath, en persoonlijke genegenheid moet terzijde worden geschoven als het gaat om het rangschikken van belang. Het argument voor het verwijderen van XSLT maakt geen melding van XPath, dus ik neem aan dat het nog steeds is toegestaan. Dat is goed, want XPath is de centrale en belangrijkste API in deze reeks technologieën, vooral als je iets probeert te vinden dat je buiten het normale XML-gebruik kunt gebruiken. Dit is belangrijk omdat, hoewel CSS-kiezers kunnen worden gebruikt om de meeste elementen op uw pagina te vinden, ze ze niet allemaal kunnen vinden. Bovendien kunnen CSS-selectors niet worden gebruikt om een element te vinden op basis van zijn huidige positie in de DOM. XPath kan. Sommigen van jullie die dit lezen, kennen XPath misschien, en sommigen misschien niet. XPath is een behoorlijk groot technologiegebied, en ik kan niet echt alle basisbeginselen leren en je ook leuke dingen laten zien die ermee te maken hebben in één artikel als dit. Ik heb geprobeerd dat artikel te schrijven, maar de gemiddelde publicatie van Smashing Magazine bevat niet meer dan 5.000 woorden. Ik zat al op meer dan2.000 woorden, terwijl je nog maar halverwege de basisbeginselen bent. Dus ik ga coole dingen doen met XPath en je een aantal links geven die je voor de basis kunt gebruiken als je dit interessant vindt. Combineren van XPath en CSS XPath kan veel dingen doen die CSS-selectors niet kunnen bij het opvragen van elementen. Maar CSS-selectors kunnen ook een paar dingen doen die XPath niet kan, namelijk elementen opvragen op klassenaam.
CSS XPath .mijnKlasse /*[bevat(@class, "mijnKlasse")]
In dit voorbeeld zoekt CSS naar elementen die de klassenaam .myClass bevatten. Ondertussen vraagt het XPath-voorbeeld elementen op die een attribuutklasse bevatten met de string “myClass”. Met andere woorden, het selecteert elementen met myClass in elk attribuut, inclusief elementen met de klassenaam .myClass, evenals elementen met “myClass” in de string, zoals .myClass2. XPath is in die zin breder. Dus nee. Ik suggereer niet dat we CSS moeten weggooien en alle elementen via XPath moeten selecteren. Dat is niet het punt. Het punt is dat XPath dingen kan doen die CSS niet kan en nog steeds erg nuttig zou kunnen zijn, ook al is het een oudere technologie in de browserstack en lijkt het op het eerste gezicht misschien niet voor de hand liggend. Laten we de twee technologieën samen gebruiken, niet alleen omdat we dat kunnen, maar ook omdat we gaandeweg iets over XPath zullen leren, waardoor het een extra hulpmiddel in je stapel wordt - een hulpmiddel waarvan je misschien niet wist dat het er altijd al was! Het probleem is dat de document.evaluate-methode van JavaScript en de verschillende queryselectiemethoden die we gebruiken met de CSS-API's voor JavaScript incompatibel zijn. Ik heb een compatibele query-API gemaakt om ons op weg te helpen, hoewel ik er weliswaar niet veel over heb nagedacht, omdat het afwijkt van wat we hier doen. Hier is een vrij eenvoudig werkend voorbeeld van een herbruikbare queryconstructor: Zie de Pen queryXPath [gevorkt] door Bryan Rasmussen. Ik heb twee methoden aan het documentobject toegevoegd: queryCSSSelectors (wat in wezen querySelectorAll is) en queryXPaths. Beide retourneren een queryResults-object:
{ queryType: knooppunten | tekenreeks | nummer | booleaans, resultaten: any[] // html-elementen, xml-elementen, strings, getallen, booleans, queryCSSSelectors: (query: string, wijzig: boolean) => queryResults, queryXpaths: (query: string, wijzig: boolean) => queryResults }
De functies queryCSSSelectors en queryXpaths voeren de query uit die u ze geeft over de elementen in de resultatenarray, zolang de resultatenarray uiteraard van het type knooppunten is. Anders retourneert het een queryResult met een lege array en een type knooppunten. Als de eigenschap wijzigen is ingesteld op true, zullen de functies hun eigen queryResults wijzigen. Dit mag in geen geval in een productieomgeving worden gebruikt. Ik doe het op deze manier puur om de verschillende effecten van het samen gebruiken van de twee query-API's te demonstreren. Voorbeeldvragen Ik wil een paar voorbeelden laten zien van verschillende XPath-query's die enkele van de krachtige dingen die ze kunnen doen demonstreren en hoe ze kunnen worden gebruikt in plaats van andere benaderingen. Het eerste voorbeeld is //li/text(). Dit vraagt alle li-elementen op en retourneert hun tekstknooppunten. Dus als we de volgende HTML zouden opvragen:
- één
- twee
- drie
…dit is wat er terugkomt:
{"queryType ": xpathEvaluate", resultaten":["één", "twee", "drie"],"resultType: "string"}
Met andere woorden, we krijgen de volgende array: ["één", "twee", "drie"]. Normaal gesproken zou je de li-elementen opvragen om dat te krijgen, het resultaat van die zoekopdracht in een array veranderen, de array in kaart brengen en het tekstknooppunt van elk element retourneren. Maar we kunnen dat beknopter doen met XPath: document.queryXPaths("//li/text()").resultaten.
Merk op dat de manier om een tekstknooppunt te verkrijgen is door text() te gebruiken, wat lijkt op een functiehandtekening - en dat is het ook. Het retourneert het tekstknooppunt van een element. In ons voorbeeld zijn er drie li-elementen in de opmaak, die elk tekst bevatten ("één", "twee" en "drie").
Laten we nog een voorbeeld bekijken van een text()-query. Stel dat dit onze opmaak is:
Laten we een query schrijven die de href-attribuutwaarde retourneert: document.queryXPaths("//a[text() = 'Aanmelden']/@href").resultaten.
Dit is een XPath-query op het huidige document, net als het laatste voorbeeld, maar deze keer retourneren we het href-attribuut van een link (een element) die de tekst ‘Aanmelden’ bevat. De werkelijke terugresultaat is ["/login.html"]. Overzicht van XPath-functies Er zijn een aantal XPath-functies, en u bent er waarschijnlijk niet bekend mee. Ik denk dat er verschillende zijn die de moeite waard zijn om te weten, waaronder de volgende:
starts-withAls een tekst begint met een bepaald ander tekstvoorbeeld, retourneert starts-with(@href, 'http:') true als een href-attribuut begint met http:. bevatAls een tekst een bepaald ander tekstvoorbeeld bevat, retourneert contain(text(), "Smashing Magazine") waar als een tekstknooppunt ergens de woorden "Smashing Magazine" bevat. countRetourneert een telling van het aantal overeenkomsten dat een zoekopdracht bevat. count(//*[starts-with(@href, 'http:']) retourneert bijvoorbeeld een telling van het aantal links in het contextknooppunt dat elementen bevat met een href-attribuut dat de tekst bevat die begint met http:. substringWerkt als JavaScript-substring, behalve dat je de string als argument doorgeeft. Substring("mijn tekst", 2, 4) retourneert bijvoorbeeld "y t". substring-beforeRetourneert het deel van een tekenreeks vóór een andere tekenreeks. Substing-before("mijn tekst", " ") retourneert bijvoorbeeld "mijn". Op dezelfde manier retourneert substring-before("hi", "doei") een lege tekenreeks. substring-afterRetourneert het deel van een tekenreeks na een andere tekenreeks. Substing-after("mijn tekst", " ") retourneert bijvoorbeeld "tekst". Op dezelfde manier retourneert substring-after("hi", "doei") een lege tekenreeks. normalize-space Retourneert de argumentreeks waarbij de witruimte is genormaliseerd door de voor- en achterliggende witruimte te verwijderen en reeksen witruimtetekens te vervangen door een enkele spatie. notRetourneert een booleaanse waarde true als het argument false is, anders false. trueRetourneert boolean waar. falseRetourneert booleaanse waarde false. concat Hetzelfde als JavaScript concat, behalve dat je het niet als methode op een string uitvoert. In plaats daarvan voer je alle strings in die je wilt samenvoegen. string-lengthDit is niet hetzelfde als JavaScript string-length, maar retourneert eerder de lengte van de string die eraan wordt gegeven als argument. vertalenDit neemt een string en verandert het tweede argument in het derde argument. Translate("abcdef", "abc", "XYZ") levert bijvoorbeeld XYZdef op.
Afgezien van deze specifieke XPath-functies zijn er een aantal andere functies die precies hetzelfde werken als hun JavaScript-tegenhangers (of tegenhangers in vrijwel elke programmeertaal) die u waarschijnlijk ook nuttig zou vinden, zoals vloer, plafond, rond, som, enzovoort. De volgende demo illustreert elk van deze functies: Zie de Pen XPath Numerieke functies [gevorkt] door Bryan Rasmussen. Merk op dat, net als de meeste functies voor tekenreeksmanipulatie, veel van de numerieke functies één enkele invoer vereisen. Dit komt natuurlijk omdat ze bedoeld zijn om te worden gebruikt voor het uitvoeren van query's, zoals in het laatste XPath-voorbeeld: //li[vloer(tekst()) > 250]/@val
Als u ze gebruikt, zoals de meeste voorbeelden doen, zult u deze uiteindelijk uitvoeren op het eerste knooppunt dat overeenkomt met het pad. Er zijn ook enkele typeconversiefuncties die u waarschijnlijk moet vermijden, omdat JavaScript al zijn eigen typeconversieproblemen kent. Maar er kunnen momenten zijn waarop u een tekenreeks naar een getal wilt converteren om deze met een ander getal te vergelijken. Functies die het type van iets instellen zijn Boolean, Number, String en Node. Dit zijn de belangrijke XPath-gegevenstypen. En zoals je je misschien kunt voorstellen, kunnen de meeste van deze functies worden gebruikt op datatypes die geen DOM-knooppunten zijn. Substring-after neemt bijvoorbeeld een string zoals we al hebben besproken, maar het kan de string van een href-attribuut zijn. Het kan ook gewoon een string zijn:
const testSubstringAfter = document.queryXPaths("substring-after('hallo wereld',' ')");
Uiteraard geeft dit voorbeeld ons de resultatenreeks terug als ["wereld"]. Om dit in actie te laten zien, heb ik een demopagina gemaakt met functies tegen dingen die geen DOM-knooppunten zijn: Zie de Pen queryXPath [gevorkt] door Bryan Rasmussen. Let op het verrassende aspect van de vertaalfunctie, namelijk dat als je een karakter hebt in het tweede argument (d.w.z. de lijst met karakters die je wilt vertalen) en geen overeenkomend karakter om naar te vertalen, dat karakter uit de uitvoer wordt verwijderd. Dus dit:
translate('Hallo, mijn naam is Inigo Montoya, je hebt mijn vader vermoord, bereid je voor om te sterven','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…resulteert in de string, inclusief spaties: [" * * ** "]
Dit betekent dat de letter “a” wordt vertaald naar een asterisk (*), maar elk ander teken dat geen vertaling heeft gezien de doelreeks, wordt volledig verwijderd. De witruimte is het enige dat we nog hebbentussen de vertaalde “a”-tekens. Dan weer deze vraag:
translate('Hallo, mijn naam is Inigo Montoya, je hebt mijn vader vermoord, bereid je voor om te sterven','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','**************************************************')")
…heeft het probleem niet en geeft een resultaat dat er als volgt uitziet:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Het zal je misschien opvallen dat er in JavaScript geen gemakkelijke manier is om precies te doen wat de XPath-vertaalfunctie doet, hoewel ReplaceAll in veel gevallen met reguliere expressies dit wel aankan. Je zou dezelfde aanpak kunnen gebruiken die ik heb gedemonstreerd, maar dat is niet optimaal als je alleen maar de tekenreeksen wilt vertalen. De volgende demo omhult de vertaalfunctie van XPath om een JavaScript-versie te bieden: Zie de Pen-vertaalfunctie [gevorkt] door Bryan Rasmussen. Waar zou je zoiets kunnen gebruiken? Overweeg Caesar Cipher-codering met een offset van drie plaatsen (bijvoorbeeld de allerbeste codering uit 48 v.Chr.):
translate("Caesar is van plan de Rubicon over te steken!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
De invoertekst “Caesar is van plan de Rubicon over te steken!” resulteert in “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Om nog een snel voorbeeld van verschillende mogelijkheden te geven, heb ik een metaalfunctie gemaakt die een stringinvoer nodig heeft en een vertaalfunctie gebruikt om de tekst terug te geven, inclusief alle tekens die umlauten bevatten. Zie de metalen Pen-functie [gevorkt] door Bryan Rasmussen.
const metaal = (str) => { return vertalen(str, "AOUaou", "ÄÖÜäöü"); }
En als de tekst “Motley Crue regels, rock on dudes!” wordt gegeven, retourneert “Mötley Crüe rüles, röck ön düdes!” Het is duidelijk dat je allerlei soorten parodiegebruik van deze functie kunt maken. Als jij dat bent, dan zou dit TVTropes-artikel je voldoende inspiratie moeten bieden. CSS gebruiken met XPath Denk aan onze belangrijkste reden om CSS-selectors samen met XPath te gebruiken: CSS begrijpt vrijwel wat een klasse is, terwijl het beste wat je met XPath kunt doen, stringvergelijkingen van het klassenattribuut is. Dat zal in de meeste gevallen werken. Maar als u ooit in een situatie zou terechtkomen waarin iemand bijvoorbeeld klassen heeft gemaakt met de namen .primaryLinks en .primaryLinks2 en u XPath gebruikt om de klasse .primaryLinks op te halen, dan zult u waarschijnlijk tegen problemen aanlopen. Zolang er niets geks is, zou je waarschijnlijk XPath gebruiken. Maar het spijt me te moeten melden dat ik op plaatsen heb gewerkt waar mensen dat soort gekke dingen doen. Hier is nog een demo waarin CSS en XPath samen worden gebruikt. Het laat zien wat er gebeurt als we de code gebruiken om een XPath uit te voeren op een contextknooppunt dat niet het knooppunt van het document is. Zie de Pen css en xpath samen [gevorkt] door Bryan Rasmussen. De CSS-query is .relatedarticles a, die de twee a-elementen ophaalt in een div waaraan een klasse .relatedarticles is toegewezen. Daarna volgen drie ‘slechte’ queries, dat wil zeggen queries die niet doen wat we willen dat ze doen als ze met deze elementen als contextknooppunt worden uitgevoerd. Ik kan uitleggen waarom ze zich anders gedragen dan je zou verwachten. De drie slechte zoekopdrachten in kwestie zijn:
//text(): Geeft alle tekst in het document terug. //a/text(): Geeft alle tekst binnen de links in het document terug. ./a/text(): Geeft geen resultaten.
De reden voor deze resultaten is dat hoewel uw context een element is dat wordt geretourneerd door de CSS-query, // in strijd is met het hele document. Dit is de kracht van XPath; CSS kan niet van een knooppunt omhoog gaan naar een voorouder en vervolgens naar een broer of zus van die voorouder, en vervolgens naar beneden lopen naar een afstammeling van die broer of zus. Maar XPath kan dat wel. Ondertussen ondervraagt ./ de onderliggende knooppunten, waarbij de punt (.) het huidige knooppunt vertegenwoordigt, en de schuine streep (/) het gaan naar een onderliggend knooppunt vertegenwoordigt. Of het een attribuut, element of tekst is, wordt bepaald door het volgende deel van het pad. Maar er is geen onderliggend element geselecteerd door de CSS-query, dus retourneert die query ook niets. Er zijn drie goede vragen in die laatste demo:
.//tekst(), ./tekst(), normaliseer-spatie(./text()).
De normalize-space-query demonstreert het gebruik van de XPath-functie, maar lost ook een probleem op dat is opgenomen in de andere query's. De HTML is als volgt opgebouwd:
Automatiseer uw functietests met Selenium WebDriver
De query retourneert een regelinvoer aan het begin en einde van het tekstknooppunt,en normalize-space verwijdert dit. Het gebruik van een XPath-functie die iets anders retourneert dan een Booleaanse waarde met een invoer-XPath is van toepassing op andere functies. De volgende demo toont een aantal voorbeelden: Zie de voorbeelden van Pen xpath-functies [gevorkt] door Bryan Rasmussen. Het eerste voorbeeld toont een probleem waar u op moet letten. Concreet de volgende code:
document.queryXPaths("substring-after(//a/@href,'https://')");
… retourneert één tekenreeks:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Het is logisch, toch? Deze functies retourneren geen arrays, maar eerder afzonderlijke tekenreeksen of afzonderlijke getallen. Als u de functie ergens met meerdere resultaten uitvoert, wordt alleen het eerste resultaat geretourneerd. Het tweede resultaat laat zien wat we echt willen:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Wat een array van twee strings retourneert:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/", "www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath-functies kunnen net als functies in JavaScript worden genest. Dus als we de URL-structuur van Smashing Magazine kennen, kunnen we het volgende doen (het gebruik van sjabloonliterals wordt aanbevolen): `vertalen( subtekenreeks( substring-after(./@href, ‘www.smashingmagazine.com/') ,9), '/','')`
Dit wordt een beetje te complex in de mate dat er commentaar nodig is dat beschrijft wat het doet: neem de hele URL van het href-attribuut na www.smashingmagazine.com/, verwijder de eerste negen tekens en vertaal vervolgens het slash-teken (/) naar niets om de eindigende slash te verwijderen. De resulterende array:
["feature-testing-selenium-webdriver","geautomatiseerde testresultaten-verbetering-toegankelijkheid"]
Meer XPath-gebruiksscenario's XPath kan echt uitblinken tijdens het testen. De reden is niet moeilijk te begrijpen, aangezien XPath kan worden gebruikt om elk element in de DOM op te halen, vanuit elke positie in de DOM, terwijl CSS dat niet kan. Je kunt er niet op rekenen dat CSS-klassen consistent blijven in veel moderne bouwsystemen, maar met XPath kunnen we robuustere overeenkomsten maken met betrekking tot wat de tekstinhoud van een element is, ongeacht een veranderende DOM-structuur. Er is onderzoek gedaan naar technieken waarmee je veerkrachtige XPath-testen kunt maken. Niets is erger dan dat tests uitvallen en mislukken, alleen maar omdat een CSS-selector niet meer werkt omdat iets een nieuwe naam heeft gekregen of is verwijderd. XPath is ook erg goed in het extraheren van meerdere locators. Er zijn meerdere manieren om XPath-query's te gebruiken om een element te matchen. Hetzelfde geldt voor CSS. Maar XPath-query's kunnen op een meer gerichte manier inzoomen op zaken, waardoor wordt beperkt wat er wordt geretourneerd, zodat u een specifieke overeenkomst kunt vinden waar er meerdere mogelijke overeenkomsten kunnen zijn. We kunnen bijvoorbeeld XPath gebruiken om een specifiek h2-element terug te geven dat zich in een div bevindt en die onmiddellijk volgt op een zuster-div die op zijn beurt een onderliggend afbeeldingselement bevat met een data-testID="leader" attribuut erop:
begrijp deze kop niet
Begrijp deze kop ook niet
De koptekst voor de leiderafbeelding
Dit is de vraag: document.queryXPaths(` //div[ volgende broer of zus::div[1] /img[@data-testID='leider'] ] /h2/ tekst() `);
Laten we een demo bekijken om te zien hoe dat allemaal samenkomt: Zie de Pen Complex H2 Query [gevorkt] door Bryan Rasmussen. Dus ja. Er zijn veel mogelijke paden naar elk element in een test met XPath. XSLT 1.0 Beëindiging Ik zei al vroeg dat het Chrome-team van plan is XSLT 1.0-ondersteuning uit de browser te verwijderen. Dat is belangrijk omdat XSLT 1.0 XML-gerichte programmering gebruikt voor documenttransformatie die op zijn beurt afhankelijk is van XPath 1.0, wat in de meeste browsers te vinden is. Wanneer dat gebeurt, verliezen we een belangrijk onderdeel van XPath. Maar gezien het feit dat XPath echt geweldig is voor het schrijven van tests, vind ik het onwaarschijnlijk dat XPath als geheel binnenkort zal verdwijnen. Dat gezegd hebbende, heb ik gemerkt dat mensen geïnteresseerd raken in een functie wanneer deze wordt verwijderd. En dat geldt zeker in het geval dat XSLT 1.0 wordt beëindigd. Er vindt een hele discussie plaats bij Hacker News vol argumenten tegen de afschaffing. Het bericht zelf is een goed voorbeeld van het creëren van een blogframework met XSLT. JijJe kunt de discussie zelf lezen, maar er wordt ingegaan op de manier waarop JavaScript kan worden gebruikt als vulstuk voor XLST om dat soort gevallen af te handelen. Ik heb ook suggesties gezien dat browsers SaxonJS zouden moeten gebruiken, wat een poort is naar de Saxon XSLT-, XQUERY- en XPath-engines van JavaScript. Dat is een interessant idee, vooral omdat Saxon-JS de huidige versie van deze specificaties implementeert, terwijl er geen browser is die een versie van XPath of XSLT na 1.0 implementeert, en geen browser die XQuery implementeert. Ik nam contact op met Norm Tovey-Walsh van Saxonica, het bedrijf achter SaxonJS en andere versies van de Saxon-motor. Hij zei: “Als een browserleverancier geïnteresseerd zou zijn om SaxonJS als uitgangspunt te nemen voor het integreren van moderne XML-technologieën in de browser, zouden we dit graag met hen bespreken.” – Norm Tovey-Walsh
Maar ook toegevoegd: "Ik zou zeer verrast zijn als iemand zou denken dat het nemen van SaxonJS in zijn huidige vorm en het ongewijzigd in de browser laten bouwen de ideale aanpak zou zijn. Een browserleverancier zou, vanwege het feit dat zij de browser bouwen, de integratie op een veel dieper niveau kunnen benaderen dan we 'van buitenaf' kunnen doen. "- Norm Tovey-Walsh
Het is vermeldenswaard dat de opmerkingen van Tovey-Walsh ongeveer een week vóór de aankondiging van de beëindiging van de XSLT kwamen. Conclusie Ik kan doorgaan. Maar ik hoop dat dit de kracht van XPath heeft aangetoond en je voldoende voorbeelden heeft gegeven die laten zien hoe je het kunt gebruiken om geweldige dingen te bereiken. Het is een perfect voorbeeld van oudere technologie in de browserstack die vandaag de dag nog steeds veel nut heeft, zelfs als je nooit hebt geweten dat het bestond of nooit hebt overwogen ernaar te streven. Verder lezen
“De veerkracht van geautomatiseerde webtests verbeteren met natuurlijke taal” (ACM Digital Library) door Maroun Ayli, Youssef Bakouny, Nader Jalloul en Rima Kilany Dit artikel biedt veel XPath-voorbeelden voor het schrijven van veerkrachtige tests. XPath (MDN) Dit is een uitstekende plaats om te beginnen als u een technische uitleg wilt over hoe XPath werkt. XPath-tutorial (ZVON) Ik vond deze tutorial het nuttigst bij mijn eigen leerproces, dankzij een schat aan voorbeelden en duidelijke uitleg. XPatherMet deze interactieve tool kunt u rechtstreeks met de code werken.
