Front-end garapenean nahikoa denbora daramat urteetan zehar joera bat ikusteko: garatzaile gazteagoak programazioaren paradigma berri batekin lanean, horren testuinguru historikoa ulertu gabe. Zerbait ez jakitea guztiz ulergarria da, noski. Sarea oso leku handia da, gaitasun eta espezialitate asko dituena, eta ez dakigu beti ezagutzen ez duguna. Arlo honetan ikastea etengabeko bidaia bat da, behin gertatu eta amaitzen den zerbait baino. Kasua: nire taldeko norbaitek galdetu zuen ea posible ote zen jakin erabiltzaileak UI-ko fitxa jakin batetik urruntzen diren ala ez. Deskargatu aurretik JavaScript-en gertaera adierazi nuen. Baina aurretik horri aurre egin diotenek badakite hori posible dela, beste gune batzuetan gorde gabeko datuei buruzko alertak jaso dituztelako, eta horietarako deskargatu aurretik erabilera kasu arrunta da. OrrialdeaEzkutatu eta ikusgarritasunaAldatu gertaerak ere adierazi nizkion nire lankideari neurri egokian. Nola jakin nuen hori? Beste proiektu batean sortu zelako, ez hasieran JavaScript ikastean ikasi nuelako. Kontua da front-end esparru modernoak aurretik zituzten erraldoi teknologikoen sorbaldetan daudela. Garapen-praktikak abstraitzen dituzte, askotan garatzaileen esperientzia hobea izateko, eta horrek tradizionalki front-end funtsezko kontzeptuak izan zirenak ziurrenik ezagutu beharko lituzkeen ezagutza edo ukitu beharra murrizten edo ezabatzen du. Demagun CSS Object Model (CSSOM). CSS eta JavaScript-en lan egiten duen edonork CSSOM esperientzia praktikoa izatea espero dezakezu, baina ez da beti horrela izango. Lan egin nuen merkataritza elektronikoko gune baterako React proiektu bat zegoen, non une honetan aukeratutako ordainketa-hornitzailearentzat estilo-orri bat kargatu behar genuen. Arazoa zen estilo-orria orri guztietan kargatzen ari zela orrialde zehatz batean soilik behar zenean. Hau gertatzeaz arduratu zen garatzaileak ez zuen inoiz estilo-orririk kargatu dinamikoki. Berriz ere, hau guztiz ulergarria da React-ek lortu zenezakeen ikuspegi tradizionala abstraitzen duenean. CSSOM ziurrenik ez da zure eguneroko lanean behar duzun zerbait. Baina litekeena da noizbait harekin elkarreragin beharko duzula, nahiz eta kasu puntual batean. Esperientzia hauek inspiratu ninduten artikulu hau idaztera. Zure eguneroko lanean inoiz zuzenean ukituko ez dituzun web-eginbide eta teknologia asko daude. Beharbada, nahiko berria zara web garapenean eta haietaz ez dituzu ezagutzen, sakon ezagutzea eskatzen ez dizun esparru zehatz baten abstrakzioan murgilduta zaudelako, ezta batere ere. Zehazki, XMLri buruz ari naiz, gutako askok dakiguna HTML-tik guztiz desberdina ez den antzinako hizkuntza bat dela. Hau ekartzen dut azken WHATWG-ko eztabaidengatik XSLT programazio gisa ezagutzen den XML pilaren zati garrantzitsu bat arakatzaileetatik kendu behar dela iradokitzen baitute. Hau da, hain zuzen, urtetan izan dugun teknologia zaharragoa, nire taldeak zegoen CSSOM egoera bezain praktikorako erabil daitekeena. XSLTrekin lan egin al duzu aurretik? Ea teknologia zaharrago honetan asko makurtzen garen eta XML-ren testuingurutik kanpo bere ezaugarriak baliatzen garen gaur egungo mundu errealeko arazoei aurre egiteko. XPath: API Zentrala XML teknologiarik garrantzitsuena, beharbada XML ikuspegi zuzenetik kanpo erabilgarriena dena XPath da, erro-elementu bakarra duen marka-zuhaitz batean edozein nodo edo atributu aurkitzea ahalbidetzen duen kontsulta-lengoaia. XSLTarekiko maitasun pertsonala dut, baina hori ere XPath-en oinarritzen da, eta afektu pertsonala alde batera utzi behar da sailkapenaren garrantzian. XSLT kentzeko argudioak ez du XPath-i aipamenik egiten, beraz, oraindik baimenduta dagoela suposatzen dut. Hori ona da XPath teknologia multzo honetako API zentrala eta garrantzitsuena delako, batez ere XML erabilera arruntetik kanpo erabiltzeko zerbait aurkitzen saiatzean. Garrantzitsua da, izan ere, CSS hautatzaileak zure orrialdeko elementu gehienak aurkitzeko erabil daitezkeen arren, ezin dituzte guztiak aurkitu. Gainera, CSS hautatzaileak ezin dira erabili elementu bat aurkitzeko DOM-en uneko posizioan oinarrituta. XPath-ek. Orain, hau irakurtzen duzuenetako batzuek baliteke XPath jakitea, eta beste batzuek ez. XPath teknologiaren arlo nahiko handia da, eta ezin ditut oinarri guztiak irakatsi eta honekin egiteko gauza politak ere erakutsi horrelako artikulu bakar batean. Egia esan, saiatu nintzen artikulu hori idazten, baina Smashing Magazine argitalpenaren batez bestekoa ez da 5.000 hitzetik gorakoa. Dagoeneko baino gehiagotan nengoen2.000 hitz, oinarrizkoen erdian baino ez. Beraz, XPath-ekin gauza politak egiten hasiko naiz eta oinarrizko esteka batzuk emango dizkizut, gauza hau interesgarria iruditzen bazaizu. XPath eta CSS konbinatuz XPath-ek CSS hautatzaileek ezin dituzten gauza asko egin ditzake elementuak kontsultatzerakoan. Baina CSS hautatzaileek XPath-ek ezin dituen gauza batzuk ere egin ditzakete, hots, elementuak klasearen izenaren arabera kontsultatu.
CSS XPath .nireKlasa /*[dauka(@klasea, "nireKlasa")]
Adibide honetan, CSS-k .myClass klase-izena duten elementuak kontsultatzen ditu. Bitartean, XPath adibideak "myClass" katea duen atributu-klase bat duten elementuak galdetzen ditu. Beste era batera esanda, myClass duten elementuak hautatzen ditu edozein atribututan, .myClass klase-izena duten elementuak barne, baita katean "myClass" duten elementuak ere, adibidez .myClass2. XPath zabalagoa da zentzu horretan. Beraz, ez. Ez dut iradokitzen CSS bota eta XPath bidez elementu guztiak hautatzen hasi behar dugunik. Ez da hori kontua. Kontua da XPath-ek CSS-k ezin dituen eta oraindik oso erabilgarriak izan daitezkeen gauzak egin ditzakeela, nahiz eta arakatzailearen pilako teknologia zaharragoa den eta lehen begiratuan begi-bistakoa ez dirudien arren. Erabili ditzagun bi teknologiak elkarrekin ahal dugulako ez ezik, prozesuan XPath-i buruz zerbait ikasiko dugulako, zure pilako beste tresna bat bihurtuz, agian ezagutzen ez zenituzkeen bat beti egon dela! Arazoa da JavaScript-en document.evaluate metodoa eta JavaScript-erako CSS APIekin erabiltzen ditugun hainbat kontsulta-hautatzaile metodoak bateraezinak direla. Kontsulta-API bateragarri bat egin dut hasteko, nahiz eta, egia esan, ez dudala gogoeta handirik jarri hemen egiten ari garenetik urrun dagoenez. Hona hemen kontsulta-eraikitzaile berrerabilgarri baten lan-adibide sinple bat: Ikus Bryan Rasmussen-en Pen queryXPath [forked]. Dokumentu objektuan bi metodo gehitu ditut: queryCSSSelectors (funtsean querySelectorAll da) eta queryXPaths. Bi hauek queryResults objektu bat itzultzen dute:
{ queryType: nodoak | katea | zenbakia | boolearra, emaitzak: edozein[] // html elementuak, xml elementuak, kateak, zenbakiak, boolearrak, queryCSSSelectors: (kontsulta: katea, aldatu: boolearra) => queryResults, queryXpaths: (kontsulta: katea, aldaketa: boolearra) => QueryResults }
QueryCSSSelectors eta queryXpaths funtzioek ematen diezun kontsulta emaitzen arrayko elementuen gainean exekutatzen dute, betiere emaitzen array motako nodoak badira, noski. Bestela, queryResult bat itzuliko du matrize huts batekin eta nodo mota batekin. Emendio propietatea true gisa ezartzen bada, funtzioek beren kontsultaren emaitzak aldatuko dituzte. Ez da inola ere erabili behar produkzio-ingurunean. Modu honetan egiten ari naiz bi kontsulta-APIak batera erabiltzeak dituen ondorio desberdinak erakusteko. Adibide kontsultak Egin ditzaketen gauza indartsu batzuk eta beste ikuspegi batzuen ordez nola erabil daitezkeen erakusten duten XPath kontsulta ezberdinen adibide batzuk erakutsi nahi ditut. Lehenengo adibidea //li/text() da. Honek li elementu guztiak kontsultatzen ditu eta haien testu-nodoak itzultzen ditu. Beraz, honako HTML hau kontsultatuko bagenu:
- bat
- bi
- hiru
... hau da itzultzen dena:
{"queryType":"xpathEvaluate","results":["bat","bi","hiru"],"resultType":"katea"}
Beste era batera esanda, honako array hau lortuko dugu: ["bat","bi","hiru"]. Normalean, li elementuak eskatuko dituzu hori lortzeko, kontsulta horren emaitza array bihurtu, array mapa eta elementu bakoitzaren testu-nodoa itzuliko zenituzke. Baina hori zehatzago egin dezakegu XPath-ekin: document.queryXPaths("//li/text()").results.
Kontuan izan testu-nodo bat lortzeko modua text() erabiltzea dela, funtzio sinadura baten itxura duena, eta hala da. Elementu baten testu-nodoa itzultzen du. Gure adibidean, hiru elementu daude markazioan, bakoitzak testua duena ("bat", "bi" eta "hiru").
Ikus dezagun testu() kontsulta baten adibide bat gehiago. Demagun hau dela gure marka:
Idatz dezagun href atributuaren balioa itzultzen duen kontsulta: document.queryXPaths("//a[text() = 'Hasi saioa']/@href").results.
Hau uneko dokumentuko XPath kontsulta bat da, azken adibidean bezala, baina oraingoan "Hasi saioa" testua duen esteka baten (elementu bat) href atributua itzuliko dugu. Benetakoa itzuli daemaitza ["/login.html"] da. XPath funtzioen ikuspegi orokorra XPath-en funtzio ugari daude, eta ziurrenik ez dituzu ezagutzen. Hainbat dira, nire ustez, ezagutzea merezi dutenak, besteak beste:
hasten-with Testu bat beste testu adibide jakin batekin hasten bada, starts-with(@href, 'http:') egia itzultzen du href atributu bat http:-rekin hasten bada. contieneTestu batek beste testu-adibide jakin bat badu, contains(text(), "Smashing Magazine") egia itzultzen du testu-nodo batek "Smashing Magazine" hitzak edonon baditu. count Kontsulta batek zenbat partida dituen zenbatzen duen itzultzen du. Esate baterako, count(//*[hasi(@href, 'http:'])-k testuinguru-nodoan zenbat estekak dituzten elementuak http:-rekin hasten den testua duen href atributua duten zenbatzena ematen du. azpikatea JavaScript azpikatea bezala funtzionatzen du, katea argumentu gisa pasatzen baduzu izan ezik. Adibidez, azpikateak ("nire testua", 2, 4) "y t" ematen du. substring-before Kate baten zatia beste kate baten aurretik itzultzen du. Adibidez, substing-before("nire testua", " ") "nire" itzultzen du. Era berean, substring-before("kaixo","agur") kate huts bat itzultzen du. substring-afterKate baten zatia beste kate baten ondoren itzultzen du. Adibidez, substing-after("nire testua", " ") "testua" itzultzen du. Era berean, substring-after("kaixo","agur") kate huts bat itzultzen du. normalize-space Argumentu-katea itzultzen du zuriuneak normalizatuta dituena, hasierako eta amaierako zuriuneak kenduz eta zuriuneko karaktereen sekuentziak zuriune bakar batez ordezkatuz. not boolear bat egia itzultzen du argumentua faltsua bada, bestela faltsua. trueReturns boolearra egia. falseBoolean false itzultzen du. concatJavaScript concat-en gauza bera, ez duzu kate batean metodo gisa exekutatzen izan ezik. Horren ordez, kateatu nahi dituzun kate guztiak jartzen dituzu. string-lengthThis ez da JavaScript string-length-en berdina, baizik eta argumentu gisa ematen den katearen luzera itzultzen du. translateHonek kate bat hartzen du eta bigarren argumentua hirugarren argumentura aldatzen du. Adibidez, translate("abcdef", "abc", "XYZ") XYZdef ateratzen du.
XPath-en funtzio partikular horiez gain, JavaScript-en kontrakoekin berdin funtzionatzen duten beste hainbat funtzio daude - edo, funtsean, edozein programazio-lengoaian - seguruenik ere erabilgarriak izango zenituzkeenak, hala nola zorua, sabaia, biribila, batura eta abar. Ondorengo demoak funtzio horietako bakoitza erakusten du: Ikus Bryan Rasmussen-en Pen XPath Zenbakizko funtzioak [forked]. Kontuan izan, kateak manipulatzeko funtzio gehienek bezala, zenbakizko askok sarrera bakarra hartzen dutela. Hau da, noski, kontsultak egiteko erabili behar direlako, azken XPath adibidean bezala: //li[solairua(testua()) > 250]/@val
Erabiltzen badituzu, adibide gehienek egiten duten bezala, bidearekin bat datorren lehen nodoan exekutatzen amaituko duzu. Mota bihurtze-funtzio batzuk ere badaude ziurrenik saihestu beharko zenuke JavaScriptek dagoeneko bere mota bihurtzeko arazoak dituelako. Baina egon daitezke kate bat zenbaki batera bihurtu nahi duzunean beste zenbaki batekin egiaztatzeko. Zerbait mota ezartzen duten funtzioak boolearra, zenbakia, katea eta nodoa dira. Hauek dira XPath datu-mota garrantzitsuak. Eta imajina dezakezun bezala, funtzio horietako gehienak DOM nodoak ez diren datu-motetan erabil daitezke. Adibidez, substring-after-ek kate bat hartzen du jada azaldu dugun bezala, baina href atributu bateko katea izan daiteke. Kate bat ere izan daiteke:
const testSubstringAfter = document.queryXPaths("substring-after('kaixo mundua',' ')");
Jakina, adibide honek emaitzen array-a ["mundua"] bezala itzuliko digu. Hau ekintzan erakusteko, demo orri bat egin dut DOM nodoak ez diren gauzen aurkako funtzioak erabiliz: Ikus Bryan Rasmussen-en Pen queryXPath [forked]. Kontuan izan behar duzu itzultzeko funtzioaren alderdi harrigarria, hau da, bigarren argumentuan karaktere bat baduzu (hau da, itzuli nahi duzun karaktereen zerrenda) eta itzultzeko bat datorren karaktererik ez baduzu, karaktere hori irteeratik kenduko da. Horrela, hau:
translate('Kaixo, Nire izena Inigo Montoya da, nire aita hil duzu, prestatu hiltzeko','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
… katearen emaitzak, zuriuneak barne: [" ** ** "]
Horrek esan nahi du "a" letra izartxo batera (*) batera itzultzen ari dela, baina xede-katea emanda itzulpenik ez duten beste karaktere guztiak guztiz kendu egiten dira. Zuriunea da geratzen zaigun guztiaitzulitako “a” karaktereen artean. Berriz ere, kontsulta hau:
translate('Kaixo, Nire izena Inigo Montoya da, nire aita hil duzu, prestatu hiltzeko','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','****************************************************')")
... ez du arazorik eta honelako emaitza bat ateratzen du:
"****** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Deigarria izan daiteke JavaScript-en ez dagoela modu errazik XPath translate funtzioak egiten duena egiteko, nahiz eta erabilera kasu askotan ordezkatuAll adierazpen erregularrekin maneiatu. Erakutsi dudan planteamendu bera erabil dezakezu, baina hori ez da optimoa nahi duzun guztia kateak itzultzea bada. Ondorengo demoak XPath-en itzultzeko funtzioa biltzen du JavaScript bertsioa emateko: Ikusi Bryan Rasmussen-en Pen translate funtzioa [forked]. Non erabil dezakezu horrelako zerbait? Demagun Caesar Cipher enkriptatzea hiru lekuko desplazamenduarekin (adibidez, K.a. 48ko goi mailako enkriptatzea):
translate("Zesarrek Rubikoia zeharkatzeko asmoa du!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Sarrerako testua "Zesarrek Rubikon zeharkatzeko asmoa du!" emaitzak "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Aukera desberdinen beste adibide azkar bat emateko, kate sarrera bat hartzen duen eta testua itzultzeko itzultzeko funtzio bat erabiltzen duen metal funtzio bat egin nuen, umlautak hartzen dituzten karaktere guztiak barne. Ikusi Bryan Rasmussen-en Pen metal funtzioa [forked].
const metal = (str) => { itzuli itzuli(str, "AOUaou","ÄÖÜäöü"); }
Eta, "Motley Crue arauak, rock on dudes!" testua ematen bazaio, "Mötley Crüe rüles, röck ön düdes!" Jakina, funtzio honen parodia mota guztietako erabilerak izan ditzake. Hori bazara, orduan TVTropes artikulu honek inspirazio ugari eman behar dizu. CSS XPath-ekin erabiliz Gogoratu gure arrazoi nagusia CSS hautatzaileak XPath-ekin batera erabiltzeko: CSS-k nahiko ulertzen du klase bat zer den, eta XPath-ekin egin dezakezun onena klase-atributuaren kateen konparaketak dira. Horrek funtzionatuko du kasu gehienetan. Baina inoiz .primaryLinks eta .primaryLinks2 izeneko klaseak sortu eta .primaryLinks klasea lortzeko XPath erabiltzen ari bazenuen, demagun, norbaitek .primaryLinks klasea lortzeko egoeraren bat topatuko bazenu, ziurrenik arazoak izango dituzu. Horrelako txorakeriarik ez dagoen bitartean, ziurrenik XPath erabiliko zenuke. Baina pena ematen dit jendeak horrelako txorakeriak egiten dituen lekuetan lan egin dudala. Hona hemen CSS eta XPath batera erabiliz beste demo bat. Dokumentuaren nodoa ez den testuinguru-nodo batean XPath bat exekutatzeko kodea erabiltzen dugunean zer gertatzen den erakusten du. Ikusi Pen css eta xpath elkarrekin [forked] Bryan Rasmussen-ek. CSS kontsulta .relatedarticles a da, eta .relatedarticles klase bat esleitutako div batean bi elementu a eskuratzen ditu. Horren ondoren, hiru kontsulta "txar" daude, hau da, elementu horiek testuinguru-nodo gisa exekutatzen direnean egin nahi duguna egiten ez duten kontsultak. Esplikatu dezaket zergatik jokatzen ari diren uste baino modu ezberdinean. Aipatutako hiru galdera txarrak hauek dira:
//text(): dokumentuko testu guztia itzultzen du. //a/text(): dokumentuko esteken barneko testu guztia itzultzen du. ./a/text(): ez du emaitzarik ematen.
Emaitza hauen arrazoia zure testuingurua CSS kontsultatik itzultzen den elementu bat den arren, // dokumentu osoaren aurka doa. Hau da XPath-en indarra; CSS ezin da nodo batetik arbaso batera joan eta, ondoren, arbaso horren anai-arreba batera, eta anai-arreba horren ondorengora joan. Baina XPath-ek egin dezake. Bitartean, ./-k uneko nodoaren seme-alabei galdetzen die, non puntuak (.) uneko nodoa adierazten duen eta barra-barrak (/) nodo seme-alaba batera joatea adierazten du; atributua, elementua edo testua den bidearen hurrengo zatiak zehazten du. Baina ez dago CSS kontsultak hautatutako elementurik; beraz, kontsulta horrek ez du ezer itzultzen. Azken demo horretan hiru kontsulta on daude:
.//testua(), ./testua(), normalizatu-espazioa(./testua()).
Normalize-space kontsultak XPath funtzioaren erabilera erakusten du, baina beste kontsultetan jasotako arazo bat ere konpontzen du. HTMLa honela egituratuta dago:
Automatizatu zure ezaugarrien probak Selenium WebDriver-ekin
Kontsultak lerro-jario bat itzultzen du testu-nodoaren hasieran eta amaieran,eta normalize-space hau kentzen du. Sarrera batekin boolearra ez den beste zerbait itzultzen duen edozein XPath funtzio erabiltzea XPath-ek beste funtzio batzuei aplikatzen die. Ondorengo demoak adibide batzuk erakusten ditu: Ikusi Bryan Rasmussen-en Pen xpath funtzioen adibideak [forked]. Lehenengo adibideak kontuz ibili behar duzun arazo bat erakusten du. Zehazki, honako kodea:
document.queryXPaths ("substring-after(//a/@href,'https://')");
…kate bat itzultzen du:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Zentzuzkoa du, ezta? Funtzio hauek ez dituzte matrizeak itzultzen, kate edo zenbaki bakarrak baizik. Funtzioa edozein lekutan exekutatzen ari den emaitza anitzekin lehen emaitza soilik itzultzen du. Bigarren emaitzak benetan nahi duguna erakusten du:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Horrek bi kate dituen array bat itzultzen du:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath funtzioak JavaScript-en funtzioak bezala habia daitezke. Beraz, Smashing Magazine URL egitura ezagutzen badugu, honako hau egin genezake (txantiloi literalak erabiltzea gomendatzen da): `itzul( azpikatea( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Hau pixka bat konplexuegia bihurtzen ari da egiten dena deskribatzen duten iruzkinak behar dituen neurrian: hartu www.smashingmagazine.com/ ondorengo href atribututik URL guztia, kendu lehenengo bederatzi karaktereak, eta gero itzuli barra (/) karakterea ezerezean, amaierako barra kentzeko. Sortzen den array:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
XPath erabilera-kasu gehiago XPath-ek benetan distira egin dezake probetan. Arrazoia ez da zaila ikusten, XPath DOM-eko elementu guztiak lortzeko erabil baitaiteke, DOMeko edozein posiziotatik, CSS-k ezin duen bitartean. Ezin duzu CSS klaseak koherenteak izaten jarraituko duten eraikuntza-sistema moderno askotan, baina XPath-ekin, elementu baten testu-edukia zein den jakiteko bat-etortze sendoagoak egiteko gai gara, DOM egitura aldatzen den edozein dela ere. XPath proba erresilienteak egiteko aukera ematen duten tekniken inguruko ikerketak egin dira. Ez da ezer okerragorik probak atera eta huts egitea baino, CSS hautatzaileak jada ez duelako funtzionatzen zerbait izena aldatu edo kendu delako. XPath ere oso bikaina da bilatzaile anitzeko erauzketan. XPath-en kontsultak elementu batekin bat etortzeko modu bat baino gehiago dago. Gauza bera gertatzen da CSS-rekin. Baina XPath-en kontsultak gauzak modu zehatzago batean zula ditzakete, itzultzen dena mugatzen duena, eta aukera ematen dizu bat-etortze zehatz bat aurkitzea non hainbat bat-etortze posible izan daitezkeen. Esate baterako, XPath erabil dezakegu div baten barruan dagoen h2 elementu zehatz bat itzultzeko, anai-arreba div-a berehala jarraitzen duena, eta, aldi berean, data-testID="leader" atributua duen haur-irudi elementu bat dauka:
Ez lortu izenburu hau
Ez jaso izenburu hau ere
Lideraren irudiaren goiburua
Hau da kontsulta: document.queryXPaths(` //div[ ondorengo anai-arreba::div[1] /img[@data-testID='liderra'] ] /h2/ testua () `);
Jar dezagun demo bat dena nola elkartzen den ikusteko: Ikusi Bryan Rasmussen-en Pen Complex H2 Kontsulta [forked]. Beraz, bai. XPath erabiliz proba batean edozein elementutarako bide posible asko daude. XSLT 1.0 zaharkitua Hasieran aipatu nuen Chrome taldeak XSLT 1.0 laguntza arakatzailetik kentzeko asmoa duela. Hori garrantzitsua da XSLT 1.0-k XML-ra bideratutako programazioa erabiltzen duelako dokumentuen eraldaketarako, eta, aldi berean, XPath 1.0-n oinarritzen da, hau da, nabigatzaile gehienetan aurkitzen dena. Hori gertatzen denean, XPath-en funtsezko osagai bat galduko dugu. Baina XPath probak idazteko benetan bikaina dela kontuan hartuta, nekez ikusten dut XPath osoa laster desagertzea. Hori bai, ohartu naiz jendea kentzen denean eginbide bat interesatzen zaiola. Eta hori egia da XSLT 1.0 zaharkituta dagoen kasuan. Hacker News-en eztabaida oso bat gertatzen ari da zaharkitzearen aurkako argudioz beteta. Posta bera XSLT-rekin blog-esparru bat sortzeko adibide bikaina da. Zukzuk zeuk irakur dezakezu eztabaida, baina JavaScript nola erabil daitekeen XLST-rako kasu mota horiek kudeatzeko nola erabil daitekeen aztertzen da. Arakatzaileek SaxonJS erabili behar duten iradokizunak ere ikusi ditut, hau da, JavaScript-en Saxon XSLT, XQUERY eta XPath motorretarako ataka bat dena. Ideia interesgarria da, batez ere Saxon-JS-k zehaztapen hauen egungo bertsioa inplementatzen duelako, baina ez dago XPath edo XSLT 1.0-tik gorako bertsiorik inplementatzen duen arakatzailerik eta XQuery inplementatzen duenik. Norm Tovey-Walsh-ekin harremanetan jarri nintzen Saxonica-n, SaxonJS eta Saxon motorren beste bertsio batzuen atzean dagoen konpainia. Esan zuen: "Nabigatzaileren batek SaxonJS abiapuntu gisa hartzeko interesa izango balu XML teknologia modernoak arakatzailean integratzeko, poz-pozik egongo ginateke haiekin eztabaidatzea." - Norm Tovey-Walsh
Baina gaineratu ere: "Oso harrituko nintzateke norbaitek pentsatuko balu SaxonJS egungo forman hartu eta arakatzailearen eraikuntzan aldaketarik gabe uztea planteamendu aproposa izango litzatekeela. Arakatzaile-saltzaile batek, arakatzailea eraikitzen duelako, integrazioa "kanpotik" ahal duguna baino askoz ere maila sakonagoan hel lezake "- Norm Tovey-Walsh.
Aipatzekoa da Tovey-Walsh-en iruzkinak XSLT zaharkitzearen iragarpena baino astebete lehenago iritsi zirela. Ondorioa Gero eta aurrera egin nezake. Baina espero dut honek XPath-en boterea frogatu izana eta gauza handiak lortzeko nola erabili erakusten duten adibide ugari ematea. Gaur egun oraindik erabilgarritasun handia duen arakatzailearen pilako teknologia zaharraren adibide ezin hobea da, nahiz eta inoiz existitzen zenik jakin edo inoiz horretara iristea pentsatu ez baduzu. Irakurketa gehiago
"Enhancing the Resiliency of Automated Web Tests with Natural Language" (ACM Digital Library) Maroun Ayli, Youssef Bakouny, Nader Jalloul eta Rima Kilany-k Artikulu honek XPath-en adibide ugari eskaintzen ditu proba erresilienteak idazteko. XPath (MDN)Hasteko leku bikaina da XPath-ek nola funtzionatzen duen zehazten duen azalpen tekniko bat nahi baduzu. XPath Tutoriala (ZVON)Tutorial hau nire ikaskuntzarako lagungarriena iruditu zait, adibide ugariri eta azalpen argiei esker. XPatherThis tresna interaktibo honek zuzenean kodearekin lan egiteko aukera ematen dizu.
