Elég régóta foglalkozom front-end fejlesztéssel ahhoz, hogy észrevegyem az évek során tapasztalható trendet: a fiatalabb fejlesztők a programozás új paradigmájával dolgoznak anélkül, hogy megértenék ennek történelmi kontextusát. Természetesen teljesen érthető, ha valamit nem tudunk. A web egy nagyon nagy hely, sokrétű készségekkel és specialitásokkal, és nem mindig tudjuk, mit nem tudunk. A tanulás ezen a területen egy folyamatos utazás, nem pedig valami, ami egyszer megtörténik és véget ér. Példa: Valaki a csapatomból megkérdezte, hogy meg lehet-e állapítani, hogy a felhasználók elnavigálnak-e a felhasználói felület egy adott lapjáról. Rámutattam a JavaScript letöltés előtti eseményére. De azok, akik már foglalkoztak ezzel, tudják, hogy ez lehetséges, mert más webhelyeken kaptak figyelmeztetést a nem mentett adatokról, amelyekre a kitöltés előtti tipikus használati eset. Az oldalElrejtés és a láthatóságChange eseményeket is felhívtam kollégámra, hogy jó legyen. Honnan tudtam én erről? Mert ez egy másik projektben merült fel, nem azért, mert tanultam rajta, amikor először tanultam a JavaScriptet. A helyzet az, hogy a modern front-end keretrendszerek az őket megelőző technológiai óriások vállán állnak. Elvonják a fejlesztési gyakorlatokat, gyakran a jobb fejlesztői élmény érdekében, ami csökkenti vagy akár meg is szünteti annak szükségességét, hogy ismerjék vagy érintsék meg azokat a hagyományosan alapvető front-end fogalmakat, amelyeket valószínűleg mindenkinek tudnia kell. Tekintsük a CSS-objektummodellt (CSSOM). Arra számíthat, hogy bárki, aki CSS-ben és JavaScriptben dolgozik, rengeteg gyakorlati CSSOM-tapasztalattal rendelkezik, de ez nem mindig lesz így. Volt egy React projekt egy e-kereskedelmi webhelyhez, amelyen dolgoztam, ahol be kellett töltenünk egy stíluslapot a jelenleg kiválasztott fizetési szolgáltatóhoz. A probléma az volt, hogy a stíluslap minden oldalon betöltődött, amikor csak egy adott oldalon volt rá szükség. Az ezzel megbízott fejlesztő még soha nem töltött be dinamikusan stíluslapot. Ez ismét teljesen érthető, amikor a React elvonatkoztatja a hagyományos megközelítést, amelyhez esetleg elért. Valószínűleg a CSSOM-ra nincs szüksége a mindennapi munkában. De valószínű, hogy valamikor kapcsolatba kell lépnie vele, akár egyszeri esetben is. Ezek a tapasztalatok inspiráltak a cikk megírásához. Számos létező webes funkció és technológia létezik a természetben, amelyekhez a mindennapi munkája során nem nyúlhat közvetlenül hozzá. Lehet, hogy eléggé kezdő vagy a webfejlesztésben, és egyszerűen nincs tisztában velük, mert elmerül egy adott keretrendszer absztrakciójában, amelyhez nem szükséges mélyen vagy egyáltalán nem ismerni. Kifejezetten az XML-ről beszélek, amelyről sokan tudjuk, hogy egy ősi nyelv, amely nem teljesen különbözik a HTML-től. Ezt a legutóbbi WHATWG-beszélgetések miatt hozom fel, amelyek azt sugallják, hogy az XSLT-programozásként ismert XML-verem jelentős részét el kell távolítani a böngészőkből. Ez pontosan az a fajta régebbi, létező technológia, amivel évek óta rendelkezünk, és olyan gyakorlati célokra is használható, mint a CSSOM-helyzet, amelyben a csapatom volt. Dolgoztál már XSLT-vel? Nézzük meg, hogy erősen támaszkodunk-e erre a régebbi technológiára, és kihasználjuk-e annak funkcióit az XML kontextusán kívül a való világ mai problémáinak megoldására. XPath: A központi API A legfontosabb XML-technológia, amely az egyenes XML-perspektíván kívül talán a leghasznosabb az XPath, egy lekérdezési nyelv, amely lehetővé teszi bármely csomópont vagy attribútum megtalálását a jelölőfában egyetlen gyökérelemmel. Személyes vonzalmat érzek az XSLT-hez, de ez is az XPath-ra támaszkodik, és a személyes vonzalmat félre kell tenni a fontosság rangsorolásánál. Az XSLT eltávolítása melletti érv nem tesz említést az XPath-ról, így azt hiszem, továbbra is engedélyezett. Ez jó, mert az XPath a központi és legfontosabb API ebben a technológiai csomagban, különösen akkor, ha a normál XML-használaton kívül próbálunk valami használhatót találni. Ez azért fontos, mert bár a CSS-szelektorok segítségével meg lehet találni az oldal legtöbb elemét, nem találják meg az összeset. Ezenkívül a CSS-szelektorok nem használhatók egy elem megkeresésére a DOM-ban lévő aktuális pozíciója alapján. Az XPath képes. Nos, néhányan, akik ezt olvassák, ismerik az XPath-ot, mások pedig nem. Az XPath a technológia meglehetősen nagy területe, és nem igazán tudom megtanítani az összes alapokat, és egyetlen ilyen cikkben sem mutathatok meg remek dolgokat vele. Valójában megpróbáltam megírni azt a cikket, de a Smashing Magazine átlagos kiadványa nem haladja meg az 5000 szót. Már többnél jártam2000 szó, miközben csak az alapok felénél. Szóval, elkezdek nagyszerű dolgokat csinálni az XPath-tal, és adok néhány linket, amelyeket felhasználhatsz az alapokhoz, ha érdekesnek találod ezeket a dolgokat. XPath és CSS kombinálása Az XPath sok olyan dologra képes, amit a CSS-szelektorok nem tudnak az elemek lekérdezésekor. De a CSS-szelektorok is megtehetnek néhány olyan dolgot, amit az XPath nem tud, nevezetesen az elemek osztálynév alapján történő lekérdezésére.
CSS XPath .myClass /*[contains(@class, "myClass")]
Ebben a példában a CSS olyan elemeket kérdez le, amelyek .myClass osztálynevet tartalmaznak. Eközben az XPath példa olyan elemeket kérdez le, amelyek egy attribútumosztályt tartalmaznak a „myClass” karakterlánccal. Más szavakkal, bármely attribútumban kiválasztja a myClass elemet, beleértve a .myClass osztálynévvel rendelkező elemeket, valamint a „myClass” karakterláncot tartalmazó elemeket, mint például a .myClass2. Az XPath ebben az értelemben szélesebb. Szóval nem. Nem azt javaslom, hogy dobjuk ki a CSS-t, és kezdjük el az összes elem kiválasztását XPath segítségével. Nem ez a lényeg. A lényeg az, hogy az XPath olyan dolgokat tud megtenni, amelyeket a CSS nem tud és még mindig nagyon hasznos lehet, bár ez egy régebbi technológia a böngészőveremben, és első pillantásra nem tűnik nyilvánvalónak. Használjuk együtt a két technológiát, nem csak azért, mert megtehetjük, hanem azért is, mert közben megtudunk valamit az XPath-ról, és ez egy újabb eszköz lesz a veremben – amelyről talán nem is tudtad, hogy mindvégig ott volt! A probléma az, hogy a JavaScript document.evaluate metódusa és a különböző lekérdezésválasztó módszerek, amelyeket a JavaScript CSS API-jaival használunk, nem kompatibilisek. Létrehoztam egy kompatibilis lekérdező API-t a kezdéshez, bár bevallom, nem nagyon gondolkodtam rajta, mivel ez eltér attól, amit itt csinálunk. Íme egy meglehetősen egyszerű működő példa egy újrafelhasználható lekérdezés konstruktorra: Tekintse meg a Pen queryXPath [forked]-et Bryan Rasmussentől. Két módszert adtam hozzá a dokumentumobjektumhoz: a queryCSSSelectors (amely lényegében querySelectorAll) és a queryXPaths. Mindkettő egy queryResults objektumot ad vissza:
{ queryType: csomópontok | húr | szám | logikai, eredmények: any[] // html elemek, xml elemek, karakterláncok, számok, logikai értékek, queryCSSSelectors: (query: string, amend: Boolean) => queryResults, queryXpaths: (query: string, amend: Boolean) => queryResults }
A queryCSSSelectors és a queryXpaths függvények a nekik adott lekérdezést futtatják az eredménytömb elemei felett, természetesen mindaddig, amíg az eredménytömb csomópont típusú. Ellenkező esetben a queryResult egy üres tömböt és egy típusú csomópontot ad vissza. Ha az amen tulajdonság igaz értékre van állítva, a függvények megváltoztatják saját queryResults-jukat. Ezt semmilyen körülmények között nem szabad termelési környezetben használni. Ezt pusztán azért teszem, hogy bemutassam a két lekérdezési API együttes használatának különböző hatásait. Példa lekérdezések Szeretnék néhány példát mutatni a különböző XPath-lekérdezésekre, amelyek bemutatják, hogy milyen hatékony dolgokat tudnak tenni, és hogyan használhatók más megközelítések helyett. Az első példa a //li/text(). Ez lekérdezi az összes li elemet, és visszaadja a szöveges csomópontjaikat. Tehát, ha a következő HTML-t kérdeznénk le:
- egy
- kettő
- három
…ezt adják vissza:
{"queryType":"xpathEvaluate","results":["one","two","three"],"resultType":"string"}
Más szavakkal, a következő tömböt kapjuk: ["egy", "kettő", "három"]. Általában le kell kérdezni az li elemeket, hogy megkapja ezt, a lekérdezés eredményét tömbbé alakítja, leképezi a tömböt, és visszaadja az egyes elemek szöveges csomópontját. De ezt tömörebben megtehetjük az XPath segítségével: document.queryXPaths("//li/text()").eredmények.
Figyeljük meg, hogy a szövegcsomópont létrehozásának módja a text() használata, amely függvényaláírásnak tűnik – és az is. Egy elem szöveges csomópontját adja vissza. Példánkban három li elem található a jelölésben, amelyek mindegyike szöveget tartalmaz ("egy", "kettő" és "három").
Nézzünk még egy példát a text() lekérdezésre. Tegyük fel, hogy ez a mi jelölésünk:
Írjunk egy lekérdezést, amely a href attribútum értékét adja vissza: document.queryXPaths("//a[text() = 'Bejelentkezés']/@href").eredmények.
Ez egy XPath-lekérdezés az aktuális dokumentumon, csakúgy, mint az előző példa, de ezúttal egy hivatkozás (egy elem) href attribútumait adjuk vissza, amely a „Sign In” szöveget tartalmazza. A tényleges visszatértaz eredmény: ["/login.html"]. XPath függvények áttekintése Számos XPath-függvény létezik, és valószínűleg nem ismeri őket. Azt hiszem, többről is érdemes tudni, többek között a következőkről:
starts-withHa egy szöveg egy adott szöveges példával kezdődik, a starts-with(@href, 'http:') értéke igaz, ha egy href attribútum http:-vel kezdődik. includeHa egy szöveg tartalmaz egy konkrét szöveges példát, a include(text(), "Smashing Magazine") igazat ad vissza, ha egy szövegcsomópont bárhol tartalmazza a "Smashing Magazine" szavakat. count Visszaadja, hogy hány egyezés van egy lekérdezésben. Például a count(//*[starts-with(@href, 'http:']) azt a számot adja vissza, hogy a kontextus csomópontban hány hivatkozás tartalmaz egy href attribútumot tartalmazó elemet, amely a http:-vel kezdődő szöveget tartalmazza. substring Úgy működik, mint a JavaScript részkarakterlánc, kivéve, hogy a karakterláncot argumentumként adja át. Például a substring("saját szövegem", 2, 4) az "y t" értéket adja vissza. substring-before Egy karakterlánc egy másik karakterlánc előtti részét adja vissza. Például a substing-befor("saját szövegem", " ") a "my" értéket adja vissza. Hasonlóképpen, a substring-before("hi","bye") üres karakterláncot ad vissza. substring-after Egy karakterlánc egy másik karakterlánc utáni részét adja vissza. Például a substing-after("saját szövegem", " ") a "szöveg" értéket adja vissza. Hasonlóképpen, a substring-after("hi","bye") üres karakterláncot ad vissza. normalize-space Visszaadja az argumentum karakterláncot szóközzel, amely normalizálódik a kezdő és a záró szóközök eltávolításával, valamint a szóköz karakterek sorozatának egyetlen szóközzel való helyettesítésével. not A logikai értéke igaz, ha az argumentum hamis, egyébként hamis. true Logikai igazat ad vissza. false Boolean hamis értéket ad vissza. concatUgyanaz, mint a JavaScript concat, csak nem metódusként futtatod egy karakterláncon. Ehelyett be kell írni az összes összefűzni kívánt karakterláncot. string-lengthEz nem ugyanaz, mint a JavaScript string-length, hanem az argumentumként megadott karakterlánc hosszát adja vissza. A translateThis egy karakterláncot vesz fel, és a második argumentumot a harmadik argumentummá változtatja. Például a translate("abcdef", "abc", "XYZ") XYZdef kimenetet ad.
Ezeken a konkrét XPath-függvényeken kívül számos más funkció is ugyanúgy működik, mint JavaScript-társaik – vagy alapvetően bármilyen programozási nyelv megfelelői –, amelyeket valószínűleg szintén hasznosnak talál, például padló, mennyezet, kör, összeg stb. A következő bemutató bemutatja az egyes funkciókat: Tekintse meg a Pen XPath Numerical függvényeket [forked] Bryan Rasmussentől. Vegye figyelembe, hogy a legtöbb karakterlánc-manipulációs függvényhez hasonlóan sok numerikus függvény is egyetlen bemenetet vesz igénybe. Ez természetesen azért van, mert állítólag lekérdezésre használják őket, mint az utolsó XPath példában: //li[floor(text()) > 250]/@val
Ha használja őket, ahogy a legtöbb példa teszi, akkor végül az elérési útnak megfelelő első csomóponton fogja futtatni. Vannak olyan típuskonverziós függvények is, amelyeket valószínűleg kerülni kell, mert a JavaScript-nek már megvannak a saját típuskonverziós problémái. De előfordulhatnak olyan esetek, amikor egy karakterláncot számmá szeretne konvertálni, hogy összehasonlítsa egy másik számmal. A valami típusát beállító függvények a következők: logikai érték, szám, karakterlánc és csomópont. Ezek a fontos XPath adattípusok. És ahogy elképzelhető, ezeknek a függvényeknek a többsége olyan adattípusokon is használható, amelyek nem DOM-csomópontok. Például az substring-after egy karakterláncot vesz fel, ahogyan már leírtuk, de lehet egy href attribútumból származó karakterlánc is. Ez is lehet csak egy karakterlánc:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Nyilvánvaló, hogy ez a példa az eredménytömböt ["világ"] néven adja vissza. Ennek gyakorlati bemutatására készítettem egy bemutató oldalt olyan funkciókkal, amelyek nem DOM csomópontok: Tekintse meg a Pen queryXPath [forked]-et Bryan Rasmussentől. Figyelembe kell venni a fordítási függvény meglepő aspektusát, amely az, hogy ha van egy karakter a második argumentumban (vagyis a lefordítani kívánt karakterek listájában), és nincs egyező karakter, amelyre lefordítani lehetne, akkor az a karakter eltávolításra kerül a kimenetből. Tehát ez:
translate('Szia, a nevem Inigo Montoya, megölted az apámat, készülj a halálra','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…eredmények a karakterláncban, beleértve a szóközöket: [" * * ** "]
Ez azt jelenti, hogy az „a” betűt a rendszer csillaggá (*) fordítja, de minden olyan karakter, amelynek nincs fordítása a célkarakterlánchoz képest, teljesen eltávolításra kerül. Már csak a szóköz maradta lefordított „a” karakterek között. Aztán megint ez a lekérdezés:
translate('Szia, a nevem Inigo Montoya, megölted az apámat, készülj a halálra','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','********************************************************')")
…nincs probléma, és a következőképpen néz ki:
"****** *** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Megdöbbenhet, hogy a JavaScriptben nincs egyszerű módja annak, hogy pontosan azt tegye, amit az XPath fordítási függvény, bár sok esetben az All reguláris kifejezésekre cserélése képes kezelni. Használhatja ugyanazt a megközelítést, amit bemutattam, de ez szuboptimális, ha csak le kell fordítani a karakterláncokat. A következő bemutató az XPath fordítási funkcióját burkolja, hogy JavaScript-verziót biztosítson: Lásd Bryan Rasmussen tollfordítási funkcióját [forked]. Hol használhatsz ilyesmit? Vegyük fontolóra a Caesar Cipher titkosítást háromhelyes eltolással (pl. a legmagasabb szintű titkosítás ie 48-ból):
translate("Caesar azt tervezi, hogy átkel a Rubiconon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
A beviteli szöveg: „Caesar azt tervezi, hogy átkel a Rubiconon!” eredmény: „Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Hogy egy másik gyors példát adjak a különböző lehetőségekre, készítettem egy fémfüggvényt, amely karakterlánc bemenetet vesz fel, és egy fordítási függvényt használ a szöveg visszaadásához, beleértve az összes karaktert, amely umlautokat vesz fel. Lásd a Pen metal funkciót [villás] Bryan Rasmussentől.
const metal = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
És ha a „Motley Crue rules, rock on dudes!” szöveget kapjuk, akkor a „Mötley Crüe rüles, röck ön düdes” szöveget adja vissza! Nyilvánvaló, hogy ennek a funkciónak mindenféle paródiás felhasználása lehet. Ha Ön az, akkor ennek a TVTropes-cikknek rengeteg ihletet kell adnia. CSS használata XPath-tal Emlékezzen a fő okunkra, amiért a CSS-szelektorokat XPath-tal együtt használjuk: a CSS nagyjából megérti, hogy mi az osztály, míg az XPath-tal a legjobb, ha az osztályattribútum karakterlánc-összehasonlítását teheti. Ez a legtöbb esetben működni fog. De ha valaha is olyan helyzetbe kerülne, hogy valaki .primaryLinks és .primaryLinks2 nevű osztályokat hozott létre, és Ön XPath segítségével szerezte be a .primaryLinks osztályt, akkor valószínűleg problémákba ütközne. Amíg nincs ilyen ostobaság, valószínűleg XPath-ot használ. De szomorúan jelentem, hogy olyan helyeken dolgoztam, ahol az emberek ilyen butaságokat csinálnak. Íme egy másik demó, amely a CSS-t és az XPath-ot együtt használja. Megmutatja, hogy mi történik, ha a kóddal XPath-ot futtatunk egy olyan környezeti csomóponton, amely nem a dokumentum csomópontja. Tekintse meg a Pen css-t és az xpath-t együtt [elágazva] Bryan Rasmussen által. A CSS-lekérdezés a .relatedarticles a, amely lekéri a .relatedarticles osztályhoz rendelt div két a elemét. Ezt követően három „rossz” lekérdezés következik, vagyis olyan lekérdezések, amelyek nem azt teszik, amit szeretnénk, ha ezekkel az elemekkel kontextus csomópontként futnak. Meg tudom magyarázni, miért viselkednek másként, mint ahogyan azt várná. A szóban forgó három rossz lekérdezés a következő:
//text(): Visszaadja a dokumentumban lévő összes szöveget. //a/text(): Visszaadja a dokumentumban található hivatkozásokon belüli összes szöveget. ./a/text(): Nem ad vissza eredményt.
Ezeknek az eredményeknek az az oka, hogy míg a kontextus a CSS-lekérdezésből visszaadott elem, a // ellentétes az egész dokumentummal. Ez az XPath erőssége; A CSS nem léphet át egy csomópontból egy ősbe, majd az ős testvérébe, és nem léphet le a testvér leszármazottjáig. De az XPath képes rá. Eközben a ./ lekérdezi az aktuális csomópont gyermekeit, ahol a pont (.) az aktuális csomópontot jelöli, a perjel (/) pedig valamilyen gyermekcsomóponthoz való eljutást – hogy attribútumról, elemről vagy szövegről van szó, azt az útvonal következő része határozza meg. A CSS-lekérdezés által kiválasztott elemnek azonban nincs gyermeke, így a lekérdezés sem ad vissza semmit. Három jó lekérdezés van az utolsó demóban:
.//text(), ./text(), normalize-space(./text()).
A normalize-space lekérdezés bemutatja az XPath függvény használatát, de kijavítja a többi lekérdezésben szereplő problémát is. A HTML a következőképpen épül fel:
Funkciótesztelés automatizálása a Selenium WebDriver segítségével
A lekérdezés soremelést ad vissza a szövegcsomópont elején és végén,és a normalize-space eltávolítja ezt. Bármilyen XPath függvény használata, amely a logikai értéktől eltérőt ad vissza XPath bemenettel, más függvényekre is vonatkozik. A következő bemutató számos példát mutat be: Lásd a Pen xpath függvények példáit [forked] Bryan Rasmussentől. Az első példa egy olyan problémát mutat be, amelyre figyelnie kell. Pontosabban a következő kód:
document.queryXPaths("substring-after(//a/@href,'https://')");
…egy karakterláncot ad vissza:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Van értelme, nem? Ezek a függvények nem tömböket adnak vissza, hanem egyedi karakterláncokat vagy egyedi számokat. Ha a függvényt bárhol több eredménnyel futtatja, akkor csak az első eredményt adja vissza. A második eredmény megmutatja, hogy mit is akarunk valójában:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Ami egy két karakterláncból álló tömböt ad vissza:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Az XPath függvények ugyanúgy beágyazhatók, mint a JavaScript függvényei. Tehát, ha ismerjük a Smashing Magazine URL-struktúráját, akkor a következőket tehetjük (a sablonliterálok használata javasolt): `fordítani( alsztring( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')''
Ez egy kicsit túl bonyolulttá válik, olyannyira, hogy megjegyzésekre van szüksége, amelyek leírják, hogy mit csinál: vegye ki az összes URL-t a www.smashingmagazine.com/ utáni href attribútumból, távolítsa el az első kilenc karaktert, majd fordítsa le a perjelet (/) semmivé, hogy megszabaduljon a végződő perjeltől. Az eredményül kapott tömb:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
További XPath használati esetek Az XPath igazán remekül tud tesztelni. Az okot nem nehéz belátni, mivel az XPath segítségével a DOM minden eleme lekérhető a DOM bármely helyéről, míg a CSS nem. Nem számíthat arra, hogy a CSS-osztályok konzisztensek maradnak sok modern összeállítási rendszerben, de az XPath segítségével robusztusabb egyezéseket tudunk létrehozni egy elem szövegtartalmára vonatkozóan, függetlenül a változó DOM-struktúrától. Kutatások folytak olyan technikákról, amelyek lehetővé teszik rugalmas XPath-tesztek készítését. Semmi sem rosszabb, mint amikor a tesztek elromlanak és meghiúsulnak, csak azért, mert a CSS-választó már nem működik, mert valamit átneveztek vagy eltávolítottak. Az XPath nagyon jó a több lokátor kivonatánál is. Egynél több módszer is létezik XPath-lekérdezések használatával egy elem egyeztetésére. Ugyanez igaz a CSS-re is. Az XPath-lekérdezések azonban célzottabb módon képesek elmélyülni a dolgokban, ami korlátozza, hogy mit kapjon vissza, és lehetővé teszi, hogy megtaláljon egy adott egyezést, ahol több lehetséges egyezés is lehet. Például az XPath segítségével visszaadhatunk egy adott h2 elemet, amely egy divben található, amely közvetlenül egy testvér div után következik, amely viszont egy data-testID="leader" attribútummal ellátott gyermek képelemet tartalmaz:
ne kapja meg ezt a címsort
Ne kapja meg ezt a címsort sem
A vezetőkép fejléce
Ez a lekérdezés: document.queryXPaths(` //div[ következő-testvér::div[1] /img[@data-testID='vezető'] ] /h2/ szöveg() `);
Nyissunk be egy bemutatót, hogy lássuk, hogyan áll össze mindez: Tekintse meg a Pen Complex H2 Query-t [elágazva] Bryan Rasmussentől. Szóval igen. Az XPath használatával végzett teszt bármely eleméhez számos lehetséges útvonal létezik. Az XSLT 1.0 elavultsága Korán említettem, hogy a Chrome csapata azt tervezi, hogy eltávolítja az XSLT 1.0 támogatását a böngészőből. Ez azért fontos, mert az XSLT 1.0 XML-központú programozást használ a dokumentumátalakításhoz, amely viszont az XPath 1.0-ra támaszkodik, amely a legtöbb böngészőben megtalálható. Amikor ez megtörténik, elveszítjük az XPath egyik kulcsfontosságú összetevőjét. De figyelembe véve azt a tényt, hogy az XPath igazán nagyszerű tesztek írásához, valószínűtlennek tartom, hogy az XPath egésze egyhamar eltűnjön. Ennek ellenére azt vettem észre, hogy az emberek akkor kezdenek érdeklődni egy funkció iránt, amikor elveszik azt. És ez minden bizonnyal igaz az XSLT 1.0 elavultsága esetén. Egy egész vita folyik a Hacker Newsnál, tele érvekkel a lejáratás ellen. Maga a bejegyzés remek példa arra, hogyan lehet XSLT-vel létrehozni egy blogolási keretrendszert. Temaga is elolvashatja a vitát, de kitér arra is, hogy a JavaScriptet miként lehet az XLST alátétként használni az ilyen esetek kezelésére. Olyan javaslatokat is láttam, hogy a böngészőknek a SaxonJS-t kell használniuk, amely a JavaScript Saxon XSLT, XQUERY és XPath motorjainak portja. Ez egy érdekes ötlet, különösen mivel a Saxon-JS ezen specifikációk jelenlegi verzióját valósítja meg, miközben nincs olyan böngésző, amely az XPath vagy XSLT bármely verzióját megvalósítaná az 1.0-n túl, és nincs olyan böngésző, amely az XQuery-t. Megkerestem Norm Tovey-Walsh-t a Saxonicánál, a SaxonJS és a Saxon motor más verziói mögött álló cégnél. Azt mondta: „Ha bármelyik böngészőgyártót érdekelné a SaxonJS kiindulópontja a modern XML-technológiák böngészőbe való integrálásához, örömmel vitatkoznánk vele.” – Norm Tovey-Walsh
De hozzátette: "Nagyon meglepődnék, ha valaki azt gondolná, hogy a SaxonJS jelenlegi formájában és változatlan formában történő bedobása a böngészőbe az ideális megoldás. Egy böngészőgyártó, abból a tényből adódóan, hogy ők építik a böngészőt, sokkal mélyebb szinten közelíthetné meg az integrációt, mint ahogy azt mi "kívülről" megtehetjük." - Norm Tovey-Walsh
Érdemes megjegyezni, hogy Tovey-Walsh megjegyzései körülbelül egy héttel az XSLT megszüntetéséről szóló bejelentés előtt érkeztek. Következtetés Még hosszan sorolhatnám. De remélem, hogy ez megmutatta az XPath erejét, és rengeteg példát mutatott be, amelyek bemutatják, hogyan használhatod nagyszerű dolgok elérésére. Tökéletes példája a régebbi technológiának a böngészőveremben, amely még ma is bőven használható, még akkor is, ha soha nem tudta, hogy létezik, vagy soha nem gondolt arra, hogy hozzányúljon. További olvasás
Maroun Ayli, Youssef Bakouny, Nader Jalloul és Rima Kilany „Az automatizált webtesztek rugalmasságának fokozása természetes nyelvvel” (ACM Digital Library) Ez a cikk számos XPath-példát kínál rugalmas tesztek írásához. XPath (MDN) Ez egy kiváló kiindulópont, ha műszaki magyarázatot szeretne kapni az XPath működéséről. XPath oktatóprogram (ZVON) Ezt az oktatóanyagot találtam a leghasznosabbnak saját tanulásom során, köszönhetően a rengeteg példának és világos magyarázatnak. XPatherEz az interaktív eszköz lehetővé teszi, hogy közvetlenül dolgozzon a kóddal.
