Matagal na akong nasa front-end development para makakita ng trend sa paglipas ng mga taon: ang mga nakababatang developer na nagtatrabaho sa isang bagong paradigm ng programming nang hindi nauunawaan ang makasaysayang konteksto nito. Siyempre, lubos na nauunawaan ang hindi alam ang isang bagay. Ang web ay isang napakalaking lugar na may magkakaibang hanay ng mga kasanayan at specialty, at hindi namin palaging alam kung ano ang hindi namin alam. Ang pag-aaral sa larangang ito ay isang patuloy na paglalakbay sa halip na isang bagay na minsang nangyayari at nagtatapos. Halimbawa: May nagtanong sa aking team kung posible bang sabihin kung ang mga user ay nagna-navigate palayo sa isang partikular na tab sa UI. Itinuro ko ang kaganapan bago mag-unload ng JavaScript. Ngunit alam ng mga nakausap na nito dati na posible ito dahil natamaan sila ng mga alerto tungkol sa hindi na-save na data sa iba pang mga site, kung saan bago ang pag-unload ay isang karaniwang kaso ng paggamit. Itinuro ko rin ang pageHide at visibilityBaguhin ang mga kaganapan sa aking kasamahan para sa mahusay na sukat. Paano ko nalaman ang tungkol doon? Dahil ito ay lumabas sa isa pang proyekto, hindi dahil pinag-aralan ko ito noong una kong natutunan ang JavaScript. Ang katotohanan ay ang mga modernong front-end na balangkas ay nakatayo sa mga balikat ng mga higante ng teknolohiya na nauna sa kanila. Ang mga ito ay abstract na mga kasanayan sa pag-unlad, madalas para sa isang mas mahusay na karanasan ng developer na binabawasan, o kahit na inaalis, ang pangangailangang malaman o hawakan kung ano ang tradisyonal na naging mahahalagang konsepto sa harap na malamang na dapat malaman ng lahat. Isaalang-alang ang CSS Object Model (CSSOM). Maaari mong asahan na ang sinumang nagtatrabaho sa CSS at JavaScript ay may maraming hands-on na karanasan sa CSSOM, ngunit hindi palaging ganoon ang mangyayari. Nagkaroon ng React na proyekto para sa isang e-commerce na site na pinagtrabahuan ko kung saan kailangan naming mag-load ng stylesheet para sa kasalukuyang napiling provider ng pagbabayad. Ang problema ay ang stylesheet ay naglo-load sa bawat pahina kapag ito ay talagang kailangan sa isang partikular na pahina. Ang developer na nakatalaga sa paggawa nito ay hindi kailanman nag-load ng stylesheet nang dynamic. Muli, lubos itong mauunawaan kapag inalis ng React ang tradisyonal na diskarte na maaaring naabot mo. Ang CSSOM ay malamang na hindi isang bagay na kailangan mo sa iyong pang-araw-araw na gawain. Ngunit malamang na kakailanganin mong makipag-ugnayan dito sa isang punto, kahit na sa isang pagkakataon. Ang mga karanasang ito ang nagbigay inspirasyon sa akin na isulat ang artikulong ito. Mayroong maraming umiiral na mga tampok sa web at teknolohiya sa ligaw na hindi mo maaaring direktang mahawakan sa iyong pang-araw-araw na trabaho. Marahil ay medyo bago ka sa pag-develop ng web at hindi mo alam ang tungkol sa mga ito dahil siksik ka sa abstraction ng isang partikular na framework na hindi nangangailangan sa iyo na malaman ito nang malalim, o kahit na sa lahat. Partikular akong nagsasalita tungkol sa XML, na alam ng marami sa atin na isang sinaunang wika na hindi lubos na naiiba sa HTML. Ibinabalita ko ito dahil sa kamakailang mga talakayan sa WHATWG na nagmumungkahi na ang isang makabuluhang bahagi ng XML stack na kilala bilang XSLT programming ay dapat alisin sa mga browser. Ito ang eksaktong uri ng mas lumang, umiiral na teknolohiya na mayroon kami sa loob ng maraming taon na maaaring magamit para sa isang bagay na kasing praktikal ng sitwasyon ng CSSOM na kinaroroonan ng aking koponan. Nakapagtrabaho ka na ba sa XSLT dati? Tingnan natin kung tayo ay lubos na umaasa sa mas lumang teknolohiyang ito at ginagamit ang mga tampok nito sa labas ng konteksto ng XML upang harapin ang mga problema sa totoong mundo ngayon. XPath: Ang Central API Ang pinakamahalagang teknolohiya ng XML na marahil ang pinakakapaki-pakinabang sa labas ng isang tuwid na XML perspective ay ang XPath, isang query language na nagbibigay-daan sa iyong makahanap ng anumang node o attribute sa isang markup tree na may isang root element. Mayroon akong personal na pagmamahal para sa XSLT, ngunit umaasa din iyon sa XPath, at ang personal na pagmamahal ay dapat isantabi sa kahalagahan ng pagraranggo. Ang argumento para sa pag-alis ng XSLT ay hindi nagbabanggit ng XPath, kaya sa palagay ko ay pinapayagan pa rin ito. Maganda iyon dahil ang XPath ang sentro at pinakamahalagang API sa suite ng mga teknolohiyang ito, lalo na kapag sinusubukang maghanap ng magagamit sa labas ng normal na paggamit ng XML. Mahalaga ito dahil, habang ang mga tagapili ng CSS ay maaaring gamitin upang mahanap ang karamihan sa mga elemento sa iyong pahina, hindi nila mahahanap ang lahat ng ito. Higit pa rito, hindi magagamit ang mga tagapili ng CSS upang maghanap ng elemento batay sa kasalukuyang posisyon nito sa DOM. Pwede ang XPath. Ngayon, ang ilan sa inyo na nagbabasa nito ay maaaring alam ang XPath, at ang ilan ay maaaring hindi. Ang XPath ay isang medyo malaking bahagi ng teknolohiya, at hindi ko talaga maituturo ang lahat ng mga pangunahing kaalaman at maipakita rin sa iyo ang mga magagandang bagay na gagawin dito sa isang artikulong tulad nito. Sinubukan ko talagang isulat ang artikulong iyon, ngunit ang karaniwang publikasyon ng Smashing Magazine ay hindi umabot sa 5,000 salita. Ako ay nasa higit sa2,000 salita habang nasa kalagitnaan pa lang ng basics. Kaya, sisimulan kong gumawa ng mga cool na bagay sa XPath at bibigyan ka ng ilang link na magagamit mo para sa mga pangunahing kaalaman kung sa tingin mo ay kawili-wili ang bagay na ito. Pinagsasama ang XPath at CSS Ang XPath ay maaaring gumawa ng maraming bagay na hindi magagawa ng mga tagapili ng CSS kapag nagtatanong ng mga elemento. Ngunit ang mga tagapili ng CSS ay maaari ding gumawa ng ilang bagay na hindi magagawa ng XPath, ibig sabihin, mga elemento ng query ayon sa pangalan ng klase.
CSS XPath .myClass /*[naglalaman(@class, "myClass")]
Sa halimbawang ito, ang CSS ay nagtatanong ng mga elemento na naglalaman ng .myClass classname. Samantala, ang halimbawa ng XPath ay nagtatanong ng mga elemento na naglalaman ng attribute class na may string na "myClass". Sa madaling salita, pumipili ito ng mga elementong may myClass sa anumang attribute, kabilang ang mga elementong may .myClass classname — pati na rin ang mga elementong may “myClass” sa string, gaya ng .myClass2. Ang XPath ay mas malawak sa kahulugang iyon. Kaya, hindi. Hindi ko iminumungkahi na dapat nating itapon ang CSS at simulan ang pagpili ng lahat ng elemento sa pamamagitan ng XPath. Hindi iyon ang punto. Ang punto ay ang XPath ay makakagawa ng mga bagay na hindi magagawa ng CSS at maaari pa ring maging lubhang kapaki-pakinabang, kahit na ito ay isang mas lumang teknolohiya sa browser stack at maaaring hindi halata sa unang tingin. Gamitin natin ang dalawang teknolohiya nang magkasama hindi lamang dahil kaya natin, ngunit dahil may matututunan tayo tungkol sa XPath sa proseso, na ginagawa itong isa pang tool sa iyong stack — isa na maaaring hindi mo alam na nariyan na! Ang problema ay ang paraan ng document.evaluate ng JavaScript at ang iba't ibang paraan ng tagapili ng query na ginagamit namin sa mga CSS API para sa JavaScript ay hindi tugma. Gumawa ako ng compatible na querying API para makapagsimula tayo, bagama't tinatanggap ko, hindi ko ito masyadong pinag-isipan dahil malayo ito sa ginagawa natin dito. Narito ang isang medyo simpleng gumaganang halimbawa ng isang magagamit muli na tagabuo ng query: Tingnan ang Pen queryXPath [na-forked] ni Bryan Rasmussen. Nagdagdag ako ng dalawang pamamaraan sa object ng dokumento: queryCSSSelectors (na mahalagang querySelectorAll) at queryXPaths. Parehong ito ay nagbabalik ng queryResults object:
{ Uri ng query: mga node | string | numero | boolean, mga resulta: anumang[] // html elemento, xml elemento, string, numero, boolean, queryCSSSelectors: (query: string, amend: boolean) => queryResults, queryXpaths: (query: string, amend: boolean) => queryResults }
Ang queryCSSSelectors at queryXpaths function ay nagpapatakbo ng query na ibibigay mo sa kanila sa mga elemento sa hanay ng mga resulta, hangga't ang hanay ng mga resulta ay may mga uri ng node, siyempre. Kung hindi, magbabalik ito ng queryResult na may isang walang laman na array at isang uri ng mga node. Kung ang pag-amyenda ng property ay nakatakda sa true, babaguhin ng mga function ang sarili nilang queryResults. Sa anumang pagkakataon dapat itong gamitin sa isang kapaligiran ng produksyon. Ginagawa ko ito sa paraang ito para lang ipakita ang iba't ibang epekto ng paggamit ng dalawang query API nang magkasama. Mga Halimbawang Tanong Gusto kong magpakita ng ilang halimbawa ng iba't ibang mga query sa XPath na nagpapakita ng ilan sa mga makapangyarihang bagay na maaari nilang gawin at kung paano sila magagamit sa halip ng iba pang mga diskarte. Ang unang halimbawa ay //li/text(). Itatanong nito ang lahat ng li element at ibinabalik ang kanilang mga text node. Kaya, kung itatanong natin ang sumusunod na HTML:
- isa
- dalawa
- tatlo
…ito ang ibinalik:
{"queryType":"xpathEvaluate","results":["one","two","three"],"resultType":"string"}
Sa madaling salita, nakukuha namin ang sumusunod na array: ["isa","dalawa","tatlo"]. Karaniwan, itatanong mo para makuha iyon ng mga elemento ng li, gawing array ang resulta ng query na iyon, imapa ang array, at ibalik ang text node ng bawat elemento. Ngunit magagawa natin iyon nang mas maigsi sa XPath: document.queryXPaths("//li/text()").mga resulta.
Pansinin na ang paraan upang makakuha ng text node ay ang paggamit ng text(), na mukhang isang function signature — at ito nga. Ibinabalik nito ang text node ng isang elemento. Sa aming halimbawa, mayroong tatlong elemento ng li sa markup, bawat isa ay naglalaman ng teksto ("isa", "dalawa", at "tatlo").
Tingnan natin ang isa pang halimbawa ng text() query. Ipagpalagay na ito ang aming markup:
Sumulat tayo ng query na nagbabalik ng href attribute value: document.queryXPaths("//a[text() = 'Mag-sign In']/@href").mga resulta.
Ito ay isang query ng XPath sa kasalukuyang dokumento, tulad ng huling halimbawa, ngunit sa pagkakataong ito ay ibabalik namin ang href attribute ng isang link (isang elemento) na naglalaman ng text na "Mag-sign In". Bumalik ang aktwalang resulta ay ["/login.html"]. Pangkalahatang-ideya ng Mga Function ng XPath Mayroong ilang mga function ng XPath, at malamang na hindi ka pamilyar sa kanila. Mayroong ilang, sa tingin ko, na nagkakahalaga ng pag-alam tungkol sa, kabilang ang mga sumusunod:
starts-withKung ang isang text ay nagsisimula sa isang partikular na ibang halimbawa ng text, starts-with(@href, 'http:') ay nagbabalik ng true kung ang isang href attribute ay nagsisimula sa http:. containsKung ang isang text ay naglalaman ng partikular na iba pang halimbawa ng text, contains(text(), "Smashing Magazine") ay nagbabalik ng true kung ang isang text node ay naglalaman ng mga salitang "Smashing Magazine" sa loob nito kahit saan. countIbinabalik ang bilang kung gaano karaming mga tugma ang mayroon sa isang query. Halimbawa, ang count(//*[starts-with(@href, 'http:']) ay nagbabalik ng bilang kung gaano karaming mga link sa context node ang may mga elemento na may isang href attribute na naglalaman ng text na nagsisimula sa http:. substringWorks tulad ng JavaScript substring, maliban kung ipasa mo ang string bilang isang argumento. Halimbawa, ang substring("my text", 2, 4) ay nagbabalik ng "y t". substring-beforeIbinabalik ang bahagi ng isang string bago ang isa pang string. Halimbawa, ang substing-before("my text", " ") ay nagbabalik ng "my". Katulad nito, ang substring-before("hi","bye") ay nagbabalik ng walang laman na string. substring-afterIbinabalik ang bahagi ng isang string pagkatapos ng isa pang string. Halimbawa, ang substing-after("my text", " ") ay nagbabalik ng "text". Katulad nito, ang substring-after("hi","bye") ay nagbabalik ng walang laman na string. normalize-spaceIbinabalik ang string ng argumento na may whitespace na na-normalize sa pamamagitan ng pagtanggal sa lead at trailing na whitespace at pagpapalit ng mga pagkakasunud-sunod ng mga whitespace na character ng isang solong espasyo. notReturns isang boolean true kung ang argument ay false, kung hindi man ay false. trueIbinabalik ang boolean true. falseIbinabalik ang boolean false. concatAng parehong bagay tulad ng JavaScript concat, maliban kung hindi mo ito pinapatakbo bilang isang paraan sa isang string. Sa halip, inilagay mo ang lahat ng mga string na nais mong pagsamahin. string-lengthHindi ito kapareho ng JavaScript string-length, ngunit ibinabalik ang haba ng string na ibinigay nito bilang argumento. translateThis ay tumatagal ng isang string at binabago ang pangalawang argumento sa ikatlong argumento. Halimbawa, ang translate("abcdef", "abc", "XYZ") ay naglalabas ng XYZdef.
Bukod sa mga partikular na function ng XPath na ito, may ilang iba pang mga function na gumagana nang kapareho ng kanilang mga katapat na JavaScript — o mga katapat sa karaniwang anumang programming language — na malamang na kapaki-pakinabang din sa iyo, tulad ng sahig, kisame, bilog, kabuuan, at iba pa. Ang sumusunod na demo ay naglalarawan sa bawat isa sa mga function na ito: Tingnan ang Pen XPath Numerical function [na-forked] ni Bryan Rasmussen. Tandaan na, tulad ng karamihan sa mga function ng pagmamanipula ng string, marami sa mga numerical ang kumukuha ng isang input. Ito ay, siyempre, dahil ang mga ito ay dapat na gamitin para sa pagtatanong, tulad ng sa huling halimbawa ng XPath: //li[floor(text()) > 250]/@val
Kung gagamitin mo ang mga ito, tulad ng ginagawa ng karamihan sa mga halimbawa, papatakbuhin mo ito sa unang node na tumutugma sa landas. Mayroon ding ilang uri ng mga function ng conversion na malamang na dapat mong iwasan dahil ang JavaScript ay mayroon nang sariling mga problema sa uri ng conversion. Ngunit maaaring may mga pagkakataon na gusto mong i-convert ang isang string sa isang numero upang suriin ito laban sa ibang numero. Ang mga function na nagtatakda ng uri ng isang bagay ay boolean, numero, string, at node. Ito ang mga mahahalagang datatype ng XPath. At gaya ng maiisip mo, karamihan sa mga function na ito ay maaaring gamitin sa mga datatype na hindi mga DOM node. Halimbawa, ang substring-after ay kumukuha ng string gaya ng natalakay na namin, ngunit maaaring ito ay ang string mula sa isang href attribute. Maaari rin itong maging isang string lamang:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Malinaw, ibabalik sa atin ng halimbawang ito ang hanay ng mga resulta bilang ["mundo"]. Para ipakita ito sa aksyon, gumawa ako ng demo page gamit ang mga function laban sa mga bagay na hindi DOM node: Tingnan ang Pen queryXPath [na-forked] ni Bryan Rasmussen. Dapat mong tandaan ang nakakagulat na aspeto ng translate function, na kung mayroon kang isang character sa pangalawang argumento (ibig sabihin, ang listahan ng mga character na gusto mong isalin) at walang katugmang character na isasalin, ang character na iyon ay aalisin sa output. Kaya, ito:
translate('Hello, My Name is Inigo Montoya, pinatay mo ang aking ama, maghanda para mamatay','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…mga resulta sa string, kabilang ang mga puwang: [" * * ** "]
Nangangahulugan ito na ang titik na "a" ay isinasalin sa isang asterisk (*), ngunit ang bawat iba pang character na walang pagsasalin na ibinigay sa target na string ay ganap na tinanggal. Ang whitespace na lang ang natitira sa aminsa pagitan ng isinalin na "a" na mga character. At muli, ang query na ito:
translate('Hello, My Name is Inigo Montoya, pinatay mo ang tatay ko, maghanda kang mamatay','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','******************************************************')")
…ay walang problema at naglalabas ng resulta na ganito:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Maaaring mapansin mo na walang madaling paraan sa JavaScript upang gawin nang eksakto kung ano ang ginagawa ng XPath translate function, bagama't para sa maraming mga kaso ng paggamit, ang replaceAll na may mga regular na expression ay kayang hawakan ito. Maaari mong gamitin ang parehong diskarte na ipinakita ko, ngunit iyon ay suboptimal kung ang gusto mo lang ay isalin ang mga string. Binabalot ng sumusunod na demo ang function ng pagsasalin ng XPath upang magbigay ng bersyon ng JavaScript: Tingnan ang Pen translate function [na-forked] ni Bryan Rasmussen. Saan mo maaaring gamitin ang isang bagay na tulad nito? Isaalang-alang ang Caesar Cipher encryption na may tatlong lugar na offset (hal., top-of-the-line na encryption mula 48 B.C.):
translate("Pinaplano ni Caesar na tumawid sa Rubicon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Ang input text na "Pinaplano ni Caesar na tumawid sa Rubicon!" resulta sa “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Upang magbigay ng isa pang mabilis na halimbawa ng iba't ibang posibilidad, gumawa ako ng metal na function na kumukuha ng string input at gumagamit ng translate function para ibalik ang text, kasama ang lahat ng character na kumukuha ng mga umlaut. Tingnan ang function ng Pen metal [na-forked] ni Bryan Rasmussen.
const metal = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
At, kung bibigyan ng text na “Motley Crue rules, rock on dudes!”, ibabalik ang “Mötley Crüe rüles, röck ön düdes!” Malinaw, ang isa ay maaaring magkaroon ng lahat ng uri ng parody na paggamit ng function na ito. Kung ikaw iyon, ang artikulong ito sa TVTropes ay dapat magbigay sa iyo ng maraming inspirasyon. Paggamit ng CSS Sa XPath Tandaan ang aming pangunahing dahilan sa paggamit ng mga tagapili ng CSS kasama ng XPath: Medyo naiintindihan ng CSS kung ano ang isang klase, samantalang ang pinakamahusay na magagawa mo sa XPath ay ang mga paghahambing ng string ng katangian ng klase. Gagana iyon sa karamihan ng mga kaso. Ngunit kung makakaranas ka ng sitwasyon kung saan, sabihin nating, may lumikha ng mga klase na pinangalanang .primaryLinks at .primaryLinks2 at ginagamit mo ang XPath upang makuha ang .primaryLinks na klase, malamang na magkakaroon ka ng mga problema. Hangga't walang ganoong kalokohan, malamang na gagamitin mo ang XPath. Ngunit nalulungkot akong iulat na nagtrabaho ako sa mga lugar kung saan ginagawa ng mga tao ang mga uri ng kalokohang bagay. Narito ang isa pang demo gamit ang CSS at XPath nang magkasama. Ipinapakita nito kung ano ang mangyayari kapag ginamit namin ang code para magpatakbo ng XPath sa isang context node na hindi node ng dokumento. Tingnan ang Pen css at xpath na magkasama [na-forked] ni Bryan Rasmussen. Ang CSS query ay .relatedarticles a, na kumukuha ng dalawang elemento sa isang div na nakatalaga ng .relatedarticles class. Pagkatapos noon ay tatlong "masamang" query, ibig sabihin, mga query na hindi ginagawa ang gusto naming gawin nila kapag tumatakbo gamit ang mga elementong ito bilang context node. Maaari kong ipaliwanag kung bakit iba ang kanilang pag-uugali kaysa sa inaasahan mo. Ang tatlong masamang query na pinag-uusapan ay:
//text(): Ibinabalik ang lahat ng text sa dokumento. //a/text(): Ibinabalik ang lahat ng text sa loob ng mga link sa dokumento. ./a/text(): Walang ibinabalik na resulta.
Ang dahilan ng mga resultang ito ay habang ang iyong konteksto ay isang elementong ibinalik mula sa query ng CSS, // ay sumasalungat sa buong dokumento. Ito ang lakas ng XPath; Ang CSS ay hindi maaaring pumunta mula sa isang node hanggang sa isang ninuno at pagkatapos ay sa isang kapatid ng ninuno na iyon, at pumunta sa isang inapo ng kapatid na iyon. Ngunit maaari ang XPath. Samantala, ang ./ ay nagtatanong sa mga bata ng kasalukuyang node, kung saan ang tuldok (.) ay kumakatawan sa kasalukuyang node, at ang forward slash (/) ay kumakatawan sa pagpunta sa ilang child node — kung ito ay isang katangian, elemento, o teksto ay tinutukoy ng susunod na bahagi ng landas. Ngunit walang bata ang isang elemento na pinili ng CSS query, kaya ang query na iyon ay wala ring ibinabalik. Mayroong tatlong magagandang query sa huling demo na iyon:
.//text(), ./text(), normalize-space(./text()).
Ang query ng normalize-space ay nagpapakita ng paggamit ng XPath function, ngunit inaayos din ang isang problema na kasama sa iba pang mga query. Ang HTML ay nakabalangkas tulad nito:
Pag-automate ng Iyong Pagsubok sa Feature Gamit ang Selenium WebDriver
Ang query ay nagbabalik ng isang line feed sa simula at dulo ng text node,at inaalis ito ng normalize-space. Ang paggamit ng anumang XPath function na nagbabalik ng isang bagay maliban sa isang boolean na may input na XPath ay nalalapat sa iba pang mga function. Ang sumusunod na demo ay nagpapakita ng ilang mga halimbawa: Tingnan ang mga halimbawa ng Pen xpath functions [na-forked] ni Bryan Rasmussen. Ang unang halimbawa ay nagpapakita ng problemang dapat mong bantayan. Sa partikular, ang sumusunod na code:
document.queryXPaths("substring-after(//a/@href,'https://')");
…nagbabalik ng isang string:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Ito ay may katuturan, tama? Ang mga function na ito ay hindi nagbabalik ng mga arrays ngunit sa halip ay iisang string o iisang numero. Ang pagpapatakbo ng function kahit saan na may maraming resulta ay nagbabalik lamang ng unang resulta. Ipinapakita ng pangalawang resulta kung ano talaga ang gusto natin:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Na nagbabalik ng array ng dalawang string:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Maaaring ma-nest ang mga function ng XPath tulad ng mga function sa JavaScript. Kaya, kung alam namin ang istraktura ng URL ng Smashing Magazine, magagawa namin ang sumusunod (inirerekomenda ang paggamit ng mga literal na template): `translate( substring( substring-after(./@href, ‘www.smashingmagazine.com/') ,9), '/','')`
Medyo nagiging kumplikado na ito hanggang sa nangangailangan ito ng mga komentong naglalarawan kung ano ang ginagawa nito: kunin ang lahat ng URL mula sa href attribute pagkatapos ng www.smashingmagazine.com/, alisin ang unang siyam na character, pagkatapos ay i-translate ang forward slash (/) na character sa wala upang maalis ang nagtatapos na forward slash. Ang resultang array:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
Higit pang XPath Use Cases Maaari talagang sumikat ang XPath sa pagsubok. Ang dahilan ay hindi mahirap makita, dahil ang XPath ay maaaring gamitin upang makuha ang bawat elemento sa DOM, mula sa anumang posisyon sa DOM, samantalang ang CSS ay hindi. Hindi ka makakaasa sa mga klase ng CSS na nananatiling pare-pareho sa maraming modernong build system, ngunit sa XPath, nakakagawa kami ng mas mahusay na mga tugma kung ano ang nilalaman ng text ng isang elemento, anuman ang pagbabago ng istraktura ng DOM. Nagkaroon ng pananaliksik sa mga diskarte na nagbibigay-daan sa iyong gumawa ng mga nababanat na pagsubok sa XPath. Wala nang mas masahol pa kaysa sa pagkakaroon ng mga pagsubok na lumabas at mabibigo dahil lang sa isang CSS selector ay hindi na gumagana dahil may pinalitan ng pangalan o inalis. Napakahusay din ng XPath sa maramihang pagkuha ng tagahanap. Mayroong higit sa isang paraan upang magamit ang mga query sa XPath upang tumugma sa isang elemento. Ang parehong ay totoo sa CSS. Ngunit ang mga query sa XPath ay maaaring mag-drill sa mga bagay sa mas naka-target na paraan na naglilimita sa kung ano ang ibabalik, na nagbibigay-daan sa iyong makahanap ng isang partikular na tugma kung saan maaaring mayroong ilang posibleng mga tugma. Halimbawa, maaari naming gamitin ang XPath upang ibalik ang isang partikular na elemento ng h2 na nilalaman sa loob ng isang div na agad na sumusunod sa isang kapatid na div na, sa turn, ay naglalaman ng isang elemento ng larawan ng bata na may isang data-testID="lider" na katangian dito:
huwag makuha ang headline na ito
Huwag mo ring kunin ang headline na ito
Ang header para sa larawan ng pinuno
Ito ang query: document.queryXPaths(` //div[ sumusunod na kapatid::div[1] /img[@data-testID='leader'] ] /h2/ text() `);
Dumaan tayo sa isang demo para makita kung paano magkakasama ang lahat: Tingnan ang Pen Complex H2 Query [na-forked] ni Bryan Rasmussen. Kaya, oo. Maraming posibleng landas sa anumang elemento sa isang pagsubok gamit ang XPath. Paghinto sa paggamit ng XSLT 1.0 Maaga kong binanggit na ang koponan ng Chrome ay nagpaplano sa pag-alis ng suporta sa XSLT 1.0 mula sa browser. Mahalaga iyon dahil ang XSLT 1.0 ay gumagamit ng XML-focused programming para sa pagbabago ng dokumento na, sa turn, ay umaasa sa XPath 1.0, na siyang matatagpuan sa karamihan ng mga browser. Kapag nangyari iyon, mawawalan tayo ng mahalagang bahagi ng XPath. Ngunit dahil sa katotohanan na ang XPath ay talagang mahusay para sa pagsusulat ng mga pagsusulit, nakita kong malabong mawala ang XPath sa kabuuan sa lalong madaling panahon. Sabi nga, napansin kong nagiging interesado ang mga tao sa isang feature kapag inalis na ito. At tiyak na totoo iyon sa kaso ng XSLT 1.0 na hindi na ginagamit. Mayroong isang buong talakayan na nangyayari sa Hacker News na puno ng mga argumento laban sa paghinto. Ang post mismo ay isang magandang halimbawa ng paglikha ng balangkas sa pag-blog gamit ang XSLT. Ikaway maaaring basahin ang talakayan para sa iyong sarili, ngunit napupunta ito sa kung paano maaaring gamitin ang JavaScript bilang isang shim para sa XLST upang mahawakan ang mga ganitong uri ng mga kaso. Nakakita rin ako ng mga mungkahi na dapat gamitin ng mga browser ang SaxonJS, na isang port sa Saxon XSLT, XQUERY, at XPath engine ng JavaScript. Iyan ay isang kawili-wiling ideya, lalo na habang ipinapatupad ng Saxon-JS ang kasalukuyang bersyon ng mga pagtutukoy na ito, samantalang walang browser na nagpapatupad ng anumang bersyon ng XPath o XSLT na lampas sa 1.0, at walang nagpapatupad ng XQuery. Naabot ko ang Norm Tovey-Walsh sa Saxonica, ang kumpanya sa likod ng SaxonJS at iba pang mga bersyon ng Saxon engine. Sabi niya: "Kung interesado ang sinumang vendor ng browser na kunin ang SaxonJS bilang panimulang punto para sa pagsasama ng mga modernong XML na teknolohiya sa browser, matutuwa kaming talakayin ito sa kanila." - Norm Tovey-Walsh
Ngunit idinagdag din: "Lubos akong magugulat kung may mag-isip na ang pagkuha ng SaxonJS sa kasalukuyang anyo nito at pag-drop nito sa browser build na hindi nagbabago ay ang perpektong diskarte. Ang isang vendor ng browser, sa likas na katangian ng katotohanan na sila ang bumuo ng browser, ay maaaring lumapit sa pagsasama sa isang mas malalim na antas kaysa sa magagawa natin 'mula sa labas'." - Norm Tovey-Walsh
Kapansin-pansin na ang mga komento ni Tovey-Walsh ay dumating mga isang linggo bago ang anunsyo ng paghinto sa paggamit ng XSLT. Konklusyon Kaya kong magpatuloy at magpatuloy. Ngunit umaasa ako na ito ay nagpakita ng kapangyarihan ng XPath at nagbigay sa iyo ng maraming mga halimbawa na nagpapakita kung paano ito gamitin para sa pagkamit ng magagandang bagay. Ito ay isang perpektong halimbawa ng mas lumang teknolohiya sa browser stack na mayroon pa ring maraming utility ngayon, kahit na hindi mo pa alam na umiral ito o hindi kailanman naisip na abutin ito. Karagdagang Pagbasa
“Enhancing the Resiliency of Automated Web Tests with Natural Language” (ACM Digital Library) nina Maroun Ayli, Youssef Bakouny, Nader Jalloul, at Rima KilanyAng artikulong ito ay nagbibigay ng maraming halimbawa ng XPath para sa pagsulat ng mga resilient test. XPath (MDN)Ito ay isang mahusay na lugar upang magsimula kung gusto mo ng teknikal na paliwanag na nagdedetalye kung paano gumagana ang XPath. XPath Tutorial (ZVON)Napag-alaman kong ang tutorial na ito ang pinakakapaki-pakinabang sa sarili kong pag-aaral, salamat sa maraming halimbawa at malinaw na paliwanag. XPather Nagbibigay-daan sa iyo ang interactive na tool na ito na gumana nang direkta gamit ang code.
