Unë kam qenë në zhvillimin e nivelit të parë mjaftueshëm për të parë një prirje ndër vite: zhvillues më të rinj që punojnë me një paradigmë të re programimi pa e kuptuar kontekstin historik të tij. Sigurisht, është krejtësisht e kuptueshme të mos dish diçka. Rrjeti është një vend shumë i madh me një grup të larmishëm aftësish dhe specialitetesh, dhe ne nuk dimë gjithmonë atë që nuk dimë. Të mësuarit në këtë fushë është një udhëtim i vazhdueshëm sesa diçka që ndodh një herë dhe përfundon. Rasti kryesor: Dikush në ekipin tim më pyeti nëse ishte e mundur të dallohej nëse përdoruesit largohen nga një skedë e veçantë në ndërfaqen e përdoruesit. Unë vura në dukje ngjarjen e JavaScript para shkarkimit. Por ata që e kanë trajtuar këtë më parë e dinë se kjo është e mundur sepse janë goditur me sinjalizime për të dhëna të paruajtura në sajte të tjera, për të cilat para shkarkimit është një rast tipik përdorimi. Unë gjithashtu vura në dukje ngjarjet e faqes Hide and visibilityChange për kolegun tim për një masë të mirë. Si e dija për këtë? Sepse doli në një projekt tjetër, jo sepse e studiova kur mësova fillimisht JavaScript. Fakti është se kornizat moderne të pjesës së përparme po qëndrojnë mbi supet e gjigantëve të teknologjisë që i paraprinë. Ato abstraktojnë praktikat e zhvillimit, shpesh për një përvojë më të mirë zhvilluesi që redukton, apo edhe eliminon nevojën për të njohur ose prekur ato që kanë qenë tradicionalisht koncepte thelbësore të pjesës së përparme që të gjithë ndoshta duhet të dinë. Merrni parasysh modelin e objektit CSS (CSSOM). Ju mund të prisni që kushdo që punon në CSS dhe JavaScript të ketë një mori përvojë praktike CSSOM, por kjo nuk do të jetë gjithmonë kështu. Kishte një projekt React për një sajt të tregtisë elektronike ku punova, ku duhej të ngarkonim një fletë stili për ofruesin e përzgjedhur aktualisht të pagesave. Problemi ishte se fleta e stilit po ngarkohej në çdo faqe kur ishte vërtet e nevojshme vetëm në një faqe specifike. Zhvilluesi i ngarkuar për ta bërë këtë të ndodhë nuk kishte ngarkuar ndonjëherë një fletë stili në mënyrë dinamike. Përsëri, kjo është plotësisht e kuptueshme kur React heq qasjen tradicionale që mund të keni arritur. CSSOM ka të ngjarë të mos jetë diçka që ju nevojitet në punën tuaj të përditshme. Por ka të ngjarë që do t'ju duhet të ndërveproni me të në një moment, madje edhe në një rast të vetëm. Këto përvoja më frymëzuan për të shkruar këtë artikull. Ka shumë veçori dhe teknologji ekzistuese të internetit në natyrë që nuk mund t'i prekni kurrë drejtpërdrejt në punën tuaj të përditshme. Ndoshta ju jeni mjaft i ri në zhvillimin e uebit dhe thjesht nuk jeni në dijeni të tyre sepse jeni të zhytur në abstraksionin e një kornize specifike që nuk kërkon që ju ta njihni atë thellë, apo edhe fare. Unë po flas në mënyrë specifike për XML, të cilën shumë prej nesh e dinë se është një gjuhë e lashtë jo krejtësisht e ndryshme nga HTML. Po e sjell këtë për shkak të diskutimeve të fundit të WHATWG që sugjerojnë që një pjesë e konsiderueshme e pirgut XML të njohur si programimi XSLT duhet të hiqet nga shfletuesit. Ky është pikërisht lloji i teknologjisë më të vjetër ekzistuese që kemi pasur prej vitesh që mund të përdoret për diçka aq praktike sa situata CSSOM në të cilën ndodhej ekipi im. A keni punuar më parë me XSLT? Le të shohim nëse mbështetemi shumë në këtë teknologji të vjetër dhe shfrytëzojmë veçoritë e saj jashtë kontekstit të XML për të trajtuar problemet e botës reale sot. XPath: API Qendrore Teknologjia më e rëndësishme XML që është ndoshta më e dobishme jashtë një perspektive të drejtpërdrejtë XML është XPath, një gjuhë pyetëse që ju lejon të gjeni çdo nyje ose atribut në një pemë shënjimi me një element rrënjë. Unë kam një dashuri personale për XSLT, por kjo gjithashtu mbështetet në XPath, dhe dashuria personale duhet të lihet mënjanë në rëndësinë e renditjes. Argumenti për heqjen e XSLT nuk përmend XPath, kështu që supozoj se është ende i lejuar. Kjo është mirë sepse XPath është API qendrore dhe më e rëndësishme në këtë grup teknologjish, veçanërisht kur përpiqeni të gjeni diçka për t'u përdorur jashtë përdorimit normal të XML. Është e rëndësishme sepse, ndërsa përzgjedhësit CSS mund të përdoren për të gjetur shumicën e elementeve në faqen tuaj, ata nuk mund t'i gjejnë të gjithë. Për më tepër, përzgjedhësit CSS nuk mund të përdoren për të gjetur një element bazuar në pozicionin e tij aktual në DOM. XPath mund. Tani, disa prej jush që e lexojnë këtë mund të njohin XPath, dhe disa mund të mos e njohin. XPath është një fushë mjaft e madhe e teknologjisë dhe nuk mund t'i mësoj të gjitha bazat dhe gjithashtu t'ju tregoj gjëra interesante për të bërë me të në një artikull të vetëm si ky. Unë në fakt u përpoqa ta shkruaj atë artikull, por mesatarja e botimit të Revistës Smashing nuk kalon më shumë se 5000 fjalë. Unë isha tashmë në më shumë se2000 fjalë ndërsa vetëm në gjysmë të rrugës bazë. Pra, unë do të filloj të bëj gjëra interesante me XPath dhe do t'ju jap disa lidhje që mund t'i përdorni për bazat nëse ju duken interesante këto gjëra. Kombinimi i XPath dhe CSS XPath mund të bëjë shumë gjëra që përzgjedhësit CSS nuk mund t'i bëjnë kur kërkojnë elementë. Por përzgjedhësit CSS mund të bëjnë gjithashtu disa gjëra që XPath nuk mund t'i bëjë, domethënë, të kërkojë elementë sipas emrit të klasës.
CSS XPath .myClass /*[përmban(@class, "myClass")]
Në këtë shembull, CSS kërkon elemente që përmbajnë një emër klase .myClass. Ndërkohë, shembulli XPath kërkon elementë që përmbajnë një klasë atribute me vargun "myClass". Me fjalë të tjera, ai zgjedh elemente me myClass në çdo atribut, duke përfshirë elementë me emrin e klasës .myClass — si dhe elementë me "myClass" në varg, si p.sh. .myClass2. XPath është më i gjerë në këtë kuptim. Pra, jo. Unë nuk po sugjeroj që ne duhet të hedhim CSS dhe të fillojmë të zgjedhim të gjithë elementët përmes XPath. Kjo nuk është çështja. Çështja është se XPath mund të bëjë gjëra që CSS nuk mund dhe ende mund të jetë shumë e dobishme, edhe pse është një teknologji më e vjetër në grupin e shfletuesit dhe mund të mos duket e qartë në shikim të parë. Le t'i përdorim të dy teknologjitë së bashku jo vetëm sepse mundemi, por sepse do të mësojmë diçka rreth XPath në proces, duke e bërë atë një mjet tjetër në pirgun tuaj – një që mund të mos e keni ditur se ka qenë atje gjatë gjithë kohës! Problemi është se metoda document.evaluate e JavaScript dhe metodat e ndryshme të përzgjedhjes së pyetjeve që përdorim me API-të CSS për JavaScript janë të papajtueshme. Unë kam bërë një API të pajtueshme kërkimi për të na bërë të fillojmë, megjithëse pa dyshim, nuk kam menduar shumë për të pasi është një largim nga ajo që po bëjmë këtu. Këtu është një shembull mjaft i thjeshtë pune i një konstruktori të pyetjeve të ripërdorshme: Shih pyetjen e penës XPath [forked] nga Bryan Rasmussen. Unë kam shtuar dy metoda në objektin e dokumentit: queryCSSSelectors (që në thelb është querySelectorAll) dhe queryXPaths. Të dyja këto kthejnë një objekt queryResults:
{ lloji i pyetjes: nyjet | varg | numri | boolean, rezultatet: çdo[] // elemente html, elemente xml, vargje, numra, booleans, queryCSSS zgjedhësit: (pyetje: varg, amend: boolean) => queryRezultat, queryXpaths: (query: string, amend: boolean) => queryResults }
Funksionet queryCSSSelectors dhe queryXpaths drejtojnë pyetjen që ju u jepni atyre mbi elementët në grupin e rezultateve, për sa kohë që grupi i rezultateve është i llojit të nyjeve, natyrisht. Përndryshe, ai do të kthejë një queryResult me një grup bosh dhe një lloj nyjesh. Nëse vetia amend vendoset në true, funksionet do të ndryshojnë rezultatet e tyre të pyetjes. Në asnjë rrethanë nuk duhet të përdoret në një mjedis prodhimi. Unë po e bëj në këtë mënyrë thjesht për të demonstruar efektet e ndryshme të përdorimit të dy API-ve të pyetjeve së bashku. Shembuj të pyetjeve Unë dua të tregoj disa shembuj të pyetjeve të ndryshme XPath që demonstrojnë disa nga gjërat e fuqishme që mund të bëjnë dhe se si mund të përdoren në vend të qasjeve të tjera. Shembulli i parë është //li/text(). Kjo kërkon të gjithë elementët li dhe kthen nyjet e tyre të tekstit. Pra, nëse do të pyesnim HTML-në e mëposhtme:
- një
- dy
- tre
...kjo është ajo që është kthyer:
{"queryType":"xpathEvaluate","rezultatet":["një","dy","tre"],"resultType":"string"}
Me fjalë të tjera, marrim grupin e mëposhtëm: ["një", "dy", "tre"]. Normalisht, ju do të kërkoni që elementët li ta marrin atë, ta ktheni rezultatin e atij pyetësori në një grup, të hartoni grupin dhe të ktheni nyjen e tekstit të secilit element. Por ne mund ta bëjmë këtë në mënyrë më koncize me XPath: dokument.queryXPaths("//li/text()").rezultatet.
Vini re se mënyra për të marrë një nyje teksti është përdorimi i tekstit (), i cili duket si një nënshkrim funksioni - dhe është. Ai kthen nyjen e tekstit të një elementi. Në shembullin tonë, ka tre elementë li në shënim, secili përmban tekst ("një", "dy" dhe "tre").
Le të shohim një shembull tjetër të një pyetjeje teksti (). Supozoni se kjo është shënimi ynë:
Le të shkruajmë një pyetje që kthen vlerën e atributit href: document.queryXPaths("//a[text() = 'Identifikohu']/@href").rezultatet.
Ky është një pyetje XPath në dokumentin aktual, ashtu si shembulli i fundit, por këtë herë ne kthejmë atributin href të një lidhjeje (një elementi) që përmban tekstin "Identifikohu". E vërteta u kthyerezultati është ["/login.html"]. Përmbledhje e funksioneve të XPath Ka një sërë funksionesh XPath dhe ndoshta nuk jeni të njohur me to. Mendoj se ka disa që ia vlen të dihen, duke përfshirë sa vijon:
starts-withNëse një tekst fillon me një shembull tjetër teksti të caktuar, starts-with(@href, 'http:') kthehet true nëse një atribut href fillon me http:. përmbanNëse një tekst përmban një shembull tjetër teksti të veçantë, përmban(tekst(), "Revista Smashing") kthehet e vërtetë nëse një nyje teksti përmban fjalët "Revista Smashing" në të kudo. countKthen një numërim se sa ndeshje ka një pyetje. Për shembull, count(//*[starts-with(@href, 'http:']) kthen një numër se sa lidhje në nyjen e kontekstit kanë elementë me një atribut href që përmban tekstin që fillon me http:. substringPunon si nënvarg JavaScript, përveçse ju e kaloni vargun si argument. Për shembull, substring("teksti im", 2, 4) kthen "y t". substring-beforeKthen pjesën e një vargu përpara një vargu tjetër. Për shembull, substing-before("teksti im", " ") kthen "my". Në mënyrë të ngjashme, substring-before("hi","bye") kthen një varg bosh. substring-afterKthen pjesën e një vargu pas një vargu tjetër. Për shembull, substing-after("teksti im", " ") kthen "tekst". Në mënyrë të ngjashme, substring-after("hi","bye") kthen një varg bosh. normalize-spaceKthen vargun e argumentit me hapësirë të bardhë të normalizuar duke hequr hapësirën e bardhë kryesore dhe pasuese dhe duke zëvendësuar sekuencat e karaktereve të hapësirës së bardhë me një hapësirë të vetme. nukKthen një të vërtetë boolean nëse argumenti është false, përndryshe false. trueKthen boolean true. falseKthen false boolean. concatE njëjta gjë si JavaScript concat, vetëm se nuk e ekzekutoni si metodë në një varg. Në vend të kësaj, ju vendosni të gjitha vargjet që dëshironi të bashkoni. string-lengthKjo nuk është e njëjtë me gjatësinë e vargut të JavaScript, por më tepër kthen gjatësinë e vargut që është dhënë si argument. translateThis merr një varg dhe ndryshon argumentin e dytë në argumentin e tretë. Për shembull, translate ("abcdef", "abc", "XYZ") nxjerr XYZdef.
Përveç këtyre funksioneve të veçanta të XPath, ka një sërë funksionesh të tjera që funksionojnë njësoj si homologët e tyre JavaScript - ose homologët në thelb në çdo gjuhë programimi - që ndoshta do t'i gjeni të dobishme, si dyshemeja, tavani, rrumbullakët, shuma, etj. Demoja e mëposhtme ilustron secilin nga këto funksione: Shihni funksionet numerike të Pen XPath [të forcuara] nga Bryan Rasmussen. Vini re se, si shumica e funksioneve të manipulimit të vargut, shumë nga ato numerike marrin një hyrje të vetme. Kjo, natyrisht, sepse ato supozohet të përdoren për pyetje, si në shembullin e fundit XPath: //li[kat(tekst()) > 250]/@val
Nëse i përdorni, siç bëjnë shumica e shembujve, do të përfundoni duke e ekzekutuar në nyjen e parë që përputhet me shtegun. Ekzistojnë gjithashtu disa funksione të konvertimit të tipit që ndoshta duhet t'i shmangni sepse JavaScript tashmë ka problemet e veta të konvertimit të tipit. Por mund të ketë raste kur dëshironi të konvertoni një varg në një numër në mënyrë që ta kontrolloni atë kundrejt ndonjë numri tjetër. Funksionet që përcaktojnë llojin e diçkaje janë boolean, numri, vargu dhe nyja. Këto janë llojet e rëndësishme të të dhënave XPath. Dhe siç mund ta imagjinoni, shumica e këtyre funksioneve mund të përdoren në tipe të dhënash që nuk janë nyje DOM. Për shembull, substring-after merr një varg siç e kemi mbuluar tashmë, por mund të jetë vargu nga një atribut href. Mund të jetë gjithashtu thjesht një varg:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Natyrisht, ky shembull do të na kthejë grupin e rezultateve si ["botë"]. Për ta treguar këtë në veprim, unë kam krijuar një faqe demo duke përdorur funksione kundër gjërave që nuk janë nyje DOM: Shih pyetjen e penës XPath [forked] nga Bryan Rasmussen. Duhet të vini re aspektin befasues të funksionit të përkthimit, që është se nëse keni një karakter në argumentin e dytë (d.m.th., listën e karaktereve që dëshironi të përkthehen) dhe asnjë karakter që përkthehet, ai karakter hiqet nga dalja. Kështu, kjo:
përkthe ('Përshëndetje, emri im është Inigo Montoya, ju vratë babanë tim, përgatituni të vdisni','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…rezultatet në varg, duke përfshirë hapësirat: [" * * ** "]
Kjo do të thotë që shkronja "a" po përkthehet në një yll (*), por çdo karakter tjetër që nuk ka një përkthim të dhënë në vargun e synuar hiqet plotësisht. Hapësira e bardhë është gjithçka që na ka mbeturndërmjet personazheve të përkthyer “a”. Pastaj përsëri, kjo pyetje:
përktheni ('Përshëndetje, emri im është Inigo Montoya, ju vratë babanë tim, përgatituni të vdisni','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','***************************************************')")
…nuk e ka problemin dhe nxjerr një rezultat që duket si ky:
"******** ** **** ** ***** ******* *** ***** ** ***** ******** ** ***"
Mund të të duket se nuk ka asnjë mënyrë të lehtë në JavaScript për të bërë pikërisht atë që funksioni i përkthimit të XPath bën, megjithëse për shumë raste përdorimi, zëvendësimi i të gjitha me shprehje të rregullta mund ta trajtojë atë. Ju mund të përdorni të njëjtën qasje që kam demonstruar, por kjo është jooptimale nëse gjithçka që dëshironi është të përktheni vargjet. Demoja e mëposhtme përfundon funksionin e përkthimit të XPath për të siguruar një version JavaScript: Shihni funksionin e përkthimit të stilolapsit [forked] nga Bryan Rasmussen. Ku mund të përdorni diçka të tillë? Konsideroni enkriptimin e Caesar Cipher me një zhvendosje me tre vende (p.sh., kriptimi më i lartë nga viti 48 p.e.s.):
përktheni ("Cezari po planifikon të kalojë Rubikonin!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Teksti hyrës "Cezari po planifikon të kalojë Rubikonin!" rezulton në "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Për të dhënë një shembull tjetër të shpejtë të mundësive të ndryshme, bëra një funksion metalik që merr një hyrje të vargut dhe përdor një funksion përkthimi për të kthyer tekstin, duke përfshirë të gjithë karakteret që marrin umlaut. Shihni funksionin metalik të stilolapsit [të pirun] nga Bryan Rasmussen.
konst metal = (rr) => { kthimi i përkthimit (rr, "AOUaou", "ÄÖÜäöü"); }
Dhe, nëse jepet teksti "Motley Crue rules, rock on dudes!", kthen "Mötley Crüe rüles, röck ön düdes!" Natyrisht, dikush mund të ketë të gjitha llojet e përdorimeve parodi të këtij funksioni. Nëse jeni ju, atëherë ky artikull i TVTropes duhet t'ju ofrojë shumë frymëzim. Përdorimi i CSS me XPath Mos harroni arsyen tonë kryesore për përdorimin e përzgjedhësve CSS së bashku me XPath: CSS e kupton shumë mirë se çfarë është një klasë, ndërsa më e mira që mund të bëni me XPath është krahasimi i vargjeve të atributit të klasës. Kjo do të funksionojë në shumicën e rasteve. Por nëse do të hasnit ndonjëherë në një situatë ku, të themi, dikush krijoi klasa të quajtura .primaryLinks dhe .primaryLinks2 dhe ju po përdorni XPath për të marrë klasën .primaryLinks, atëherë ka të ngjarë të hasni probleme. Për sa kohë që nuk ka asgjë të trashë si kjo, ju me siguri do të përdorni XPath. Por jam i trishtuar të raportoj se kam punuar në vende ku njerëzit bëjnë ato lloj gjërash marrëzi. Këtu është një tjetër demo duke përdorur CSS dhe XPath së bashku. Tregon se çfarë ndodh kur përdorim kodin për të ekzekutuar një XPath në një nyje konteksti që nuk është nyja e dokumentit. Shih stilolapsin css dhe xpath së bashku [të forcuar] nga Bryan Rasmussen. Pyetja CSS është .relatedarticles a, e cila merr dy elementët a në një div të caktuar një klasë .relatedarticles. Pas kësaj janë tre pyetje "të këqija", domethënë pyetje që nuk bëjnë atë që duam të bëjnë kur ekzekutohen me këta elementë si nyja e kontekstit. Unë mund të shpjegoj pse ata po sillen ndryshe nga sa mund të prisni. Tre pyetjet e këqija në fjalë janë:
//text(): Kthen të gjithë tekstin në dokument. //a/text(): Kthen të gjithë tekstin brenda lidhjeve në dokument. ./a/text(): Nuk kthen asnjë rezultat.
Arsyeja për këto rezultate është se ndërsa konteksti juaj është një element i kthyer nga pyetja CSS, // shkon kundër të gjithë dokumentit. Kjo është forca e XPath; CSS nuk mund të shkojë nga një nyje deri te një paraardhës dhe më pas te një vëlla ose motër e atij paraardhësi, dhe të ecë deri te një pasardhës i atij vëllai. Por XPath mundet. Ndërkohë, ./ pyet fëmijët e nyjes aktuale, ku pika (.) përfaqëson nyjen aktuale, dhe prerja përpara (/) përfaqëson shkuarjen në një nyje fëmijësh - nëse është një atribut, element ose tekst, përcaktohet nga pjesa tjetër e shtegut. Por nuk ka asnjë element të zgjedhur nga pyetësori CSS, kështu që ai pyetje gjithashtu nuk kthen asgjë. Ka tre pyetje të mira në atë demonstrim të fundit:
.//text(), ./text(), normalize-space(./text()).
Pyetja e hapësirës së normalizimit demonstron përdorimin e funksionit XPath, por gjithashtu rregullon një problem të përfshirë në pyetjet e tjera. HTML është strukturuar kështu:
Automatizimi i testimit të veçorive tuaja me Selenium WebDriver
Pyetja kthen një furnizim rreshti në fillim dhe në fund të nyjës së tekstit,dhe normalize-space e heq këtë. Përdorimi i çdo funksioni XPath që kthen diçka tjetër përveç një boolean me një hyrje XPath zbatohet për funksione të tjera. Demoja e mëposhtme tregon një numër shembujsh: Shihni shembujt e funksioneve Pen xpath [të forcuara] nga Bryan Rasmussen. Shembulli i parë tregon një problem për të cilin duhet të keni kujdes. Konkretisht, kodi i mëposhtëm:
document.queryXPaths("substring-after(//a/@href,'https://')");
…kthehet një varg:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Ka kuptim, apo jo? Këto funksione nuk kthejnë vargje, por më tepër vargje të vetme ose numra të vetëm. Ekzekutimi i funksionit kudo me rezultate të shumta kthen vetëm rezultatin e parë. Rezultati i dytë tregon atë që ne vërtet duam:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
E cila kthen një grup prej dy vargjesh:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Funksionet e XPath mund të vendosen njësoj si funksionet në JavaScript. Pra, nëse e dimë strukturën e URL-së së Revistës Smashing, mund të bëjmë sa më poshtë (rekomandohet përdorimi i fjalëpërfjalëve të shabllonit): `përkthe( nënstring ( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Kjo po bëhet paksa shumë e ndërlikuar në masën që ka nevojë për komente që përshkruajnë atë që bën: merrni të gjithë URL-në nga atributi href pas www.smashingmagazine.com/, hiqni nëntë karakteret e para, më pas përktheni karakterin e pjerrët përpara (/) në asgjë, në mënyrë që të heqni qafe vijën fundore përpara. Vargu që rezulton:
["feature-testing-selenium-webdriver", "automated-test-results-improve-accessibility"]
Më shumë raste përdorimi të XPath XPath mund të shkëlqejë vërtet në testim. Arsyeja nuk është e vështirë të shihet, pasi XPath mund të përdoret për të marrë çdo element në DOM, nga çdo pozicion në DOM, ndërsa CSS jo. Nuk mund të mbështeteni që klasat CSS të mbeten të qëndrueshme në shumë sisteme ndërtimi moderne, por me XPath, ne jemi në gjendje të bëjmë përputhje më të fuqishme se çfarë është përmbajtja e tekstit të një elementi, pavarësisht nga një strukturë DOM që ndryshon. Ka pasur kërkime mbi teknikat që ju lejojnë të bëni teste elastike XPath. Asgjë nuk është më e keqe se sa testet të dështojnë dhe të dështojnë vetëm sepse një përzgjedhës CSS nuk funksionon më sepse diçka është riemërtuar ose hequr. XPath është gjithashtu vërtet i shkëlqyeshëm në nxjerrjen e shumëfishtë të vendndodhjes. Ka më shumë se një mënyrë për të përdorur pyetjet XPath për të përputhur një element. E njëjta gjë është e vërtetë me CSS. Por pyetjet e XPath mund të gërmojnë gjërat në një mënyrë më të synuar që kufizon atë që kthehet, duke ju lejuar të gjeni një përputhje specifike ku mund të ketë disa përputhje të mundshme. Për shembull, ne mund të përdorim XPath për të kthyer një element specifik h2 që përmbahet brenda një div që menjëherë pason një div vëlla ose vëlla që, nga ana tjetër, përmban një element imazhi fëmijë me një atribut data-testID="lider" në të:
mos e merrni këtë titull
Mos e merrni as këtë titull
Titulli i imazhit të liderit
Ky është pyetja: document.queryXPaths(` //div[ follow-mother::div[1] /img[@data-testID='lider'] ] /h2/ teksti () `);
Le të hedhim një demo për të parë se si bashkohen të gjitha këto: Shikoni Pyetjen e Kompleksit të Penave H2 [përbërë] nga Bryan Rasmussen. Pra, po. Ka shumë shtigje të mundshme për çdo element në një test duke përdorur XPath. Zhvlerësimi i XSLT 1.0 E përmenda herët se ekipi i Chrome planifikon të heqë mbështetjen e XSLT 1.0 nga shfletuesi. Kjo është e rëndësishme sepse XSLT 1.0 përdor programim të fokusuar në XML për transformimin e dokumenteve që, nga ana tjetër, mbështetet në XPath 1.0, që është ajo që gjendet në shumicën e shfletuesve. Kur kjo të ndodhë, ne do të humbasim një komponent kyç të XPath. Por duke pasur parasysh faktin që XPath është vërtet i shkëlqyeshëm për të shkruar teste, nuk ka gjasa që XPath në tërësi të zhduket së shpejti. Thënë kështu, kam vënë re se njerëzit interesohen për një veçori kur të hiqet. Dhe kjo sigurisht që është e vërtetë në rastin kur XSLT 1.0 është zhvlerësuar. Një diskutim i tërë po ndodh në Hacker News, i mbushur me argumente kundër zhvlerësimit. Vetë postimi është një shembull i shkëlqyeshëm i krijimit të një kuadri blogimi me XSLT. Jumund ta lexoni vetë diskutimin, por hyn në mënyrën se si JavaScript mund të përdoret si një mashtrim për XLST për të trajtuar ato lloj rastesh. Kam parë gjithashtu sugjerime që shfletuesit duhet të përdorin SaxonJS, i cili është një port për motorët Saxon XSLT, XQUERY dhe XPath të JavaScript. Kjo është një ide interesante, veçanërisht pasi Saxon-JS zbaton versionin aktual të këtyre specifikimeve, ndërsa nuk ka asnjë shfletues që zbaton ndonjë version të XPath ose XSLT përtej 1.0, dhe asnjë që zbaton XQuery. Unë kontaktova me Norm Tovey-Walsh në Saxonica, kompania që qëndron pas SaxonJS dhe versione të tjera të motorit Saxon. Ai tha: "Nëse ndonjë shitës shfletuesi ishte i interesuar të merrte SaxonJS si një pikënisje për integrimin e teknologjive moderne XML në shfletues, do të ishim të kënaqur ta diskutonim me ta." - Norm Tovey-Walsh
Por gjithashtu shtoi: "Do të isha shumë i befasuar nëse dikush do të mendonte se marrja e SaxonJS në formën e tij aktuale dhe hedhja e tij në ndërtimin e shfletuesit të pandryshuar do të ishte qasja ideale. Një shitës shfletuesi, për nga natyra e faktit që ata ndërtojnë shfletuesin, mund t'i qasen integrimit në një nivel shumë më të thellë sesa ne mundemi "nga jashtë"." - Norm Tovey-Walsh
Vlen të përmendet se komentet e Tovey-Walsh erdhën rreth një javë përpara shpalljes së zhvlerësimit të XSLT. konkluzioni Mund të vazhdoja dhe të vazhdoja. Por shpresoj se kjo ka treguar fuqinë e XPath dhe ju ka dhënë shumë shembuj që tregojnë se si ta përdorni atë për të arritur gjëra të mëdha. Është një shembull i përsosur i teknologjisë së vjetër në grupin e shfletuesit që ka ende shumë dobi sot, edhe nëse nuk e keni ditur kurrë se ekzistonte ose nuk e keni menduar kurrë ta arrini atë. Lexim i mëtejshëm
"Përmirësimi i qëndrueshmërisë së testeve të automatizuara të uebit me gjuhë natyrale" (Biblioteka dixhitale ACM) nga Maroun Ayli, Youssef Bakouny, Nader Jalloul dhe Rima KilanyKy artikull ofron shumë shembuj XPath për të shkruar teste elastike. XPath (MDN) Ky është një vend i shkëlqyeshëm për të filluar nëse dëshironi një shpjegim teknik që detajon se si funksionon XPath. XPath Tutorial (ZVON) Unë e kam parë këtë tutorial si më të dobishëm në mësimin tim, falë një morie shembujsh dhe shpjegimesh të qarta. XPatherKy mjet ndërveprues ju lejon të punoni drejtpërdrejt me kodin.
