Ég hef verið nógu lengi í framhliðarþróun til að sjá þróun í gegnum árin: yngri forritarar vinna með nýja hugmyndafræði forritunar án þess að skilja sögulegt samhengi hennar. Það er auðvitað fullkomlega skiljanlegt að vita ekki eitthvað. Vefurinn er mjög stór staður með fjölbreyttri kunnáttu og sérgreinum og við vitum ekki alltaf hvað við vitum ekki. Nám á þessu sviði er áframhaldandi ferðalag frekar en eitthvað sem gerist einu sinni og endar. Tilfelli: Einhver í teyminu mínu spurði hvort hægt væri að sjá hvort notendur flakka í burtu frá tilteknum flipa í notendaviðmótinu. Ég benti á JavaScript's beforeunload atburði. En þeir sem hafa tekist á við þetta áður vita að þetta er mögulegt vegna þess að þeir hafa fengið viðvaranir um óvistuð gögn á öðrum síðum, sem áður en afhleðsla er dæmigerð notkunartilvik. Ég benti einnig samstarfsmanni mínum á síðuna Fela og sýnileikaBreyta atburði til góðs. Hvernig vissi ég um það? Vegna þess að það kom upp í öðru verkefni, ekki vegna þess að ég lærði á það þegar ég lærði JavaScript. Staðreyndin er sú að nútíma framhliðarumgjörðir standa á herðum tæknirisanna sem voru á undan þeim. Þetta eru óhlutbundin þróunaraðferðir, oft fyrir betri upplifun þróunaraðila sem dregur úr, eða jafnvel útilokar, þörfina á að vita eða snerta það sem hefur jafnan verið nauðsynleg framhliðarhugtök sem allir ættu líklega að þekkja. Íhugaðu CSS Object Model (CSSOM). Þú gætir búist við því að allir sem vinna í CSS og JavaScript hafi fullt af praktískri CSSOM reynslu, en það mun ekki alltaf vera raunin. Það var React verkefni fyrir netverslunarsíðu sem ég vann að þar sem við þurftum að hlaða inn stílblað fyrir þann greiðsluveitanda sem er valinn. Vandamálið var að stílblaðið var að hlaðast inn á hverja síðu þegar þess var raunverulega þörf á tiltekinni síðu. Framkvæmdaraðilinn sem fékk það verkefni að láta þetta gerast hafði aldrei hlaðið stílblaði á kraftmikinn hátt. Aftur, þetta er fullkomlega skiljanlegt þegar React fjarlægir hina hefðbundnu nálgun sem þú gætir hafa náð í. CSSOM er líklega ekki eitthvað sem þú þarft í daglegu starfi þínu. En það er líklegt að þú þurfir að hafa samskipti við það á einhverjum tímapunkti, jafnvel í einu tilviki. Þessi reynsla hvatti mig til að skrifa þessa grein. Það eru til margir vefeiginleikar og tækni í náttúrunni sem þú gætir aldrei snert beint í daglegu starfi þínu. Kannski ertu frekar nýr í vefþróun og ert einfaldlega ómeðvitaður um þá vegna þess að þú ert gegnsýrður ágripi ákveðins ramma sem krefst þess að þú þekkir það ekki djúpt, eða jafnvel yfirleitt. Ég er að tala sérstaklega um XML, sem mörg okkar vita að er fornt tungumál sem er ekki alveg ósvipað HTML. Ég er að koma með þetta vegna nýlegra WHATWG umræður sem benda til þess að verulegur hluti af XML staflanum þekktur sem XSLT forritun ætti að fjarlægja úr vöfrum. Þetta er nákvæmlega sú tegund af eldri, núverandi tækni sem við höfum haft í mörg ár sem hægt er að nota í eitthvað eins hagnýtt og CSSOM aðstæðurnar sem liðið mitt var í. Hefur þú unnið með XSLT áður? Við skulum sjá hvort við hallum okkur mikið að þessari eldri tækni og nýtum eiginleika hennar utan samhengis XML til að takast á við raunveruleg vandamál í dag. XPath: Central API Mikilvægasta XML tæknin sem er kannski sú gagnlegasta utan beins XML sjónarhorns er XPath, fyrirspurnartungumál sem gerir þér kleift að finna hvaða hnút eða eiginleika sem er í álagningartré með einum rótarhluta. Ég hef persónulega væntumþykju fyrir XSLT, en það byggir líka á XPath, og persónulega ástúð verður að leggja til hliðar í mikilvægi röðunar. Rökin fyrir því að fjarlægja XSLT minnast ekki á XPath, svo ég býst við að það sé enn leyfilegt. Það er gott vegna þess að XPath er miðlæga og mikilvægasta API í þessari tæknisvítu, sérstaklega þegar reynt er að finna eitthvað til að nota utan eðlilegrar XML-notkunar. Það er mikilvægt vegna þess að á meðan hægt er að nota CSS val til að finna flesta þætti á síðunni þinni, geta þeir ekki fundið þá alla. Ennfremur er ekki hægt að nota CSS val til að finna frumefni byggt á núverandi stöðu hans í DOM. XPath getur. Nú, sum ykkar sem lesa þetta gætu þekkt XPath, og önnur kannski ekki. XPath er ansi stórt tæknisvið og ég get í raun ekki kennt öll grunnatriðin og líka sýnt þér flotta hluti til að gera við það í einni grein eins og þessari. Ég reyndi reyndar að skrifa þessa grein, en meðalútgáfa Smashing Magazine nær ekki yfir 5.000 orð. Ég var þegar á meira en2.000 orð á meðan grunnatriðin eru aðeins hálfnuð. Svo ég ætla að byrja að gera flott efni með XPath og gefa þér nokkra tengla sem þú getur notað fyrir grunnatriðin ef þér finnst þetta áhugavert. Sameinar XPath og CSS XPath getur gert fullt af hlutum sem CSS veljarar geta ekki þegar spurt er um þætti. En CSS veljarar geta líka gert nokkra hluti sem XPath getur ekki, nefnilega spurt um þætti eftir flokksheiti.
CSS XPath .myClass /*[inniheldur(@class, "myClass")]
Í þessu dæmi gerir CSS fyrirspurnir um þætti sem innihalda .myClass bekkjarheiti. Á meðan spyr XPath dæmið um þætti sem innihalda eigindaflokk með strengnum „myClass“. Með öðrum orðum, það velur þætti með myClass í hvaða eigind sem er, þar á meðal þætti með .myClass bekkjarheitinu — sem og þætti með „myClass“ í strengnum, eins og .myClass2. XPath er víðtækara í þeim skilningi. Svo, nei. Ég er ekki að gefa til kynna að við ættum að henda CSS út og byrja að velja alla þætti í gegnum XPath. Það er ekki málið. Málið er að XPath getur gert hluti sem CSS getur ekki og gæti enn verið mjög gagnlegt, jafnvel þó að það sé eldri tækni í vafrastaflanum og virðist kannski ekki augljóst við fyrstu sýn. Við skulum nota þessar tvær tækni saman, ekki aðeins vegna þess að við getum, heldur vegna þess að við munum læra eitthvað um XPath í ferlinu, sem gerir það að öðru tóli í staflanum þínum - eitt sem þú gætir ekki vitað að hefur verið til staðar allan tímann! Vandamálið er að document.evaluate aðferð JavaScript og hinar ýmsu fyrirspurnavalsaðferðir sem við notum með CSS API fyrir JavaScript eru ósamhæfðar. Ég hef búið til samhæft forritaskil fyrir fyrirspurnir til að koma okkur af stað, þó að vísu hef ég ekki hugsað mikið um það þar sem það er frávik frá því sem við erum að gera hér. Hér er frekar einfalt starfandi dæmi um endurnýtanlegan fyrirspurnarsmið: Sjá Pen queryXPath [gaflað] eftir Bryan Rasmussen. Ég hef bætt tveimur aðferðum við skjalhlutinn: queryCSSSelectors (sem er í rauninni querySelectorAll) og queryXPaths. Báðar þessar skila queryResults hlut:
{ queryType: hnútar | strengur | númer | Boolean, Niðurstöður: allir[] // html þættir, xml þættir, strengir, tölur, boolean, queryCSSSelectors: (query: string, amend: Boolean) => queryResults, queryXpaths: (query: string, amend: Boolean) => queryResults }
queryCSSSelectors og queryXpaths aðgerðir keyra fyrirspurnina sem þú gefur þeim yfir þættina í niðurstöðufylkinu, svo framarlega sem niðurstöðufylkin er auðvitað af hnútum. Annars mun það skila queryResult með tómu fylki og tegund hnúta. Ef breyta eiginleiki er stilltur á satt, munu aðgerðirnar breyta eigin queryResults. Ekki ætti undir neinum kringumstæðum að nota þetta í framleiðsluumhverfi. Ég er að gera það á þennan hátt eingöngu til að sýna fram á hin ýmsu áhrif þess að nota tvö fyrirspurnar-API saman. Dæmi um fyrirspurnir Ég vil sýna nokkur dæmi um mismunandi XPath fyrirspurnir sem sýna fram á nokkra af þeim öflugu hlutum sem þeir geta gert og hvernig þeir geta verið notaðir í stað annarra aðferða. Fyrsta dæmið er //li/text(). Þetta leitar í alla li þætti og skilar textahnútum þeirra. Svo ef við myndum spyrjast fyrir um eftirfarandi HTML:
- einn
- tveir
- þrjú
…þetta er það sem er skilað:
{"queryType":"xpathEvaluate","results":["einn","tveir","þrír"],"resultType":"strengur"}
Með öðrum orðum, við fáum eftirfarandi fylki: ["einn", "tveir", "þrír"]. Venjulega myndirðu spyrjast fyrir um li þættina til að fá það, breyta niðurstöðu þeirrar fyrirspurnar í fylki, kortleggja fylkið og skila textahnút hvers þáttar. En við getum gert það hnitmiðaðri með XPath: document.queryXPaths("//li/text()").results.
Taktu eftir að leiðin til að fá textahnút er að nota text(), sem lítur út eins og fallundirskrift — og það er það. Það skilar textahnút frumefnis. Í dæminu okkar eru þrír li þættir í merkingunni, sem hver inniheldur texta ("einn", "tveir" og "þrír").
Við skulum skoða enn eitt dæmið um texta() fyrirspurn. Gerum ráð fyrir að þetta sé merking okkar:
Við skulum skrifa fyrirspurn sem skilar href eigindargildinu: document.queryXPaths("//a[text() = 'Innskráning']/@href").results.
Þetta er XPath fyrirspurn á núverandi skjali, rétt eins og síðasta dæmið, en í þetta skiptið skilum við href eigindinni á hlekk (einingu) sem inniheldur textann „Skráðu þig inn“. Hið raunverulega skilaðiNiðurstaðan er ["/login.html"]. Yfirlit yfir XPath aðgerðir Það eru til nokkrar XPath aðgerðir og þú þekkir þær líklega ekki. Það eru nokkrir, held ég, sem vert er að vita um, þar á meðal eftirfarandi:
byrjar-meðEf texti byrjar á tilteknu öðru textadæmi, byrjar-með(@href, 'http:') skilar satt ef href eiginleiki byrjar á http:. containsEf texti inniheldur tiltekið annað textadæmi, contains(text(), „Smashing Magazine“) skilar satt ef textahnútur inniheldur orðin „Smashing Magazine“ hvar sem er. count Skilar talningu á því hversu margar samsvörun eru við fyrirspurn. Til dæmis, count(//*[starts-with(@href, 'http:']) skilar fjölda af því hversu margir tenglar í samhengishnútnum eru með þætti með href-eigind sem inniheldur textann sem byrjar á http:. undirstrengur Virkar eins og JavaScript undirstreng, nema þú sendir strenginn sem rök. Til dæmis, undirstreng ("textinn minn", 2, 4) skilar "y t". substring-before Skilar hluta strengs á undan öðrum streng. Til dæmis, substing-before("my text", " ") skilar "my". Á sama hátt skilar substring-before("hæ","bless") tómum streng. substring-after Skilar hluta strengs á eftir öðrum streng. Til dæmis, substing-after("textinn minn", " ") skilar "texta". Á sama hátt skilar substring-after("hæ","bæ") tómum streng. normalize-space Skilar rifrildisstrengnum með hvítu bili sem er staðlað með því að fjarlægja fremsta og aftan hvíta bil og skipta út röðum hvítbilsstafa fyrir eitt bil. skilar ekki boolean satt ef rökin eru ósönn, annars ósönn. true Skilar boolean true. false Skilar boolean false. concatÞað sama og JavaScript concat, nema þú keyrir það ekki sem aðferð á streng. Þess í stað setur þú inn alla strengina sem þú vilt sameina. string-lengthÞetta er ekki það sama og JavaScript string-length, heldur skilar lengd strengsins sem hún er gefin upp sem rök. translateÞetta tekur streng og breytir annarri röksemdinni í þriðju röksemdina. Til dæmis, translate("abcdef", "abc", "XYZ") gefur út XYZdef.
Fyrir utan þessar tilteknu XPath aðgerðir, þá er fjöldi annarra aðgerða sem virka alveg eins og JavaScript hliðstæður þeirra - eða hliðstæður á í rauninni hvaða forritunarmáli sem er - sem þér myndi líklega líka finnast gagnlegt, eins og gólf, loft, hring, summa, og svo framvegis. Eftirfarandi kynningu sýnir hverja þessara aðgerða: Sjá penna XPath tölulegar aðgerðir [gaflaðar] eftir Bryan Rasmussen. Athugaðu að, eins og flestar strengjameðferðaraðgerðir, taka margar tölulegar aðgerðir eitt inntak. Þetta er auðvitað vegna þess að þeir eiga að vera notaðir til að spyrjast fyrir, eins og í síðasta XPath dæmi: //li[hæð(texti()) > 250]/@val
Ef þú notar þá, eins og flest dæmin gera, endar þú með því að keyra það á fyrsta hnút sem passar við slóðina. Það eru líka nokkrar tegundaviðskiptaaðgerðir sem þú ættir líklega að forðast vegna þess að JavaScript hefur nú þegar sín eigin tegundumbreytingarvandamál. En það geta verið tímar þegar þú vilt breyta streng í tölu til að athuga það á móti annarri tölu. Aðgerðir sem stilla gerð eitthvað eru boolean, tala, strengur og hnútur. Þetta eru mikilvægu XPath gagnagerðirnar. Og eins og þú gætir ímyndað þér er hægt að nota flestar þessar aðgerðir á gagnagerðum sem eru ekki DOM hnútar. Til dæmis tekur undirstreng-after streng eins og við höfum þegar fjallað um, en það gæti verið strengurinn frá href eigind. Það getur líka bara verið strengur:
const testSubstringAfter = document.queryXPaths("substring-after('halló heimur',' ')");
Augljóslega mun þetta dæmi gefa okkur niðurstöðurnar sem ["heimur"]. Til að sýna þetta í verki hef ég búið til kynningarsíðu með því að nota aðgerðir gegn hlutum sem eru ekki DOM hnútar: Sjá Pen queryXPath [gaflað] eftir Bryan Rasmussen. Þú ættir að taka eftir þeim þætti sem kemur á óvart í þýðingaaðgerðinni, sem er að ef þú ert með staf í annarri röksemdinni (þ.e. listanum yfir stafi sem þú vilt þýða) og engan samsvarandi staf til að þýða á, verður sá stafur fjarlægður úr úttakinu. Þannig þetta:
translate('Halló, ég heiti Inigo Montoya, þú drapst föður minn, búðu þig undir að deyja','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
… leiðir af sér strenginn, þar á meðal bil: [" * * ** "]
Þetta þýðir að verið er að þýða bókstafinn „a“ í stjörnu (*), en annar hver stafur sem er ekki með þýðingu miðað við markstrenginn er alveg fjarlægður. Hvíta rýmið er allt sem við eigum eftirá milli þýddu „a“-stafanna. Svo aftur, þessi fyrirspurn:
translate('Halló, ég heiti Inigo Montoya, þú drapst föður minn, búðu þig undir að deyja','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*******************************************************')")
… er ekki með vandamálið og gefur út niðurstöðu sem lítur svona út:
"***** *** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Það gæti komið þér í opna skjöldu að það er engin auðveld leið í JavaScript til að gera nákvæmlega það sem XPath þýðingaaðgerðin gerir, þó að í mörgum tilfellum geti replaceAll með reglulegum tjáningum séð um það. Þú gætir notað sömu nálgun og ég hef sýnt, en það er ekki ákjósanlegt ef allt sem þú vilt er að þýða strengina. Eftirfarandi kynningu umlykur þýðingaraðgerð XPath til að bjóða upp á JavaScript útgáfu: Sjá pennaþýðingaraðgerðina [gaflað] eftir Bryan Rasmussen. Hvar gætirðu notað eitthvað svona? Íhugaðu Caesar Cipher dulkóðun með þriggja staða offsetu (t.d. efstu dulkóðun frá 48 f.Kr.):
translate("Caesar ætlar að fara yfir Rubicon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Inntakstextinn „Caesar ætlar að fara yfir Rubicon!“ leiðir til „Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!“ Til að gefa annað fljótlegt dæmi um mismunandi möguleika bjó ég til málmfall sem tekur strenginntak og notar þýðingarfall til að skila textanum, þar með talið alla stafi sem taka umhljóð. Sjá málmfallið Penna [gaflað] eftir Bryan Rasmussen.
const málmur = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
Og ef textinn „Motley Crue ræður, rokkaðu á dudes!“ er gefinn textinn „Mötley Crüe rüles, röck ön düdes!“ Augljóslega gæti maður haft alls kyns skopstælingar á þessari aðgerð. Ef það ert þú, þá ætti þessi TVTropes grein að veita þér mikinn innblástur. Notkun CSS með XPath Mundu að aðalástæðan okkar fyrir því að nota CSS veljara ásamt XPath: CSS skilur nokkurn veginn hvað flokkur er, en það besta sem þú getur gert með XPath er strengjasamanburður á bekkjareigindinni. Það mun virka í flestum tilfellum. En ef þú lendir einhvern tíma í aðstæðum þar sem til dæmis einhver bjó til flokka sem heita .primaryLinks og .primaryLinks2 og þú værir að nota XPath til að fá .primaryLinks bekkinn, þá myndirðu líklega lenda í vandræðum. Svo lengi sem það er ekkert kjánalegt svona, myndirðu líklega nota XPath. En mér þykir leiðinlegt að segja frá því að ég hef unnið á stöðum þar sem fólk gerir svona kjánalega hluti. Hér er önnur kynning sem notar CSS og XPath saman. Það sýnir hvað gerist þegar við notum kóðann til að keyra XPath á samhengishnút sem er ekki hnútur skjalsins. Sjáðu Pen css og xpath saman [forked] eftir Bryan Rasmussen. CSS fyrirspurnin er .relatedarticles a, sem sækir tvo a þættina í div sem er úthlutað .relatedarticles flokki. Eftir það eru þrjár „slæmar“ fyrirspurnir, það er að segja fyrirspurnir sem gera ekki það sem við viljum að þær geri þegar þær keyra með þessa þætti sem samhengishnút. Ég get útskýrt hvers vegna þeir haga sér öðruvísi en þú gætir búist við. Þrjár slæmu fyrirspurnirnar sem um ræðir eru:
//text(): Skilar öllum textanum í skjalinu. //a/text(): Skilar öllum texta inni í tenglum í skjalinu. ./a/text(): Skilar engum niðurstöðum.
Ástæðan fyrir þessum niðurstöðum er sú að á meðan samhengið þitt er þættir sem skilað er frá CSS fyrirspurninni, þá gengur // gegn öllu skjalinu. Þetta er styrkur XPath; CSS getur ekki farið frá hnút upp í forföður og síðan í systkini þess forföður, og gengið niður til afkvæmis þess systkina. En XPath getur. Á meðan spyr ./ fyrir börn núverandi hnúts, þar sem punkturinn (.) táknar núverandi hnút og skástrikið (/) táknar að fara í einhvern undirhnút - hvort það er eiginleiki, þáttur eða texti ræðst af næsta hluta slóðarinnar. En það er ekkert barn sem er valið af CSS fyrirspurninni, þannig að sú fyrirspurn skilar heldur engu. Það eru þrjár góðar fyrirspurnir í síðustu kynningu:
.//texti(), ./texti(), normalize-space(./text()).
Normalize-space fyrirspurnin sýnir XPath aðgerðanotkun, en lagar einnig vandamál sem er innifalið í hinum fyrirspurnunum. HTML er byggt upp svona:
Gerðu sjálfvirkan eiginleikaprófun þína með Selenium WebDriver
Fyrirspurnin skilar línustraumi í upphafi og lok textahnútsins,og normalize-space fjarlægir þetta. Að nota hvaða XPath fall sem er sem skilar einhverju öðru en Boolean með inntak XPath á við um aðrar aðgerðir. Eftirfarandi kynningu sýnir fjölda dæma: Sjá dæmi um Pen xpath aðgerðir [forked] eftir Bryan Rasmussen. Fyrsta dæmið sýnir vandamál sem þú ættir að varast. Nánar tiltekið eftirfarandi kóða:
document.queryXPaths("substring-after(//a/@href,'https://')");
…skilar einum streng:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Það er skynsamlegt, ekki satt? Þessar aðgerðir skila ekki fylkjum heldur stökum strengjum eða stökum tölum. Að keyra aðgerðina hvar sem er með mörgum niðurstöðum skilar aðeins fyrstu niðurstöðu. Önnur niðurstaðan sýnir hvað við viljum raunverulega:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Sem skilar fylki af tveimur strengjum:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath aðgerðir geta verið hreiður eins og aðgerðir í JavaScript. Þannig að ef við þekkjum vefslóð smashing tímaritsins, gætum við gert eftirfarandi (mælt er með því að nota sniðmátsstafi): `þýða( undirstreng( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Þetta er að verða aðeins of flókið að því marki að það þarf athugasemdir sem lýsa því hvað það gerir: taktu alla vefslóðina úr href-eigindinni á eftir www.smashingmagazine.com/, fjarlægðu fyrstu níu stafina, þýddu síðan skástrikið (/) yfir á ekki neitt til að losna við framskásturinn í lokin. Fylki sem myndast:
["feature-testing-selenium-webdriver","sjálfvirkar-prófunarniðurstöður-bæta-aðgengi"]
Fleiri XPath notkunartilvik XPath getur virkilega skínt í prófunum. Ástæðan er ekki erfið að sjá, þar sem XPath er hægt að nota til að fá alla þætti í DOM, frá hvaða stöðu sem er í DOM, en CSS getur það ekki. Þú getur ekki treyst á að CSS flokkar haldist stöðugir í mörgum nútíma byggingarkerfum, en með XPath getum við gert öflugri samsvörun um hvað textainnihald frumefnis er, óháð breyttri DOM uppbyggingu. Það hafa verið rannsóknir á tækni sem gerir þér kleift að gera seigur XPath próf. Ekkert er verra en að láta prófin flagna út og mistakast bara vegna þess að CSS valur virkar ekki lengur vegna þess að eitthvað hefur verið endurnefnt eða fjarlægt. XPath er líka mjög frábært við útdrátt úr mörgum staðsetningartækjum. Það eru fleiri en ein leið til að nota XPath fyrirspurnir til að passa við frumefni. Það sama á við um CSS. En XPath fyrirspurnir geta borið í hlutina á markvissari hátt sem takmarkar það sem skilar sér, sem gerir þér kleift að finna ákveðna samsvörun þar sem það geta verið nokkrar mögulegar samsvörun. Til dæmis getum við notað XPath til að skila tilteknu h2 staki sem er inni í div sem kemur strax á eftir systkina div sem aftur á móti inniheldur barn myndeiningu með data-testID="leader" eigind á sér:
skil ekki þessa fyrirsögn
Ekki fatta þessa fyrirsögn heldur
hausinn fyrir leiðtogamyndina
Þetta er fyrirspurnin: document.queryXPaths(` //div[ eftirfarandi systkini::div[1] /img[@data-testID='leiðtogi'] ] /h2/ texti() `);
Við skulum senda inn kynningu til að sjá hvernig þetta kemur allt saman: Sjáðu Pen Complex H2 fyrirspurnina [gaflað] eftir Bryan Rasmussen. Svo, já. Það eru fullt af mögulegum leiðum að hvaða þætti sem er í prófi með XPath. XSLT 1.0 Afskrift Ég nefndi snemma að Chrome teymið ætlar að fjarlægja XSLT 1.0 stuðning úr vafranum. Það er mikilvægt vegna þess að XSLT 1.0 notar XML-miðaða forritun fyrir umbreytingu skjala sem aftur treystir á XPath 1.0, sem er það sem er að finna í flestum vöfrum. Þegar það gerist týnum við lykilhluta XPath. En miðað við þá staðreynd að XPath er virkilega frábært til að skrifa próf, þá finnst mér ólíklegt að XPath í heild sinni hverfi í bráð. Sem sagt, ég hef tekið eftir því að fólk fær áhuga á eiginleikum þegar það er tekið í burtu. Og það er vissulega rétt þegar XSLT 1.0 er aflagt. Það er heil umræða í gangi hjá Hacker News full af rökum gegn afskriftinni. Færslan sjálf er frábært dæmi um að búa til bloggramma með XSLT. Þúgetur lesið umræðuna sjálfur, en það kemur inn á hvernig JavaScript gæti verið notað sem shim fyrir XLST til að takast á við svona mál. Ég hef líka séð tillögur um að vafrar ættu að nota SaxonJS, sem er tengi fyrir Saxon XSLT, XQUERY og XPath vélar JavaScript. Það er áhugaverð hugmynd, sérstaklega þar sem Saxon-JS útfærir núverandi útgáfu af þessum forskriftum, en það er enginn vafri sem útfærir neina útgáfu af XPath eða XSLT umfram 1.0, og enginn sem útfærir XQuery. Ég náði til Norm Tovey-Walsh hjá Saxonica, fyrirtækinu á bak við SaxonJS og aðrar útgáfur af Saxon vélinni. Hann sagði: "Ef einhver vafrasali hefði áhuga á að taka SaxonJS sem upphafspunkt til að samþætta nútíma XML tækni í vafrann, þá værum við spennt að ræða það við þá." - Norm Tovey-Walsh
En bætti líka við: "Það kæmi mér mjög á óvart ef einhver teldi að að taka SaxonJS í núverandi mynd og sleppa því í vafrauppbyggingu óbreytt væri tilvalin nálgun. Vafrasali, eðli málsins samkvæmt, gæti nálgast samþættinguna á miklu dýpri stigi en við getum „utan frá“.“ — Norm Tovey-Walsh
Þess má geta að ummæli Tovey-Walsh komu um viku áður en XSLT tilkynnti um afskrift. Niðurstaða Ég gæti haldið áfram og áfram. En ég vona að þetta hafi sýnt fram á kraft XPath og gefið þér fullt af dæmum sem sýna hvernig á að nota það til að ná frábærum hlutum. Þetta er fullkomið dæmi um eldri tækni í vafrastaflanum sem hefur enn nóg af notagildi í dag, jafnvel þótt þú hafir aldrei vitað að hún væri til eða aldrei íhugað að ná í hana. Frekari lestur
„Að auka seiglu sjálfvirkra vefprófa með náttúrulegu tungumáli“ (ACM Digital Library) eftir Maroun Ayli, Youssef Bakouny, Nader Jalloul og Rima Kilany Þessi grein gefur mörg XPath dæmi til að skrifa seigur próf. XPath (MDN) Þetta er frábær staður til að byrja ef þú vilt tæknilega útskýringu á því hvernig XPath virkar. XPath kennsla (ZVON) Mér hefur fundist þessi kennsla vera mest hjálpleg í mínu eigin námi, þökk sé mikið af dæmum og skýrum skýringum. XPatherÞetta gagnvirka tól gerir þér kleift að vinna beint með kóðann.
