Olen ollut etupäässä tarpeeksi kauan nähdäkseni trendin vuosien varrella: nuoremmat kehittäjät työskentelevät uuden ohjelmoinnin paradigman kanssa ymmärtämättä sen historiallista kontekstia. Tietysti on täysin ymmärrettävää, kun ei tiedä jotain. Verkko on erittäin suuri paikka, jossa on erilaisia taitoja ja erikoisuuksia, emmekä aina tiedä, mitä emme tiedä. Tämän alan oppiminen on pikemminkin jatkuvaa matkaa kuin jotain, joka tapahtuu kerran ja päättyy. Esimerkki: Joku tiimistäni kysyi, onko mahdollista kertoa, siirtyvätkö käyttäjät pois tietystä käyttöliittymän välilehdestä. Huomasin JavaScriptin ennen latausta -tapahtuman. Mutta ne, jotka ovat käsitelleet tätä aiemmin, tietävät tämän olevan mahdollista, koska he ovat saaneet hälytyksiä tallentamattomista tiedoista muilla sivustoilla, joille ennen purkamista on tyypillinen käyttötapaus. Huomasin myös sivunPiilota ja näkyvyydenmuutos -tapahtumat kollegalleni hyvässä mittakaavassa. Kuinka tiesin siitä? Koska se tuli esille toisessa projektissa, en siksi, että opiskelin sitä alun perin oppiessani JavaScriptiä. Tosiasia on, että nykyaikaiset etupään kehykset seisovat niitä edeltäneiden teknologiajättien harteilla. Ne abstraktioivat kehityskäytännöt, usein paremman kehittäjäkokemuksen saavuttamiseksi, mikä vähentää tai jopa eliminoi tarpeen tuntea tai koskettaa niitä, jotka ovat perinteisesti olleet tärkeitä käyttöliittymäkonsepteja, jotka kaikkien pitäisi luultavasti tietää. Harkitse CSS-objektimallia (CSSOM). Saatat odottaa, että jokaisella CSS:n ja JavaScriptin parissa työskentelevillä on paljon käytännön kokemusta CSSOM:sta, mutta näin ei aina ole. Työssäni oli React-projekti verkkokauppasivustolle, jossa meidän piti ladata tyylitaulukko tällä hetkellä valitulle maksupalveluntarjoajalle. Ongelmana oli, että tyylitaulukko latautui jokaiselle sivulle, kun sitä todella tarvittiin vain tietyllä sivulla. Kehittäjä, jonka tehtävänä oli saada tämä tapahtumaan, ei ollut koskaan ladannut tyylitaulukkoa dynaamisesti. Tämä on jälleen täysin ymmärrettävää, kun React abstraktioi pois perinteisestä lähestymistavasta, johon olet ehkä pyrkinyt. CSSOM ei todennäköisesti ole jotain, jota tarvitset jokapäiväisessä työssäsi. Mutta on todennäköistä, että joudut olemaan vuorovaikutuksessa sen kanssa jossain vaiheessa, jopa yksittäistapauksessa. Nämä kokemukset inspiroivat minua kirjoittamaan tämän artikkelin. Luonnossa on monia olemassa olevia verkko-ominaisuuksia ja -tekniikoita, joihin et ehkä koskaan kosketa suoraan päivittäisessä työssäsi. Ehkä olet melko uusi verkkokehityksessä etkä yksinkertaisesti ole tietoinen niistä, koska olet täynnä tietyn kehyksen abstraktiota, joka ei vaadi sinua tuntemaan sitä syvällisesti tai edes ollenkaan. Puhun erityisesti XML:stä, jonka monet meistä tietävät, että se on ikivanha kieli, joka ei ole täysin erilainen kuin HTML. Otan tämän esille, koska viimeaikaiset WHATWG-keskustelut ehdottavat, että merkittävä osa XSLT-ohjelmointina tunnetusta XML-pinosta pitäisi poistaa selaimista. Tämä on juuri sellaista vanhempaa, olemassa olevaa teknologiaa, joka meillä on ollut vuosia ja jota voitaisiin käyttää johonkin niin käytännölliseen kuin tiimini CSSOM-tilanteeseen. Oletko työskennellyt XSLT:n kanssa aiemmin? Katsotaanpa, nojaudummeko voimakkaasti tähän vanhaan tekniikkaan ja hyödynnämmekö sen ominaisuuksia XML-kontekstin ulkopuolella ratkaistaksemme tämän päivän todellisia ongelmia. XPath: Central API Tärkein XML-tekniikka, joka on ehkä hyödyllisin suoran XML-perspektiivin ulkopuolella, on XPath, kyselykieli, jonka avulla voit löytää minkä tahansa solmun tai attribuutin merkintäpuusta yhdellä juurielementillä. Minulla on henkilökohtainen kiintymys XSLT:tä kohtaan, mutta se perustuu myös XPathiin, ja henkilökohtainen kiintymys on jätettävä syrjään tärkeysjärjestykseen. XSLT:n poistamisen argumentissa ei mainita XPathia, joten oletan, että se on edelleen sallittua. Se on hyvä, koska XPath on keskeinen ja tärkein API tässä teknologiasarjassa, varsinkin kun yritetään löytää jotain käytettävää normaalin XML-käytön ulkopuolella. Se on tärkeää, koska vaikka CSS-valitsimia voidaan käyttää useimpien sivusi elementtien löytämiseen, ne eivät löydä niitä kaikkia. Lisäksi CSS-valitsimia ei voida käyttää elementin löytämiseen sen nykyisen sijainnin perusteella DOM:ssa. XPath voi. Jotkut teistä, jotka lukevat tätä, saattavat tuntea XPathin, ja jotkut eivät. XPath on melko suuri teknologia-alue, enkä todellakaan voi opettaa kaikkia perusasioita ja näyttää sinulle hienoja asioita sen kanssa yhdessä tällaisessa artikkelissa. Yritin itse asiassa kirjoittaa tuon artikkelin, mutta keskimääräinen Smashing Magazine -julkaisu ei ylitä 5 000 sanaa. Olin jo yli2000 sanaa, kun perusasiat ovat vasta puolivälissä. Joten aion tehdä hienoja juttuja XPathilla ja annan sinulle linkkejä, joita voit käyttää perusasioissa, jos pidät tätä mielenkiintoista. XPathin ja CSS:n yhdistäminen XPath voi tehdä monia asioita, joita CSS-valitsijat eivät voi kysellä elementtejä. Mutta CSS-valitsimet voivat myös tehdä joitain asioita, joita XPath ei voi, nimittäin kyselyn elementtejä luokan nimen perusteella.
CSS XPath .myClass /*[contains(@class, "myClass")]
Tässä esimerkissä CSS kyselee elementtejä, jotka sisältävät .myClass-luokan nimen. Samaan aikaan XPath-esimerkki hakee elementtejä, jotka sisältävät attribuuttiluokan merkkijonolla "myClass". Toisin sanoen se valitsee elementtejä, joissa on myClass missä tahansa määritteessä, mukaan lukien elementit, joiden luokkanimi on .myClass - sekä elementit, joiden merkkijonossa on "myClass", kuten .myClass2. XPath on siinä mielessä laajempi. Joten ei. En ehdota, että meidän pitäisi heittää pois CSS ja alkaa valita kaikki elementit XPathin kautta. Se ei ole pointti. Asia on siinä, että XPath voi tehdä asioita, joita CSS ei voi ja voisi edelleen olla erittäin hyödyllinen, vaikka se on selainpinon vanha tekniikka, eikä se ehkä vaikuta itsestään selvältä ensi silmäyksellä. Käyttäkäämme kahta tekniikkaa yhdessä, ei vain siksi, että voimme, vaan siksi, että opimme prosessin aikana jotain XPathista, mikä tekee siitä toisen työkalun pinossasi – sellaisen, jota et ehkä tiennyt, että se on ollut olemassa koko ajan! Ongelmana on, että JavaScriptin document.evaluate-menetelmä ja erilaiset kyselynvalintamenetelmät, joita käytämme JavaScriptin CSS-sovellusliittymien kanssa, eivät ole yhteensopivia. Olen tehnyt yhteensopivan kyselysovellusliittymän saadakseni meidät alkuun, vaikka tosin en ole ajatellut sitä paljon, koska se poikkeaa siitä, mitä teemme täällä. Tässä on melko yksinkertainen toimiva esimerkki uudelleenkäytettävästä kyselyn rakentajasta: Katso Bryan Rasmussenin Pen queryXPath [forked]. Olen lisännyt asiakirjaobjektiin kaksi menetelmää: queryCSSSelectors (joka on olennaisesti querySelectorAll) ja queryXPaths. Molemmat palauttavat queryResults-objektin:
{ kyselytyyppi: solmut | merkkijono | numero | boolen, tulokset: kaikki [] // html-elementit, xml-elementit, merkkijonot, numerot, loogiset arvot, queryCSSSelectors: (query: string, amend: boolean) => queryResults, queryXpaths: (kysely: merkkijono, amend: boolean) => queryResults }
Funktiot queryCSSSelectors ja queryXpaths suorittavat niille antamasi kyselyn tulostaulukon elementtien päällä, kunhan tulostaulukko on tietysti solmutyyppiä. Muussa tapauksessa se palauttaa queryResultin, jossa on tyhjä taulukko ja tietyntyyppiset solmut. Jos amend-ominaisuuden arvoksi on asetettu tosi, funktiot muuttavat omia kyselytuloksiaan. Tätä ei saa missään tapauksessa käyttää tuotantoympäristössä. Teen sen tällä tavalla vain osoittaakseni kahden kyselyn API:n yhteiskäytön eri vaikutukset. Esimerkkikyselyt Haluan näyttää muutamia esimerkkejä erilaisista XPath-kyselyistä, jotka osoittavat joitain tehokkaita asioita, joita ne voivat tehdä ja kuinka niitä voidaan käyttää muiden lähestymistapojen sijasta. Ensimmäinen esimerkki on //li/text(). Tämä kysyy kaikki li-elementit ja palauttaa niiden tekstisolmut. Jos siis kysytään seuraavaa HTML-koodia:
- yksi
- kaksi
- kolme
…tämä palautetaan:
{"queryType":"xpathEvaluate","results":["yksi","kaksi","kolme"],"resultType":"string"}
Toisin sanoen saamme seuraavan taulukon: ["yksi","kaksi","kolme"]. Normaalisti sinun tulee kysyä li-elementtejä saadaksesi sen, muuntaa kyselyn tulos taulukoksi, yhdistää taulukko ja palauttaa kunkin elementin tekstisolmu. Mutta voimme tehdä sen tiiviimmin XPathilla: document.queryXPaths("//li/text()").tulokset.
Huomaa, että tapa saada tekstisolmu on käyttää text(), joka näyttää funktion allekirjoitukselta - ja se on sitä. Se palauttaa elementin tekstisolmun. Esimerkissämme merkinnöissä on kolme li-elementtiä, joista jokainen sisältää tekstiä ("yksi", "kaksi" ja "kolme").
Katsotaanpa vielä yhtä esimerkkiä teksti()-kyselystä. Oletetaan, että tämä on meidän merkintä:
Kirjoitetaan kysely, joka palauttaa href-attribuutin arvon: document.queryXPaths("//a[text() = 'Kirjaudu sisään']/@href").tulokset.
Tämä on XPath-kysely nykyisessä asiakirjassa, kuten edellisessä esimerkissä, mutta tällä kertaa palautetaan linkin (elementin) href-attribuutti, joka sisältää tekstin "Kirjaudu sisään". Varsinainen palasitulos on ["/login.html"]. XPath-funktioiden yleiskatsaus XPath-funktioita on useita, etkä todennäköisesti tunne niitä. Mielestäni on useita, joista kannattaa tietää, mukaan lukien seuraavat:
starts-withJos teksti alkaa tietyllä muulla tekstiesimerkillä, starts-with(@href, 'http:') palauttaa arvon tosi, jos href-attribuutti alkaa http::llä. includeJos teksti sisältää tietyn muun tekstiesimerkin, sisältää(text(), "Smashing Magazine") palauttaa tosi, jos tekstisolmu sisältää sanat "Smashing Magazine" missä tahansa. countPalauttaa määrän, kuinka monta vastaavuutta kyselyllä on. Esimerkiksi count(//*[starts-with(@href, 'http:']) palauttaa määrän siitä, kuinka monessa kontekstisolmun linkissä on elementtejä, joissa on href-attribuutti, joka sisältää http:-alkuisen tekstin. substringToimii kuten JavaScript-alimerkkijono, paitsi että annat merkkijonon argumenttina. Esimerkiksi alimerkkijono("oma teksti", 2, 4) palauttaa "y t". substring-beforePalauttaa merkkijonon osan ennen toista merkkijonoa. Esimerkiksi substing-befor("oma teksti", " ") palauttaa "minun". Vastaavasti substring-before("hi","hei") palauttaa tyhjän merkkijonon. substring-afterPalauttaa merkkijonon osan toisen merkkijonon perään. Esimerkiksi substing-after("oma teksti", " ") palauttaa "teksti". Vastaavasti substring-after("hi","hei") palauttaa tyhjän merkkijonon. normalize-space Palauttaa argumenttimerkkijonon välilyönnillä, jotka on normalisoitu poistamalla alku- ja loppuvälilyönnit ja korvaamalla välilyöntimerkkijonot yhdellä välilyönnillä. notPalauttaa loogisen arvon tosi, jos argumentti on epätosi, muuten epätosi. truePalauttaa boolen tosi. falsePalauttaa boolen epätosi. concatSama asia kuin JavaScript concat, paitsi että et suorita sitä menetelmänä merkkijonossa. Sen sijaan laitat kaikki merkkijonot, jotka haluat ketjuttaa. string-lengthTämä ei ole sama kuin JavaScript-merkkijonon pituus, vaan se palauttaa argumenttina antamansa merkkijonon pituuden. translateThis ottaa merkkijonon ja muuttaa toisen argumentin kolmanneksi argumentiksi. Esimerkiksi translate("abcdef", "abc", "XYZ") tulostaa XYZdef.
Näiden erityisten XPath-toimintojen lisäksi on monia muita toimintoja, jotka toimivat aivan samoin kuin niiden JavaScript-vastineet - tai vastineet periaatteessa millä tahansa ohjelmointikielellä -, joita luultavasti myös pidät hyödyllisinä, kuten lattia, katto, pyöreä, summa ja niin edelleen. Seuraava esittely havainnollistaa jokaista näistä toiminnoista: Katso Bryan Rasmussenin Pen XPath Numerical -funktiot [haarukka]. Huomaa, että kuten useimmat merkkijonojen käsittelytoiminnot, monet numeeriset funktiot ottavat yhden syötteen. Tämä tietysti johtuu siitä, että niitä on tarkoitus käyttää kyselyihin, kuten edellisessä XPath-esimerkissä: //li[floor(text()) > 250]/@val
Jos käytät niitä, kuten useimmat esimerkit tekevät, suoritat sen ensimmäisellä polkua vastaavalla solmulla. On myös joitain tyyppimuunnostoimintoja, joita sinun pitäisi todennäköisesti välttää, koska JavaScriptillä on jo omat tyyppimuunnosongelmansa. Mutta voi joskus olla, että haluat muuntaa merkkijonon numeroksi tarkistaaksesi sen johonkin toiseen numeroon. Funktiot, jotka määrittävät jonkin tyypin, ovat boolean, numero, merkkijono ja solmu. Nämä ovat tärkeitä XPath-tietotyyppejä. Ja kuten voit kuvitella, useimpia näistä toiminnoista voidaan käyttää tietotyypeissä, jotka eivät ole DOM-solmuja. Esimerkiksi alimerkkijono-after ottaa merkkijonon, kuten olemme jo käsitelleet, mutta se voi olla merkkijono href-attribuutista. Se voi olla myös vain merkkijono:
const testSubstringAfter = document.queryXPaths("substring-after('hei maailma',' ')");
Ilmeisesti tämä esimerkki palauttaa meille tulostaulukon nimellä ["maailma"]. Tämän näyttämiseksi toiminnassa olen tehnyt esittelysivun käyttämällä toimintoja vastaan asioita, jotka eivät ole DOM-solmuja: Katso Bryan Rasmussenin Pen queryXPath [forked]. Sinun tulee huomioida käännösfunktion yllättävä puoli, joka on se, että jos sinulla on merkki toisessa argumentissa (eli käännettävien merkkien luettelossa) eikä vastaavaa merkkiä ole käännettävä, kyseinen merkki poistetaan tulosteesta. Eli tämä:
translate('Hei, nimeni on Inigo Montoya, tapoit isäni, valmistaudu kuolemaan','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…tulokset merkkijonoon, mukaan lukien välilyönnit: [" * * ** "]
Tämä tarkoittaa, että kirjain "a" käännetään tähdeksi (*), mutta kaikki muut merkit, joilla ei ole käännöstä kohdemerkkijonon perusteella, poistetaan kokonaan. Tyhjiö on kaikki, mitä meillä on jäljelläkäännettyjen "a"-merkkien välissä. Sitten vielä tämä kysely:
translate('Hei, nimeni on Inigo Montoya, tapoit isäni, valmistaudu kuolemaan','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','********************************************************'))
… ei ole ongelmaa ja antaa tuloksen, joka näyttää tältä:
"****** *** **** ** ***** ******* *** ****** ** ****** ******* *** ***"
Saatat huomata, että JavaScriptissä ei ole helppoa tapaa tehdä täsmälleen sitä, mitä XPath-käännöstoiminto tekee, vaikka monissa käyttötapauksissa Allin korvaaminen säännöllisillä lausekkeilla voi käsitellä sen. Voisit käyttää samaa lähestymistapaa, jonka olen osoittanut, mutta se on epäoptimaalista, jos haluat vain kääntää merkkijonot. Seuraava demo kääri XPathin käännöstoiminnon JavaScript-version tarjoamiseksi: Katso Bryan Rasmussenin kynän käännöstoiminto [forked]. Missä tällaista voisi käyttää? Harkitse Caesar Cipher -salausta, jossa on kolmipaikkainen siirtymä (esim. huippuluokan salaus vuodelta 48 eaa.):
translate("Caesar suunnittelee ylittävän Rubiconin!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Syöteteksti "Caesar suunnittelee Rubiconin ylittämistä!" tulokset "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Antaakseni toisen nopean esimerkin erilaisista mahdollisuuksista, tein metallifunktion, joka ottaa merkkijonon syötteen ja käyttää käännösfunktiota palauttamaan tekstin, mukaan lukien kaikki umlautit ottavat merkit. Katso Bryan Rasmussenin metallikynätoiminto [haarukka].
const metalli = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
Ja jos annetaan teksti "Motley Crue säännöt, rock on dudes!", palauttaa "Mötley Crüe rüles, röck ön düdes!" On selvää, että tästä toiminnosta voi olla kaikenlaisia parodiakäyttöjä. Jos se olet sinä, tämän TVTropes-artikkelin pitäisi tarjota sinulle runsaasti inspiraatiota. CSS:n käyttö XPathin kanssa Muista tärkein syymme käyttää CSS-valitsimia XPathin kanssa: CSS ymmärtää melko paljon, mikä luokka on, kun taas XPathilla parasta on luokkaattribuutin merkkijonovertailu. Se toimii useimmissa tapauksissa. Mutta jos joutuisit joskus tilanteeseen, jossa joku esimerkiksi loi luokat nimeltä .primaryLinks ja .primaryLinks2 ja käytät XPathia saadaksesi .primaryLinks-luokan, kohtaat todennäköisesti ongelmia. Niin kauan kuin ei ole mitään typerää, käytät todennäköisesti XPathia. Mutta olen surullinen voidessani kertoa, että olen työskennellyt paikoissa, joissa ihmiset tekevät tällaisia typeriä asioita. Tässä on toinen demo, jossa käytetään CSS:ää ja XPathia yhdessä. Se näyttää, mitä tapahtuu, kun käytämme koodia XPathin suorittamiseen kontekstisolmussa, joka ei ole asiakirjan solmu. Katso Pen css ja xpath yhdessä [haarukka], Bryan Rasmussen. CSS-kysely on .relatedarticles a, joka hakee kaksi a-elementtiä div-elementistä, jolle on määritetty .relatedarticles-luokka. Sen jälkeen on kolme "huonoa" kyselyä, toisin sanoen kyselyjä, jotka eivät tee sitä, mitä haluamme heidän tekevän, kun näitä elementtejä käytetään kontekstisolmuna. Voin selittää, miksi he käyttäytyvät eri tavalla kuin saatat odottaa. Nämä kolme huonoa kysymystä ovat:
//text(): Palauttaa asiakirjan kaiken tekstin. //a/text(): Palauttaa kaiken tekstin dokumentissa olevien linkkien sisällä. ./a/text(): Ei palauta tuloksia.
Syynä näihin tuloksiin on se, että vaikka kontekstisi on CSS-kyselystä palautettu elementti, // on koko asiakirjaa vastaan. Tämä on XPathin vahvuus; CSS ei voi siirtyä solmusta esi-isään ja sitten tuon esi-isän sisarukseen ja kävellä tämän sisaruksen jälkeläiseen. Mutta XPath voi. Sillä välin ./ kyselee nykyisen solmun lapsia, missä piste (.) edustaa nykyistä solmua ja vinoviiva (/) tarkoittaa siirtymistä johonkin lapsisolmuun - onko se attribuutti, elementti vai teksti, sen määrittää polun seuraava osa. Mutta CSS-kyselyn valitsemaa alielementtiä ei ole, joten kysely ei myöskään palauta mitään. Tuossa viime demossa on kolme hyvää kysymystä:
.//text(), ./text(), normalisoi-avaruus(./teksti()).
Normalisointiavaruuskysely osoittaa XPath-funktion käytön, mutta myös korjaa muihin kyselyihin sisältyvän ongelman. HTML on rakenteeltaan seuraava:
Ominaisuustestauksen automatisointi Selenium WebDriverilla
Kysely palauttaa rivinsiirron tekstisolmun alussa ja lopussa,ja normalisointi-avaruus poistaa tämän. Minkä tahansa XPath-funktion käyttäminen, joka palauttaa jotain muuta kuin loogisen arvon XPath-syötteen kanssa, koskee myös muita funktioita. Seuraava demo näyttää useita esimerkkejä: Katso Bryan Rasmussenin Pen xpath -funktioiden esimerkkejä [forked]. Ensimmäinen esimerkki osoittaa ongelman, jota sinun tulee varoa. Tarkemmin sanottuna seuraava koodi:
document.queryXPaths("substring-after(//a/@href,'https://')");
…palauttaa yhden merkkijonon:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Se on järkevää, eikö? Nämä funktiot eivät palauta taulukoita, vaan pikemminkin yksittäisiä merkkijonoja tai yksittäisiä numeroita. Toiminnon suorittaminen missä tahansa, jossa on useita tuloksia, palauttaa vain ensimmäisen tuloksen. Toinen tulos osoittaa, mitä todella haluamme:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Joka palauttaa kahden merkkijonon joukon:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath-funktiot voidaan upottaa samaan tapaan kuin JavaScriptin funktiot. Joten jos tiedämme Smashing Magazine -lehden URL-osoitteen rakenteen, voimme tehdä seuraavaa (suosittelemme malliliteraalien käyttöä): `käännä( osamerkkijono( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Tämä on tulossa hieman liian monimutkaiseksi siinä määrin, että se vaatii kommentteja, jotka kuvaavat sen toimintaa: ota kaikki URL-osoite href-attribuutista www.smashingmagazine.com/ jälkeen, poista ensimmäiset yhdeksän merkkiä ja käännä sitten vinoviiva (/) tyhjäksi päästäksesi eroon päättyvästä vinoviivasta. Tuloksena oleva matriisi:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
Lisää XPath-käyttötapauksia XPath voi todella loistaa testauksessa. Syytä ei ole vaikea nähdä, sillä XPathilla voidaan saada kaikki DOM:n elementit mistä tahansa DOM:n paikasta, kun taas CSS ei voi. Et voi luottaa siihen, että CSS-luokat pysyvät yhtenäisinä monissa nykyaikaisissa koontijärjestelmissä, mutta XPathin avulla pystymme tekemään vahvempia osumia elementin tekstisisällöstä riippumatta muuttuvasta DOM-rakenteesta. On tutkittu tekniikoita, joiden avulla voit tehdä joustavia XPath-testejä. Mikään ei ole pahempaa kuin testien hilseily ja epäonnistuminen vain siksi, että CSS-valitsin ei enää toimi, koska jotain on nimetty uudelleen tai poistettu. XPath on myös todella loistava useiden paikanninten poistamiseen. XPath-kyselyitä voidaan käyttää useammalla kuin yhdellä tavalla elementin vastaamiseen. Sama pätee CSS:n kanssa. XPath-kyselyt voivat kuitenkin perehtyä asioihin kohdistetummin, mikä rajoittaa palautettavia tietoja, jolloin voit löytää tietyn vastaavuuden, jossa voi olla useita mahdollisia osumia. Voimme esimerkiksi käyttää XPathia palauttamaan tietyn h2-elementin, joka sisältyy div-elementtiin, joka seuraa välittömästi sisarus-div-elementtiä, joka puolestaan sisältää alikuvaelementin data-testID="leader"-attribuutin kanssa:
älä ymmärrä tätä otsikkoa
Älä myöskään saa tätä otsikkoa
Johtokuvan otsikko
Tämä on kysely: document.queryXPaths(` //div[ seuraava-sisarus::div[1] /img[@data-testID='johtaja'] ] /h2/ teksti() `);
Pudotetaan esittelyyn nähdäksesi, kuinka tämä kaikki yhdistyy: Katso Bryan Rasmussenin Pen Complex H2 -kysely [haarukka]. Joten kyllä. XPath-testissä on monia mahdollisia polkuja mihin tahansa elementtiin. XSLT 1.0 vanhentunut Mainitsin jo varhain, että Chrome-tiimi aikoo poistaa XSLT 1.0 -tuen selaimesta. Se on tärkeää, koska XSLT 1.0 käyttää XML-keskeistä ohjelmointia dokumenttien muuntamiseen, joka puolestaan perustuu XPath 1.0:aan, jota löytyy useimmista selaimista. Kun näin tapahtuu, menetämme XPathin keskeisen osan. Mutta kun otetaan huomioon se tosiasia, että XPath on todella hyvä testien kirjoittamiseen, pidän epätodennäköisenä, että XPath kokonaisuudessaan katoaa pian. Olen kuitenkin huomannut, että ihmiset alkavat kiinnostua ominaisuudesta, kun se poistetaan. Ja se on varmasti totta, jos XSLT 1.0 poistetaan käytöstä. Hacker Newsissa käydään kokonainen keskustelu, joka on täynnä argumentteja käytöstä poistamista vastaan. Itse viesti on loistava esimerkki blogikehyksen luomisesta XSLT:n avulla. sinäVoit lukea keskustelun itse, mutta se käsittelee sitä, kuinka JavaScriptiä voidaan käyttää väliaineena XLST:lle tällaisten tapausten käsittelemiseksi. Olen myös nähnyt ehdotuksia siitä, että selaimet käyttävät SaxonJS:ää, joka on portti JavaScriptin Saxon XSLT-, XQUERY- ja XPath-koneille. Se on mielenkiintoinen ajatus, varsinkin kun Saxon-JS toteuttaa näiden teknisten määritelmien nykyisen version, kun taas ei ole selainta, joka toteuttaisi XPathin tai XSLT:n versiota 1.0:n jälkeistä versiota, eikä yhtään selainta, joka toteuttaisi XQuerya. Otin yhteyttä Norm Tovey-Walshiin Saxonicassa, SaxonJS:n ja muiden Saxon-moottorin versioiden takana. Hän sanoi: "Jos joku selaintoimittaja olisi kiinnostunut ottamaan SaxonJS:n lähtökohtana nykyaikaisten XML-tekniikoiden integroimiseksi selaimeen, keskustelemme mielellämme siitä heidän kanssaan." - Norm Tovey-Walsh
Mutta lisätty myös: "Olisin hyvin yllättynyt, jos joku ajattelisi, että SaxonJS:n ottaminen nykyisessä muodossaan ja sen pudottaminen selaimeen muuttumattomana olisi ihanteellinen lähestymistapa. Selaintoimittaja, koska se rakentaa selaimen, voisi lähestyä integraatiota paljon syvemmällä tasolla kuin voimme "ulkopuolelta"." - Norm Tovey-Walsh
On syytä huomata, että Tovey-Walshin kommentit tulivat noin viikkoa ennen XSLT-poistoilmoitusta. Johtopäätös Voisin jatkaa ja jatkaa. Mutta toivon, että tämä on osoittanut XPathin tehon ja antanut sinulle paljon esimerkkejä, jotka osoittavat kuinka käyttää sitä suurten asioiden saavuttamiseen. Se on täydellinen esimerkki vanhemmasta selainpinon tekniikasta, jolla on edelleen paljon hyödyllistä käyttöä, vaikka et olisi koskaan tiennyt sen olemassaolosta tai koskaan harkinnut sitä tavoittavasi. Lue lisää
Maroun Ayli, Youssef Bakouny, Nader Jalloul ja Rima Kilany "Automaattisten verkkotestien kestävyyden parantaminen luonnollisella kielellä" (ACM Digital Library)Tässä artikkelissa on monia XPath-esimerkkejä kimmoisten testien kirjoittamiseen. XPath (MDN)Tämä on erinomainen paikka aloittaa, jos haluat teknisen selityksen XPathin toiminnasta. XPath Tutorial (ZVON) Olen huomannut, että tämä opetusohjelma on hyödyllisin omassa oppimisessani lukuisten esimerkkien ja selkeiden selitysten ansiosta. XPatherTämän interaktiivisen työkalun avulla voit työskennellä suoraan koodin kanssa.
