Esmu pietiekami ilgi nodarbojies ar priekšgala izstrādi, lai redzētu tendenci gadu gaitā: jaunāki izstrādātāji strādā ar jaunu programmēšanas paradigmu, neizprotot tās vēsturisko kontekstu. Protams, ir pilnīgi saprotami kaut ko nezināt. Tīmeklis ir ļoti liela vieta ar daudzveidīgām prasmēm un specialitātēm, un mēs ne vienmēr zinām, ko nezinām. Mācīšanās šajā jomā ir nepārtraukts ceļojums, nevis kaut kas tāds, kas notiek vienreiz un beidzas. Piemērs: kāds no manas komandas jautāja, vai ir iespējams noteikt, vai lietotāji pārvietojas prom no konkrētas lietotāja saskarnes cilnes. Es norādīju uz JavaScript pirms unload notikumu. Taču tie, kuri jau ir to risinājuši, zina, ka tas ir iespējams, jo viņi ir saņēmuši brīdinājumus par nesaglabātiem datiem citās vietnēs, kurām pirms izkraušanas ir tipisks lietošanas gadījums. Es arī savam kolēģim norādīju uz lapu Slēpt un redzamībaChange notikumus. Kā es par to uzzināju? Tāpēc, ka tas parādījās citā projektā, nevis tāpēc, ka es to pētīju, sākotnēji mācoties JavaScript. Fakts ir tāds, ka mūsdienu priekšgala ietvari stāv uz to tehnoloģiju gigantu pleciem, kas bija pirms tiem. Tie abstrahē izstrādes praksi, bieži vien labākai izstrādātāju pieredzei, kas samazina vai pat novērš nepieciešamību zināt vai pieskarties tiem, kas tradicionāli ir bijuši būtiski priekšgala jēdzieni, kas, iespējams, būtu jāzina ikvienam. Apsveriet CSS objektu modeli (CSSOM). Jūs varētu sagaidīt, ka ikvienam, kas strādā ar CSS un JavaScript, ir daudz praktiskas CSSOM pieredzes, taču tas ne vienmēr tā būs. Bija React projekts e-komercijas vietnei, pie kuras es strādāju, kur mums bija jāielādē stila lapa pašreiz atlasītajam maksājumu pakalpojumu sniedzējam. Problēma bija tāda, ka stila lapa tika ielādēta katrā lapā, kad tā patiešām bija nepieciešama tikai noteiktā lapā. Izstrādātājs, kura uzdevums bija to īstenot, nekad nebija dinamiski ielādējis stila lapu. Atkal, tas ir pilnīgi saprotams, kad React atceļ tradicionālo pieeju, pēc kuras, iespējams, esat sasniedzis. CSSOM, visticamāk, nav tas, kas jums nepieciešams ikdienas darbā. Bet, visticamāk, jums kādreiz ar to būs jāsazinās, pat vienreizējā gadījumā. Šī pieredze mani iedvesmoja uzrakstīt šo rakstu. Savvaļā ir pieejamas daudzas tīmekļa funkcijas un tehnoloģijas, kurām jūs, iespējams, nekad nepieskarsities tieši savā ikdienas darbā. Iespējams, jūs esat diezgan iesācējs tīmekļa izstrādē un vienkārši par tiem nezināt, jo esat pārņemts noteikta ietvara abstrakcijā, kas neprasa jums to dziļi vai pat vispār zināt. Es runāju tieši par XML, kas, kā daudzi no mums zina, ir sena valoda, kas pilnībā neatšķiras no HTML. Es to aktualizēju neseno WHATWG diskusiju dēļ, kas liecina, ka no pārlūkprogrammām vajadzētu noņemt ievērojamu daļu XML steka, kas pazīstama kā XSLT programmēšana. Šī ir tieši tāda veca, esoša tehnoloģija, kas mums ir bijusi gadiem ilgi un ko varētu izmantot tik praktiskām lietām kā CSSOM situācija, kurā atradās mana komanda. Vai esat iepriekš strādājis ar XSLT? Paskatīsimies, vai mēs ļoti atbalstām šo veco tehnoloģiju un izmantojam tās funkcijas ārpus XML konteksta, lai šodien risinātu reālās pasaules problēmas. XPath: Centrālā API Vissvarīgākā XML tehnoloģija, kas, iespējams, ir visnoderīgākā ārpus tiešas XML perspektīvas, ir XPath — vaicājumu valoda, kas ļauj atrast jebkuru mezglu vai atribūtu iezīmēšanas kokā ar vienu saknes elementu. Man ir personīga pieķeršanās XSLT, taču tas ir atkarīgs arī no XPath, un personiskā pieķeršanās ir jānoliek malā, novērtējot svarīgumu. Argumentā par XSLT noņemšanu nav minēts XPath, tāpēc es domāju, ka tas joprojām ir atļauts. Tas ir labi, jo XPath ir centrālais un vissvarīgākais API šajā tehnoloģiju komplektā, it īpaši, mēģinot atrast kaut ko lietojamu ārpus parastā XML lietojuma. Tas ir svarīgi, jo, lai gan CSS atlasītājus var izmantot, lai atrastu lielāko daļu jūsu lapas elementu, tie nevar atrast tos visus. Turklāt CSS atlasītājus nevar izmantot, lai atrastu elementu, pamatojoties uz tā pašreizējo atrašanās vietu DOM. XPath var. Tagad daži no jums, kas lasa šo, varētu zināt XPath, un daži, iespējams, ne. XPath ir diezgan liela tehnoloģiju joma, un es nevaru iemācīt visus pamatus un arī parādīt lieliskas lietas, ko ar to darīt vienā rakstā, piemēram, šis. Es tiešām mēģināju rakstīt šo rakstu, taču Smashing Magazine vidējā publikācija nepārsniedz 5000 vārdu. Es jau biju pie vairāk nekā2000 vārdu, kamēr ir tikai puse no pamatiem. Tātad, es sākšu darīt foršas lietas ar XPath un sniegšu dažas saites, kuras varat izmantot pamatinformācijai, ja šī informācija jums šķiet interesanta. XPath un CSS apvienošana XPath var veikt daudzas lietas, ko CSS atlasītāji nevar, veicot vaicājumu elementiem. Taču CSS atlasītāji var arī veikt dažas darbības, ko XPath nevar, proti, vaicāt elementus pēc klases nosaukuma.
CSS XPath .myClass /*[satur(@class, "myClass")]
Šajā piemērā CSS vaicā elementus, kas satur .myClass klases nosaukumu. Tikmēr XPath piemērā tiek vaicāti elementi, kas satur atribūtu klasi ar virkni “myClass”. Citiem vārdiem sakot, tā atlasa elementus ar myClass jebkurā atribūtā, tostarp elementus ar .myClass klases nosaukumu, kā arī elementus ar “myClass” virknē, piemēram, .myClass2. XPath šajā ziņā ir plašāks. Tātad, nē. Es neiesaku, ka mums vajadzētu izmest CSS un sākt atlasīt visus elementus, izmantojot XPath. Tas nav galvenais. Lieta ir tāda, ka XPath var darīt lietas, kuras CSS nevar un joprojām varētu būt ļoti noderīgas, lai gan tā ir vecāka pārlūkprogrammas steka tehnoloģija un no pirmā acu uzmetiena var nešķist acīmredzama. Izmantosim abas tehnoloģijas kopā ne tikai tāpēc, ka varam, bet arī tāpēc, ka šajā procesā mēs kaut ko uzzināsim par XPath, padarot to par vēl vienu rīku jūsu kaudzē — tāds, par kuru jūs, iespējams, nezinājāt, ir bijis tur visu laiku! Problēma ir tā, ka JavaScript metode document.evaluate un dažādas vaicājumu atlases metodes, ko izmantojam JavaScript CSS API, nav saderīgas. Esmu izveidojis saderīgu vaicājumu API, lai mēs varētu sākt darbu, lai gan, jāatzīst, es par to neesmu īpaši domājis, jo tā ir novirze no tā, ko mēs šeit darām. Šeit ir diezgan vienkāršs darbības piemērs atkārtoti lietojamam vaicājumu konstruktoram: Skatiet Braiena Rasmusena pildspalvas vaicājumuXPath [forked]. Esmu pievienojis dokumenta objektam divas metodes: queryCSSSelectors (kas būtībā ir querySelectorAll) un queryXPaths. Abi šie atgriež queryResults objektu:
{ vaicājuma veids: mezgli | stīga | numurs | Būla, rezultāti: jebkuri[] // html elementi, xml elementi, virknes, skaitļi, Būla vērtības, queryCSSSelectors: (vaicājums: virkne, labot: Būla) => queryResults, queryXpaths: (vaicājums: virkne, labot: Būla) => queryResults }
Funkcijas queryCSSSelectors un queryXpaths izpilda vaicājumu, ko tām sniedzat pār elementiem rezultātu masīvā, ja vien rezultātu masīvam, protams, ir tipa mezgli. Pretējā gadījumā tas atgriezīs queryResult ar tukšu masīvu un mezglu veidu. Ja rekvizīts amend ir iestatīts uz True, funkcijas mainīs savus vaicājumuResults. Nekādā gadījumā to nedrīkst izmantot ražošanas vidē. Es to daru tikai tāpēc, lai parādītu dažādus efektus, ko rada abu vaicājumu API izmantošana kopā. Vaicājumu piemēri Es vēlos parādīt dažus dažādu XPath vaicājumu piemērus, kas parāda dažas efektīvas lietas, ko tie var darīt un kā tos var izmantot citu pieeju vietā. Pirmais piemērs ir //li/text(). Tas vaicā visus li elementus un atgriež to teksta mezglus. Tātad, ja mēs vaicātu šādu HTML:
- viens
- divi
- trīs
... tas ir tas, kas tiek atgriezts:
{"queryType":"xpathEvaluate","results":["one","two","trīs"],"resultType":"string"}
Citiem vārdiem sakot, mēs iegūstam šādu masīvu: ["viens", "divi", "trīs"]. Parasti, lai to iegūtu, jums ir jāvaicā li elementi, vaicājuma rezultāts jāpārvērš masīvā, jākartē masīvs un jāatgriež katra elementa teksta mezgls. Bet mēs to varam izdarīt kodolīgāk ar XPath: document.queryXPaths("//li/text()").rezultti.
Ņemiet vērā, ka veids, kā iegūt teksta mezglu, ir izmantot tekstu (), kas izskatās kā funkcijas paraksts, un tas tā arī ir. Tas atgriež elementa teksta mezglu. Mūsu piemērā iezīmējumā ir trīs li elementi, no kuriem katrs satur tekstu ("viens", "divi" un "trīs").
Apskatīsim vēl vienu teksta() vaicājuma piemēru. Pieņemsim, ka tas ir mūsu marķējums:
Uzrakstīsim vaicājumu, kas atgriež atribūta href vērtību: document.queryXPaths("//a[text() = 'Pierakstīties']/@href").results.
Šis ir XPath vaicājums pašreizējā dokumentā, tāpat kā iepriekšējā piemērā, taču šoreiz mēs atgriežam saites (elementa) atribūtu href, kas satur tekstu “Pierakstīties”. Faktiskais atgriezāsrezultāts ir ["/login.html"]. XPath funkciju pārskats Ir vairākas XPath funkcijas, un jūs, iespējams, tās neesat pazīstams. Manuprāt, ir vērts zināt vairākas lietas, tostarp šādas:
starts-withJa teksts sākas ar konkrētu citu teksta piemēru, starts-ar(@href, 'http:') atgriež patieso vērtību, ja href atribūts sākas ar http:. includeJa tekstā ir ietverts konkrēts cita teksta piemērs, satur(text(), "Smashing Magazine") atgriež patiesu vērtību, ja teksta mezglā jebkur ir ietverti vārdi "Smashing Magazine". countAtgriež vaicājuma atbilstības skaitu. Piemēram, count(//*[sākas-ar(@href, 'http:']) atgriež skaitu, cik saitēm konteksta mezglā ir elementi ar href atribūtu, kas satur tekstu, kas sākas ar http:. apakšvirkneDarbojas kā JavaScript apakšvirkne, izņemot to, ka jūs nododat virkni kā argumentu. Piemēram, apakšvirkne ("mans teksts", 2, 4) atgriež "y t". substring-beforeAtgriež virknes daļu pirms citas virknes. Piemēram, substing-before("mans teksts", " ") atgriež "mans". Tāpat apakšvirkne-before("hi","bye") atgriež tukšu virkni. substring-afterAtgriež virknes daļu pēc citas virknes. Piemēram, substing-after("mans teksts", " ") atgriež "tekstu". Līdzīgi, substring-after("hi","bye") atgriež tukšu virkni. normalize-space Atgriež argumentu virkni ar atstarpi, kas normalizēta, noņemot sākuma un beigu atstarpes un aizstājot atstarpes rakstzīmju secības ar vienu atstarpi. notAtgriež Būla vērtību true, ja arguments ir nepatiess, pretējā gadījumā atgriež false. trueAtgriež Būla vērtību true. falseAtgriež Būla vērtību false. concatTas pats, kas JavaScript concat, izņemot to, ka jūs to nepalaižat kā metodi virknē. Tā vietā jūs ievietojat visas virknes, kuras vēlaties savienot. string-lengthTas nav tas pats, kas JavaScript virknes garums, bet drīzāk atgriež virknes garumu, kas ir norādīts kā arguments. translateThis izmanto virkni un maina otro argumentu pret trešo argumentu. Piemēram, translate("abcdef", "abc", "XYZ") izvada XYZdef.
Papildus šīm konkrētajām XPath funkcijām ir arī vairākas citas funkcijas, kas darbojas tāpat kā to JavaScript līdzinieki — vai līdzinieki būtībā jebkurā programmēšanas valodā —, kas, iespējams, arī jums noderēs, piemēram, grīdas, griesti, apaļas, summas un tā tālāk. Šajā demonstrācijā ir parādīta katra no šīm funkcijām: Skatiet Braiena Rasmusena Pen XPath skaitliskās funkcijas [forked]. Ņemiet vērā, ka, tāpat kā lielākā daļa virkņu manipulācijas funkciju, daudzas no skaitliskām funkcijām izmanto vienu ievadi. Tas, protams, ir tāpēc, ka tie ir jāizmanto vaicāšanai, kā tas ir pēdējā XPath piemērā: //li[floor(text()) > 250]/@val
Ja tos izmantosit, kā to dara vairums piemēru, tas tiks palaists pirmajā mezglā, kas atbilst ceļam. Ir arī dažas tipa konvertēšanas funkcijas, no kurām jums, iespējams, vajadzētu izvairīties, jo JavaScript jau ir savas tipa konvertēšanas problēmas. Taču var būt gadījumi, kad vēlaties pārvērst virkni par skaitli, lai to salīdzinātu ar kādu citu skaitli. Funkcijas, kas nosaka kaut kā veidu, ir Būla vērtība, skaitlis, virkne un mezgls. Šie ir svarīgi XPath datu tipi. Un, kā jūs varētu iedomāties, lielāko daļu šo funkciju var izmantot datu tipos, kas nav DOM mezgli. Piemēram, apakšvirkne-after izmanto virkni, kā mēs jau esam izklāstījuši, bet tā var būt virkne no atribūta href. Tā var būt arī tikai virkne:
const testSubstringAfter = document.queryXPaths("substring-after('sveiki pasaule',' ')");
Acīmredzot šis piemērs mums atgriezīs rezultātu masīvu kā ["pasaule"]. Lai to parādītu darbībā, esmu izveidojis demonstrācijas lapu, izmantojot funkcijas pret lietām, kas nav DOM mezgli: Skatiet Braiena Rasmusena pildspalvas vaicājumuXPath [forked]. Jāņem vērā tulkošanas funkcijas pārsteidzošais aspekts, proti, ja jums ir rakstzīme otrajā argumentā (t.i., to rakstzīmju sarakstā, kuras vēlaties tulkot) un nav atbilstošas rakstzīmes, uz kurām tulkot, šī rakstzīme tiek noņemta no izvades. Tādējādi šis:
translate('Sveiki, mani sauc Inigo Montoija, tu nogalināji manu tēvu, sagatavojies mirt','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…rezultāti virknē, ieskaitot atstarpes: [" * * ** "]
Tas nozīmē, ka burts “a” tiek tulkots kā zvaigznīte (*), bet visas pārējās rakstzīmes, kurām nav tulkojuma, ņemot vērā mērķa virkni, tiek pilnībā noņemtas. Baltais laukums ir viss, kas mums palicisstarp tulkotajām “a” rakstzīmēm. Tad atkal šis vaicājums:
translate ('Sveiki, mani sauc Inigo Montoija, tu nogalināji manu tēvu, sagatavojies mirt','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','********************************************************'))
… nav problēmu, un tiek parādīts šāds rezultāts:
"****** *** **** ** ***** ******* *** ****** ** ****** ******* *** ***"
Jūs varētu pārsteigt, ka JavaScript nav vienkārša veida, kā veikt tieši to, ko dara XPath tulkošanas funkcija, lai gan daudzos lietošanas gadījumos to var aizstāt ar regulārām izteiksmēm. Jūs varētu izmantot to pašu pieeju, ko es demonstrēju, taču tas nav optimāli, ja viss, ko vēlaties, ir tulkot virknes. Šajā demonstrācijā ir ietverta XPath tulkošanas funkcija, lai nodrošinātu JavaScript versiju: Skatiet Braiena Rasmusena funkciju Pen translate [forked]. Kur jūs varētu izmantot kaut ko līdzīgu? Apsveriet Cēzara šifrēšanas šifrēšanu ar trīs vietu nobīdi (piemēram, augstākā līmeņa šifrēšana no 48. gada p.m.ē.):
translate("Cēzars plāno šķērsot Rubikonu!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Ievades teksts "Cēzars plāno šķērsot Rubikonu!" rezultāti “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Lai sniegtu vēl vienu īsu dažādu iespēju piemēru, es izveidoju metāla funkciju, kas izmanto virknes ievadi un izmanto tulkošanas funkciju, lai atgrieztu tekstu, ieskaitot visas rakstzīmes, kurās ir umlauts. Skatiet Braiena Rasmusena pildspalvas metāla funkciju [forked].
const metāls = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
Un, ja tiek dots teksts “Motley Crue rule, rock on dudes!”, atgriež “Mötley Crüe rüles, röck ön düdes!” Acīmredzot šo funkciju var izmantot visa veida parodiski. Ja tas esat jūs, šim TVTropes rakstam vajadzētu sniegt jums daudz iedvesmas. CSS izmantošana ar XPath Atcerieties mūsu galveno iemeslu CSS atlasītāju izmantošanai kopā ar XPath: CSS gandrīz saprot, kas ir klase, savukārt labākais, ko varat darīt ar XPath, ir klases atribūta virkņu salīdzināšana. Tas darbosies vairumā gadījumu. Bet, ja jūs kādreiz nonāktu situācijā, kad, teiksim, kāds izveidoja klases ar nosaukumu .primaryLinks un .primaryLinks2, un jūs izmantotu XPath, lai iegūtu klasi .primaryLinks, visticamāk, radīsies problēmas. Kamēr nav nekā tāda muļķīga, jūs, iespējams, izmantotu XPath. Bet man ir skumji ziņot, ka esmu strādājis vietās, kur cilvēki dara šāda veida muļķīgas lietas. Šeit ir vēl viena demonstrācija, izmantojot CSS un XPath kopā. Tas parāda, kas notiek, ja mēs izmantojam kodu, lai palaistu XPath konteksta mezglā, kas nav dokumenta mezgls. Skatiet pildspalvas css un xpath kopā [forked], ko izveidojis Braiens Rasmusens. CSS vaicājums ir .relatedarticles a, kas ienes divus a elementus sadaļā div, kam piešķirta .relatedarticles klase. Pēc tam ir trīs “slikti” vaicājumi, proti, vaicājumi, kas nedara to, ko mēs vēlamies, lai tie darītu, ja tiek izpildīti šie elementi kā konteksta mezgls. Es varu izskaidrot, kāpēc viņi uzvedas savādāk, nekā jūs varētu gaidīt. Trīs minētie sliktie vaicājumi ir:
//text(): atgriež visu dokumentā esošo tekstu. //a/text(): atgriež visu tekstu dokumentā esošajās saitēs. ./a/text(): neatgriež rezultātus.
Šo rezultātu iemesls ir tāds, ka, lai gan jūsu konteksts ir elementi, kas atgriezti no CSS vaicājuma, // ir pretrunā visam dokumentam. Tas ir XPath spēks; CSS nevar pāriet no mezgla uz priekšteci un pēc tam uz šī priekšteča brāli un māsu un nonākt līdz šī brāļa un māsas pēcnācējam. Bet XPath var. Tikmēr ./ vaicā pašreizējā mezgla atvasinājumus, kur punkts (.) apzīmē pašreizējo mezglu, bet slīpsvītra (/) apzīmē došanos uz kādu bērnmezglu — to, vai tas ir atribūts, elements vai teksts, nosaka nākamā ceļa daļa. Bet CSS vaicājumā nav atlasīts pakārtots elements, tāpēc arī šis vaicājums neko neatgriež. Pēdējā demonstrācijā ir trīs labi vaicājumi:
.//text(), ./text(), normalizēt-space(./text()).
Normalize-space vaicājums parāda XPath funkcijas izmantošanu, bet arī novērš problēmu, kas iekļauta citos vaicājumos. HTML ir strukturēts šādi:
Funkciju pārbaudes automatizācija, izmantojot Selenium WebDriver
Vaicājums atgriež rindas plūsmu teksta mezgla sākumā un beigās,un normalize-space to noņem. Jebkuras XPath funkcijas izmantošana, kas atgriež kaut ko citu, nevis Būla vērtību, ar XPath ievadi attiecas uz citām funkcijām. Šajā demonstrācijā ir parādīti vairāki piemēri: Skatiet Braiena Rasmusena Pen xpath funkciju piemērus [forked]. Pirmajā piemērā ir parādīta problēma, no kuras jums vajadzētu pievērst uzmanību. Konkrēti, šāds kods:
document.queryXPaths("substring-after(//a/@href,'https://')");
…atgriež vienu virkni:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Ir jēga, vai ne? Šīs funkcijas neatgriež masīvus, bet gan atsevišķas virknes vai atsevišķus skaitļus. Palaižot funkciju jebkurā vietā ar vairākiem rezultātiem, tiek atgriezts tikai pirmais rezultāts. Otrais rezultāts parāda, ko mēs patiešām vēlamies:
document.queryCSSSelectors("a").queryXPaths("apakšvirkne-after(./@href,'https://')");
Kas atgriež divu virkņu masīvu:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath funkcijas var ligzdot tāpat kā funkcijas JavaScript. Tātad, ja mēs zinām Smashing Magazine URL struktūru, mēs varētu rīkoties šādi (ieteicams izmantot veidnes literāļus): `tulkot( apakšvirkne ( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Tas kļūst pārāk sarežģīts, jo tam ir nepieciešami komentāri, aprakstot, kā tas tiek darīts: paņemiet visu URL no atribūta href aiz www.smashingmagazine.com/, noņemiet pirmās deviņas rakstzīmes, pēc tam tulkojiet uz priekšu slīpsvītru (/) uz neko, lai atbrīvotos no beigu slīpsvītras. Iegūtais masīvs:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
Vairāk XPath lietošanas gadījumu XPath var patiešām spīdēt testēšanā. Iemeslu nav grūti saprast, jo XPath var izmantot, lai iegūtu katru DOM elementu no jebkuras DOM pozīcijas, savukārt CSS nevar. Jūs nevarat paļauties uz to, ka CSS klases būs konsekventas daudzās modernās veidošanas sistēmās, taču, izmantojot XPath, mēs varam nodrošināt precīzākas atbilstības elementa teksta saturam neatkarīgi no mainīgās DOM struktūras. Ir veikti pētījumi par metodēm, kas ļauj veikt elastīgus XPath testus. Nekas nav sliktāks par to, ka testi izzūd un neizdodas tikai tāpēc, ka CSS atlasītājs vairs nedarbojas, jo kaut kas ir pārdēvēts vai noņemts. XPath ir arī lieliski piemērots vairāku lokatoru iegūšanai. Ir vairāk nekā viens veids, kā izmantot XPath vaicājumus, lai saskaņotu elementu. Tas pats attiecas uz CSS. Taču XPath vaicājumi var mērķtiecīgāk izpētīt lietas, kas ierobežo to, kas tiek atgriezts, ļaujot jums atrast konkrētu atbilstību, kur var būt vairākas iespējamās atbilstības. Piemēram, mēs varam izmantot XPath, lai atgrieztu konkrētu h2 elementu, kas ir ietverts div daļā, kas uzreiz seko div brāļa un māsas elementam, kas savukārt satur bērna attēla elementu ar atribūtu data-testID="leader":
nesaņemiet šo virsrakstu
Nesaņemiet arī šo virsrakstu
Līdera attēla galvene
Šis ir vaicājums: document.queryXPaths(` //div[ sekojošais brālis::div[1] /img[@data-testID='līderis'] ] /h2/ teksts () `);
Ieskatīsimies demonstrācijā, lai redzētu, kā tas viss apvienojas: Skatiet Braiena Rasmusena pildspalvu kompleksa H2 vaicājumu [forked]. Tātad, jā. Ir daudz iespējamo ceļu uz jebkuru elementu testā, izmantojot XPath. XSLT 1.0 novecošana Jau iepriekš minēju, ka Chrome komanda plāno noņemt XSLT 1.0 atbalstu no pārlūkprogrammas. Tas ir svarīgi, jo XSLT 1.0 dokumentu pārveidošanai izmanto uz XML orientētu programmēšanu, kas savukārt balstās uz XPath 1.0, kas ir atrodams lielākajā daļā pārlūkprogrammu. Kad tas notiks, mēs zaudēsim galveno XPath komponentu. Bet, ņemot vērā faktu, ka XPath patiešām ir lieliski piemērots testu rakstīšanai, man šķiet maz ticams, ka XPath kopumā drīzumā pazudīs. Tomēr esmu pamanījis, ka cilvēki sāk interesēties par funkciju, kad tā tiek atņemta. Un tas noteikti ir taisnība, ja XSLT 1.0 tiek novecojis. Vietnē Hacker News notiek visa diskusija, kas ir pilna ar argumentiem pret novecošanu. Pati ziņa ir lielisks piemērs emuāru veidošanas ietvara izveidei ar XSLT. Tuvarat izlasīt diskusiju pats, bet tas attiecas uz to, kā JavaScript var izmantot kā XLST, lai risinātu šādus gadījumus. Esmu arī redzējis ieteikumus, ka pārlūkprogrammām vajadzētu izmantot SaxonJS, kas ir ports uz JavaScript Saxon XSLT, XQUERY un XPath dzinējiem. Tā ir interesanta ideja, jo īpaši tāpēc, ka Saxon-JS ievieš šo specifikāciju pašreizējo versiju, turpretim nav nevienas pārlūkprogrammas, kas ievieš XPath vai XSLT versiju, kas pārsniedz 1.0, un neviena, kas ievieš XQuery. Es sazinājos ar Norm Tovey-Walsh no Saxonica, uzņēmuma SaxonJS un citām Saxon dzinēja versijām. Viņš teica: "Ja kāds pārlūkprogrammu pārdevējs būtu ieinteresēts izmantot SaxonJS kā sākumpunktu mūsdienu XML tehnoloģiju integrēšanai pārlūkprogrammā, mēs ar prieku apspriestu to ar viņu." - Norm Tovey-Walsh
Bet arī piebilda: "Es būtu ļoti pārsteigts, ja kāds domātu, ka SaxonJS izmantošana tās pašreizējā formā un tā iekļaušana pārlūkprogrammas versijā nemainītā veidā būtu ideāla pieeja. Pārlūkprogrammas pārdevējs, ņemot vērā to, ka viņi veido pārlūkprogrammu, varētu pievērsties integrācijai daudz dziļākā līmenī, nekā mēs varam "no ārpuses"." - Norm Tovey-Walsh
Ir vērts atzīmēt, ka Tovey-Walsh komentāri nāca apmēram nedēļu pirms paziņojuma par XSLT darbības pārtraukšanu. Secinājums Es varētu turpināt un turpināt. Bet es ceru, ka tas ir parādījis XPath spēku un sniedzis jums daudz piemēru, kas parāda, kā to izmantot lielu lietu sasniegšanai. Tas ir lielisks piemērs vecākai tehnoloģijai pārlūkprogrammas kaudzē, kurai joprojām ir daudz lietderību, pat ja jūs nekad neesat zinājis, ka tā pastāv vai nekad neesat domājis par to. Tālāka lasīšana
“Automatizētu tīmekļa testu noturības uzlabošana, izmantojot dabisko valodu” (ACM digitālā bibliotēka), autors Marūns Eili, Jusefs Bakūnijs, Naders Jallouls un Rima KilanyŠajā rakstā ir sniegti daudzi XPath piemēri elastīgu testu rakstīšanai. XPath (MDN)Šī ir lieliska vieta, kur sākt, ja vēlaties saņemt tehnisku skaidrojumu, kurā sīki aprakstīts XPath darbības princips. XPath apmācība (ZVON) Pateicoties daudzajiem piemēriem un skaidriem paskaidrojumiem, šī apmācība man ir visnoderīgākā. XPatherŠis interaktīvais rīks ļauj strādāt tieši ar kodu.
