Mi estis en antaŭa evoluado sufiĉe longe por vidi tendencon tra la jaroj: pli junaj programistoj laborantaj kun nova paradigmo de programado sen kompreni la historian kuntekston de ĝi. Kompreneble estas tute komprenebla ne scii ion. La reto estas tre granda loko kun diversa aro da kapabloj kaj specialaĵoj, kaj ni ne ĉiam scias tion, kion ni ne scias. Lernado en ĉi tiu kampo estas daŭra vojaĝo prefere ol io, kio okazas unufoje kaj finiĝas. Kazo: Iu en mia teamo demandis ĉu eblas diri ĉu uzantoj navigas for de aparta langeto en la UI. Mi atentigis la eventon antaŭ malŝarĝo de JavaScript. Sed tiuj, kiuj antaŭe traktis tion, scias, ke tio eblas ĉar ili estis trafitaj per atentigoj pri nekonservitaj datumoj sur aliaj retejoj, por kiuj antaŭ malŝarĝo estas tipa uzkazo. Mi ankaŭ atentigis la paĝon Kaŝi kaj videblecon Ŝanĝi eventojn al mia kolego por bona mezuro. Kiel mi sciis pri tio? Ĉar ĝi aperis en alia projekto, ne ĉar mi studis pri ĝi komence lernante JavaScript. La fakto estas, ke modernaj antaŭfinaj kadroj staras sur la ŝultroj de la teknologiaj gigantoj, kiuj antaŭis ilin. Ili abstraktas disvolvajn praktikojn, ofte por pli bona ellaboranta sperto, kiu reduktas, aŭ eĉ forigas, la bezonon scii aŭ tuŝi tion, kio tradicie estis esencaj antaŭfinaj konceptoj, ĉiuj verŝajne devus scii. Konsideru la CSS Objektan Modelon (CSSOM). Vi eble atendas, ke iu ajn laboranta en CSS kaj JavaScript havas multajn praktikajn spertojn pri CSSOM, sed tio ne ĉiam okazos. Estis React-projekto por retkomerca retejo, pri kiu mi laboris, kie ni bezonis ŝargi stilfolion por la nuntempe elektita pagprovizanto. La problemo estis, ke la stilfolio ŝargis sur ĉiu paĝo, kiam ĝi estis vere bezonata en specifa paĝo. La programisto taskita fari ĉi tion ne iam ŝarĝis stilfolion dinamike. Denove, ĉi tio estas plene komprenebla kiam React abstraktas la tradician aliron, kiun vi eble atingis. La CSSOM verŝajne ne estas io, kion vi bezonas en via ĉiutaga laboro. Sed verŝajne vi devos interagi kun ĝi iam, eĉ en unufoja okazo. Ĉi tiuj spertoj inspiris min skribi ĉi tiun artikolon. Estas multaj ekzistantaj retaj funkcioj kaj teknologioj en la naturo, kiujn vi eble neniam tuŝas rekte en via ĉiutaga laboro. Eble vi estas sufiĉe nova pri TTT-disvolviĝo kaj simple ne konscias pri ili ĉar vi estas trempita en la abstraktado de specifa kadro, kiu ne postulas, ke vi konu ĝin profunde, aŭ eĉ entute. Mi parolas specife pri XML, kiun multaj el ni scias, ke estas antikva lingvo ne tute malsimila al HTML. Mi alportas ĉi tion pro lastatempaj WHATWG-diskutoj sugestante, ke grava parto de la XML-stako konata kiel XSLT-programado devus esti forigita de retumiloj. Ĉi tio estas ĝuste la speco de pli malnova, ekzistanta teknologio, kiun ni havis dum jaroj, kiu povus esti uzata por io tiel praktika kiel la CSSOM-situacio en kiu mia teamo estis. Ĉu vi antaŭe laboris kun XSLT? Ni vidu ĉu ni multe klinas sin al ĉi tiu pli malnova teknologio kaj utiligas ĝiajn funkciojn ekster la kunteksto de XML por trakti realajn problemojn hodiaŭ. XPath: La Centra API La plej grava XML-teknologio, kiu eble estas la plej utila ekster rekta XML-perspektivo, estas XPath, demandolingvo, kiu ebligas al vi trovi ajnan nodon aŭ atributon en markada arbo kun unu radika elemento. Mi havas personan korinklinon por XSLT, sed tio ankaŭ dependas de XPath, kaj persona amo devas esti flankenmetita en rangograveco. La argumento por forigi XSLT ne faras ajnan mencion pri XPath, do mi supozas, ke ĝi ankoraŭ estas permesita. Tio estas bona ĉar XPath estas la centra kaj plej grava API en ĉi tiu aro de teknologioj, precipe kiam oni provas trovi ion por uzi ekster normala XML-uzo. Ĝi estas grava ĉar, kvankam CSS-elektiloj povas esti uzataj por trovi la plej multajn elementojn en via paĝo, ili ne povas trovi ĉiujn. Krome, CSS-elektiloj ne povas esti uzataj por trovi elementon bazitan sur ĝia nuna pozicio en la DOM. XPath povas. Nun, iuj el vi, kiuj legas ĉi tion, eble konas XPath, kaj iuj eble ne. XPath estas sufiĉe granda areo de teknologio, kaj mi ne povas vere instrui ĉiujn bazaĵojn kaj ankaŭ montri al vi bonegajn aferojn por fari kun ĝi en ununura artikolo kiel ĉi tiu. Mi fakte provis skribi tiun artikolon, sed la averaĝa publikigado de Smashing Magazine ne superas 5 000 vortojn. Mi jam estis ĉe pli ol2,000 vortoj dum nur duonvoje tra la bazaĵoj. Do, mi komencos fari bonegajn aferojn kun XPath kaj donos al vi kelkajn ligilojn, kiujn vi povas uzi por la bazaĵoj, se vi trovas ĉi tiujn aferojn interesa. Kombinante XPath kaj CSS XPath povas fari multajn aferojn, kiujn CSS-elektiloj ne povas dum pridemandado de elementoj. Sed CSS-elektiloj ankaŭ povas fari kelkajn aferojn, kiujn XPath ne povas, nome pridemandi elementojn per klasnomo.
CSS XPath .mia Klaso /*[enhavas(@klaso, "mia Klaso")]
En ĉi tiu ekzemplo, CSS demandas elementojn kiuj enhavas .myClass klasnomon. Dume, la ekzemplo XPath demandas elementojn, kiuj enhavas atributan klason kun la ĉeno "myClass". Alivorte, ĝi elektas elementojn kun myClass en iu ajn atributo, inkluzive de elementoj kun la klasnomo .myClass - same kiel elementojn kun "myClass" en la ĉeno, kiel ekzemple .myClass2. XPath estas pli larĝa tiusence. Do, ne. Mi ne sugestas, ke ni devus elĵeti CSS kaj komenci elekti ĉiujn elementojn per XPath. Tio ne estas la punkto. La punkto estas, ke XPath povas fari aferojn, kiujn CSS ne povas kaj ankoraŭ povus esti tre utila, kvankam ĝi estas pli malnova teknologio en la retumila stako kaj eble ne ŝajnas evidenta unuavide. Ni uzu la du teknologiojn kune ne nur ĉar ni povas, sed ĉar ni lernos ion pri XPath dum la procezo, farante ĝin alia ilo en via stako - unu, kiun vi eble ne sciis, estis tie la tutan tempon! La problemo estas, ke la metodo document.evaluate de JavaScript kaj la diversaj metodoj de serĉelektiloj, kiujn ni uzas kun la CSS-APIoj por JavaScript, estas malkongruaj. Mi faris kongruan demandan API por komenci nin, kvankam certe, mi ne multe pripensis ĝin ĉar ĝi estas foriro de tio, kion ni faras ĉi tie. Jen sufiĉe simpla funkcia ekzemplo de reuzebla demanda konstrukcio: Vidu la Pen queryXPath [forkigita] de Bryan Rasmussen. Mi aldonis du metodojn al la dokumentobjekto: queryCSSSelectors (kiu estas esence querySelectorAll) kaj queryXPaths. Ambaŭ resendas objekton queryResults:
{ queryType: nodoj | ŝnuro | nombro | bulea, rezultoj: ajna[] // html-elementoj, xml-elementoj, ĉenoj, nombroj, buleoj, queryCSSSelectors: (demando: ĉeno, ŝanĝu: bulea) => queryResults, queryXpaths: (demando: ĉeno, amendo: bulea) => queryResults }
La funkcioj queryCSSSelectors kaj queryXpaths ruligas la demandon, kiun vi donas al ili super la elementoj en la rezulttabelo, kondiĉe ke la rezulttabelo estas de tipo nodoj, kompreneble. Alie, ĝi resendos queryResult kun malplena tabelo kaj speco de nodoj. Se la ŝanĝa posedaĵo estas agordita al vera, la funkcioj ŝanĝos siajn proprajn queryResults. Sub neniu cirkonstanco ĉi tio estu uzata en produktadmedio. Mi faras ĝin tiel nur por montri la diversajn efikojn de uzado de la du demandaj API-oj kune. Ekzemplaj Demandoj Mi volas montri kelkajn ekzemplojn de malsamaj XPath-demandoj, kiuj montras kelkajn el la potencaj aferoj, kiujn ili povas fari kaj kiel ili povas esti uzataj anstataŭ aliaj aliroj. La unua ekzemplo estas //li/text(). Ĉi tio demandas ĉiujn li-elementojn kaj resendas iliajn tekstajn nodojn. Do, se ni demandus la jenan HTML:
- unu
- du
- tri
... jen kio estas resendita:
{"queryType":"xpathEvaluate","rezultoj":["unu","du","tri"],"resultType":"string"}
Alivorte, ni ricevas la sekvan tabelon: ["unu","du","tri"]. Kutime, vi demandus la li-elementojn por ricevi tion, turnus la rezulton de tiu demando en tabelon, mapi la tabelon kaj resendus la tekstan nodon de ĉiu elemento. Sed ni povas fari tion pli koncize kun XPath: document.queryXPaths("//li/text()").rezultoj.
Rimarku, ke la maniero akiri tekstan nodon estas uzi text(), kiu aspektas kiel funkciosignaturo — kaj ĝi estas. Ĝi resendas la tekstan nodon de elemento. En nia ekzemplo, estas tri li-elementoj en la markado, ĉiu enhavanta tekston ("unu", "du", kaj "tri").
Ni rigardu unu plian ekzemplon de text() demando. Supozu, ke ĉi tio estas nia markado:
Ni skribu demandon, kiu resendas la atributan valoron href: document.queryXPaths("//a[text() = 'Ensalutu']/@href").rezultoj.
Ĉi tio estas XPath-demando sur la nuna dokumento, same kiel la lasta ekzemplo, sed ĉi-foje ni resendas la href-atributon de ligilo (elemento) kiu enhavas la tekston "Ensalutu". La reala revenisrezulto estas ["/login.html"]. Superrigardo de XPath Funkcioj Estas kelkaj XPath-funkcioj, kaj vi verŝajne ne konas ilin. Estas pluraj, mi pensas, pri kiuj indas scii, inkluzive de la jenaj:
starts-withSe teksto komenciĝas per aparta alia teksta ekzemplo, starts-with(@href, 'http:') resendas vera se href-atributo komenciĝas per http:. enhavasSe teksto enhavas apartan alian tekstan ekzemplon, enhavas(text(), "Smashing Magazine") resendas vera se tekstnodo enhavas la vortojn "Smashing Magazine" en ĝi ie ajn. countRedonas kalkulon de kiom da kongruoj estas al demando. Ekzemple, count(//*[komencas-kun(@href, 'http:']) liveras kalkulon de kiom da ligiloj en la kunteksta nodo havas elementojn kun href-atributo kiu enhavas la tekston komenciĝantan per la http:. subĉeno Funkcias kiel JavaScript subĉeno, krom vi pasas la ĉenon kiel argumenton. Ekzemple, subĉeno ("mia teksto", 2, 4) liveras "y t". substring-beforeResendas la parton de ĉeno antaŭ alia ĉeno. Ekzemple, substing-before("mia teksto", " ") resendas "mia". Simile, substring-before("hi","bye") resendas malplenan ĉenon. substring-afterRedonas la parton de ŝnuro post alia ŝnuro. Ekzemple, substing-after ("mia teksto", " ") resendas "tekston". Simile, substring-after("hi","bye") resendas malplenan ĉenon. normalize-spaceRedonas la argumentan ĉenon kun blankspaco normaligita per senigo de la konduka kaj malantaŭa blankspaco kaj anstataŭigante sekvencojn de blankspacoj per ununura spaco. neRedonas bulean veran se la argumento estas malvera, alie malvera. trueReturnas bulean vera. falseReturns bulean malvera. concatLa sama afero kiel JavaScript concat, krom ke vi ne rulas ĝin kiel metodo sur ĉeno. Anstataŭe, vi enmetu ĉiujn ŝnurojn, kiujn vi volas interligi. string-lengthTiu ne samas kiel JavaScript string-longo, sed prefere redonas la longon de la ŝnuro kiun ĝi estas donita kiel argumento. tradukiĈi tio prenas ĉenon kaj ŝanĝas la duan argumenton al la tria argumento. Ekzemple, traduki("abcdef", "abc", "XYZ") eligas XYZdef.
Krom ĉi tiuj apartaj funkcioj de XPath, ekzistas kelkaj aliaj funkcioj, kiuj funkcias same kiel siaj JavaScript-ekvivalentoj - aŭ ekvivalentoj en esence iu ajn programlingvo - kiujn vi verŝajne ankaŭ trovus utilaj, kiel planko, plafono, ronda, sumo, ktp. La sekva demonstraĵo ilustras ĉiun el ĉi tiuj funkcioj: Vidu la Pen XPath Numerical-funkciojn [forkitaj] de Bryan Rasmussen. Notu ke, kiel la plej multaj el la kordaj manipuladfunkcioj, multaj el la nombraj prenas ununuran enigaĵon. Ĉi tio estas, kompreneble, ĉar ili supozeble estas uzataj por pridemandado, kiel en la lasta ekzemplo de XPath: //li[etaĝo(teksto()) > 250]/@val
Se vi uzas ilin, kiel la plej multaj el la ekzemploj faras, vi finos ruli ĝin sur la unua nodo kiu kongruas kun la vojo. Estas ankaŭ iuj tipkonvertaj funkcioj, kiujn vi verŝajne devus eviti, ĉar JavaScript jam havas siajn proprajn tipkonvertajn problemojn. Sed povas esti tempoj kiam vi volas konverti ŝnuron al nombro por kontroli ĝin kontraŭ iu alia nombro. Funkcioj kiuj fiksas la tipon de io estas bulea, nombro, ĉeno kaj nodo. Ĉi tiuj estas la gravaj XPath-datumtipoj. Kaj kiel vi povus imagi, la plej multaj el ĉi tiuj funkcioj povas esti uzataj sur datumtipoj, kiuj ne estas DOM-nodoj. Ekzemple, substring-after prenas ŝnuron kiel ni jam kovris, sed ĝi povus esti la ŝnuro de href-atributo. Ĝi ankaŭ povas esti nur ĉeno:
const testSubstringAfter = document.queryXPaths("substring-after('saluton mondo',' ')");
Evidente, ĉi tiu ekzemplo redonos al ni la rezultojn tabelon kiel ["mondo"]. Por montri ĉi tion en ago, mi faris demonstran paĝon uzante funkciojn kontraŭ aferoj, kiuj ne estas DOM-nodoj: Vidu la Pen queryXPath [forkigita] de Bryan Rasmussen. Vi devus noti la surprizan aspekton de la tradukfunkcio, kiu estas ke se vi havas signon en la dua argumento (t.e., la listo de signoj vi volas traduki) kaj neniu kongrua karaktero tradukenda al, tiu signo estas forigita de la eligo. Tiel, ĉi tio:
traduki('Saluton, Mia Nomo estas Inigo Montoya, vi mortigis mian patron, prepariĝu por morti','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…rezultoj en la ĉeno, inkluzive de spacoj: [" * * ** "]
Ĉi tio signifas, ke la litero "a" estas tradukita al asterisko (*), sed ĉiu alia signo kiu ne havas tradukon donita la celĉeno estas tute forigita. La blankspaco estas ĉio, kion ni restasinter la tradukitaj "a" signoj. Tiam denove, ĉi tiu demando:
translate('Saluton, Mia Nomo estas Inigo Montoya, vi mortigis mian patron, preparu por morti','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','****************************************************')")
... ne havas la problemon kaj eligas rezulton, kiu aspektas jene:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Eble frapos vin, ke ne ekzistas facila maniero en JavaScript fari ĝuste tion, kion faras la traduka funkcio XPath, kvankam por multaj uzkazoj, anstataŭigi Ĉion per regulaj esprimoj povas trakti ĝin. Vi povus uzi la saman aliron, kiun mi pruvis, sed tio estas suboptimuma se ĉio, kion vi volas, estas traduki la ŝnurojn. La sekva demonstraĵo envolvas la tradukfunkcion de XPath por provizi JavaScript-version: Vidu la Pen tradukfunkcion [forkigita] de Bryan Rasmussen. Kie vi povus uzi ion tian? Konsideru la ĉifradon de Caesar Cipher kun triloka ofseto (ekz., plej bona ĉifrado de 48 a.K.):
traduki ("Cezaro planas transiri Rubikonon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
La eniga teksto "Cezaro planas transiri la Rubikonon!" rezultigas "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Por doni alian rapidan ekzemplon de malsamaj eblecoj, mi faris metalan funkcion, kiu prenas kordan enigon kaj uzas tradukan funkcion por redoni la tekston, inkluzive de ĉiuj signoj kiuj prenas umlaŭtojn. Vidu la Pen-metalfunkcion [forkigita] de Bryan Rasmussen.
konst metalo = (str) => { return traduki(str, "AOUaou","ÄÖÜäöü"); }
Kaj, se oni donas la tekston "Motley Crue rules, rock on dudes!", resendas "Mötley Crüe rüles, röck ön düdes!" Evidente, oni povus havi ĉiajn parodiajn uzojn de ĉi tiu funkcio. Se tio estas vi, tiam ĉi tiu TVTropes-artikolo devus provizi vin per multe da inspiro. Uzante CSS Kun XPath Memoru nian ĉefan kialon por uzi CSS-elektilojn kune kun XPath: CSS preskaŭ komprenas kio estas klaso, dum la plej bona, kiun vi povas fari kun XPath, estas ĉenkomparoj de la klasa atributo. Tio funkcios en la plej multaj kazoj. Sed se vi iam renkontus situacion kie, ekzemple, iu kreis klasojn nomitajn .primaryLinks kaj .primaryLinks2 kaj vi uzus XPath por akiri la .primaryLinks-klason, tiam vi verŝajne renkontus problemojn. Dum ne estas nenio stulta tia, vi verŝajne uzus XPath. Sed mi malĝojas raporti, ke mi laboris ĉe lokoj, kie homoj faras tiajn stultajn aferojn. Jen alia demonstraĵo uzante CSS kaj XPath kune. Ĝi montras kio okazas kiam ni uzas la kodon por ruli XPath sur kunteksta nodo kiu ne estas la nodo de la dokumento. Vidu la Pen css kaj xpath kune [forkigita] de Bryan Rasmussen. La CSS-demando estas .relatedarticles a, kiu alportas la du elementojn en div asignita .relatedarticles klaso. Post tio estas tri "malbonaj" konsultoj, tio estas, demandoj kiuj ne faras tion, kion ni volas, ke ili faru kiam ili funkcias kun ĉi tiuj elementoj kiel la kunteksta nodo. Mi povas klarigi kial ili kondutas malsame ol vi povus atendi. La tri malbonaj demandoj en demando estas:
//text(): Resendas la tutan tekston en la dokumento. //a/text(): Resendas la tutan tekston enen de ligiloj en la dokumento. ./a/text(): Donas neniujn rezultojn.
La kialo de ĉi tiuj rezultoj estas ke dum via kunteksto estas elementoj resenditaj de la CSS-demando, // iras kontraŭ la tuta dokumento. Ĉi tio estas la forto de XPath; CSS ne povas iri de nodo supren al prapatro kaj poste al gefrato de tiu praulo, kaj malsupreniri al posteulo de tiu gefrato. Sed XPath povas. Dume, ./ demandas la infanojn de la nuna nodo, kie la punkto (.) reprezentas la nunan nodon, kaj la antaŭen oblikvo (/) reprezentas iri al iu infana nodo - ĉu ĝi estas atributo, elemento aŭ teksto estas determinita de la sekva parto de la vojo. Sed ne ekzistas elemento elektita de la CSS-demando, tiel tiu demando ankaŭ resendas nenion. Estas tri bonaj demandoj en tiu lasta demonstraĵo:
.//teksto(), ./text(), normalize-space(./text()).
La normaligo-spaca demando montras XPath-funkcian uzadon, sed ankaŭ riparas problemon inkluzivitan en la aliaj demandoj. La HTML estas strukturita jene:
Aŭtomatigi Vian Trajtotestadon Kun Selenium WebDriver
La demando resendas liniofluon ĉe la komenco kaj fino de la teksta nodo,kaj normalize-space forigas ĉi tion. Uzi ajnan XPath-funkcion kiu resendas ion alian ol bulean kun enigo XPath validas por aliaj funkcioj. La sekva demonstraĵo montras kelkajn ekzemplojn: Vidu la ekzemplojn de Pen xpath-funkcioj [forkitaj] de Bryan Rasmussen. La unua ekzemplo montras problemon, pri kiu vi devus atenti. Specife, la sekva kodo:
document.queryXPaths("substring-after(//a/@href,'https://')");
… resendas unu ĉenon:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Ĝi havas sencon, ĉu ne? Ĉi tiuj funkcioj ne resendas tabelojn sed prefere ununurajn ĉenojn aŭ ununurajn nombrojn. Ruli la funkcion ie ajn kun pluraj rezultoj nur redonas la unuan rezulton. La dua rezulto montras tion, kion ni vere volas:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Kiu resendas tabelon de du ŝnuroj:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath-funkcioj povas esti nestitaj same kiel funkcioj en JavaScript. Do, se ni konas la URL-strukturon de Smashing Magazine, ni povus fari la jenon (uzi ŝablonajn literalojn rekomendas): `traduki( subĉeno( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Ĉi tio fariĝas iom tro kompleksa tiel, ke ĝi bezonas komentojn priskribantajn tion, kion ĝi faras: prenu la tutan URL de la href-atributo post www.smashingmagazine.com/, forigu la unuajn naŭ signojn, poste traduku la antaŭan oblikvon (/) al nenio por forigi la finan oblikvan oblikvon. La rezulta tabelo:
["feature-testing-selenium-webdriver","aŭtomatigita-test-rezultoj-plibonigi-alirebleco"]
Pli da XPath-Uzkazoj XPath vere povas brili en testado. La kialo ne malfacilas vidi, ĉar XPath povas esti uzata por ricevi ĉiun elementon en la DOM, de iu ajn pozicio en la DOM, dum CSS ne povas. Vi ne povas fidi, ke CSS-klasoj restas konsekvencaj en multaj modernaj konstrusistemoj, sed kun XPath, ni kapablas fari pli fortigajn kongruojn pri kio estas la tekstenhavo de elemento, sendepende de ŝanĝiĝanta DOM-strukturo. Okazis esplorado pri teknikoj, kiuj permesas vin fari rezistemajn XPath-testojn. Nenio estas pli malbona ol testoj malsukcesas kaj malsukcesas nur ĉar CSS-elektilo ne plu funkcias ĉar io estis renomita aŭ forigita. XPath ankaŭ estas vere bonega ĉe multobla lokalizilo eltiro. Estas pli ol unu maniero uzi XPath-demandojn por kongrui kun elemento. La sama estas vera kun CSS. Sed XPath-demandoj povas bori aferojn en pli celita maniero, kiu limigas tion, kio estas resendita, permesante al vi trovi specifan matĉon kie povas esti pluraj eblaj matĉoj. Ekzemple, ni povas uzi XPath por resendi specifan h2-elementon, kiu estas enhavita ene de div, kiu tuj sekvas fratan div kiu, siavice, enhavas infanan bildelementon kun data-testID="leader" atributo sur ĝi:
ne ricevu ĉi tiun titolon
Ankaŭ ĉi tiun titolon ne ricevu
La kaplinio por la ĉefbildo
Jen la demando: document.queryXPaths(` //div[ sekvanta-frato::div[1] /img[@data-testID='gvidanto'] ] /h2/ teksto () `);
Ni enmetu demonstraĵon por vidi kiel ĉio kuniĝas: Vidu la Pen Complex H2 Query [forkigita] de Bryan Rasmussen. Do jes. Estas multaj eblaj vojoj al iu ajn elemento en testo uzante XPath. XSLT 1.0 Malrekomendiĝo Mi menciis frue, ke la Chrome-teamo planas forigi XSLT 1.0-subtenon de la retumilo. Tio gravas ĉar XSLT 1.0 uzas XML-fokusitan programadon por dokumenttransformo kiu, siavice, dependas de XPath 1.0, kio troviĝas en la plej multaj retumiloj. Kiam tio okazos, ni perdos ŝlosilan komponanton de XPath. Sed konsiderante la fakton, ke XPath estas vere bonega por verki testojn, mi trovas neprobabla, ke XPath kiel tutaĵo baldaŭ malaperos. Dirite, mi rimarkis, ke homoj interesiĝas pri trajto kiam ĝi estas forprenita. Kaj tio certe veras en la kazo de XSLT 1.0 malrekomendita. Estas tuta diskuto okazanta ĉe Hacker News plena de argumentoj kontraŭ la malrekomendiĝo. La afiŝo mem estas bonega ekzemplo de kreado de bloga kadro kun XSLT. Vipovas legi la diskuton mem, sed temas pri kiel JavaScript povus esti uzata kiel shim por XLST por trakti tiajn kazojn. Mi ankaŭ vidis sugestojn, ke retumiloj uzu SaxonJS, kiu estas haveno al la Saxon XSLT, XQUERY kaj XPath-motoroj de JavaScript. Tio estas interesa ideo, precipe ĉar Saxon-JS efektivigas la nunan version de ĉi tiuj specifoj, dum ekzistas neniu retumilo kiu efektivigas ajnan version de XPath aŭ XSLT preter 1.0, kaj neniu kiu efektivigas XQuery. Mi kontaktis Norm Tovey-Walsh ĉe Saxonica, la firmao malantaŭ SaxonJS kaj aliaj versioj de la saksa motoro. Li diris: "Se iu retumila vendisto interesus preni SaxonJS kiel deirpunkton por integri modernajn XML-teknologiojn en la retumilon, ni ĝojus diskuti ĝin kun ili." - Norm Tovey-Walsh
Sed ankaŭ aldonis: "Mi estus tre surprizita, se iu pensus, ke preni SaxonJS en ĝia nuna formo kaj faligi ĝin en la retumilon konstruon senŝanĝa estus la ideala aliro. Retumila vendisto, pro la naturo de la fakto ke ili konstruas la retumilon, povus alproksimiĝi al la integriĝo je multe pli profunda nivelo ol ni povas 'de ekstere'. "- Norm Tovey-Walsh
Indas noti, ke la komentoj de Tovey-Walsh venis proksimume semajnon antaŭ la anonco pri malrekomendiĝo de XSLT. Konkludo Mi povus daŭrigi kaj plu. Sed mi esperas, ke ĉi tio pruvis la potencon de XPath kaj donis al vi multajn ekzemplojn montrantajn kiel uzi ĝin por atingi bonegajn aferojn. Ĝi estas perfekta ekzemplo de pli malnova teknologio en la retumila stako, kiu ankoraŭ havas multe da utileco hodiaŭ, eĉ se vi neniam sciis, ke ĝi ekzistas aŭ neniam pripensis atingi ĝin. Plia Legado
"Plibonigi la Resiliemon de Aŭtomatigitaj Retaj Testoj kun Natura Lingvo" (ACM Cifereca Biblioteko) de Maroun Ayli, Youssef Bakouny, Nader Jalloul, kaj Rima Kilany Ĉi tiu artikolo disponigas multajn XPath-ekzemplojn por verkado de rezistemaj testoj. XPath (MDN)Ĉi tio estas bonega loko por komenci se vi volas teknikan klarigon detaligante kiel XPath funkcias. XPath Tutorial (ZVON)Mi trovis, ke ĉi tiu lernilo estas la plej helpema por mia propra lernado, danke al amaso da ekzemploj kaj klaraj klarigoj. XPatherĈi tiu interaga ilo permesas vin labori rekte kun la kodo.
