Am fost în dezvoltarea front-end suficient de mult pentru a vedea o tendință de-a lungul anilor: dezvoltatorii mai tineri lucrează cu o nouă paradigmă de programare fără a înțelege contextul istoric al acesteia. Desigur, este perfect de înțeles să nu știi ceva. Web-ul este un loc foarte mare, cu un set divers de abilități și specialități și nu știm întotdeauna ceea ce nu știm. Învățarea în acest domeniu este o călătorie continuă, mai degrabă decât ceva care se întâmplă o dată și se termină. Caz concret: cineva din echipa mea a întrebat dacă este posibil să spun dacă utilizatorii navighează departe de o anumită filă din interfața de utilizare. Am subliniat evenimentul înainte de descărcare JavaScript. Dar cei care au abordat acest lucru înainte știu că acest lucru este posibil, deoarece au fost loviți de alerte despre date nesalvate pe alte site-uri, pentru care înainte de descărcare este un caz de utilizare tipic. De asemenea, i-am subliniat colegului meu evenimentele de ascundere a paginii și vizibilitate Schimbare pentru o măsură bună. De unde am știut despre asta? Pentru că a apărut într-un alt proiect, nu pentru că am studiat-o când am învățat inițial JavaScript. Faptul este că cadrele front-end moderne stau pe umerii giganților tehnologiei care le-au precedat. Ei abstractizează practicile de dezvoltare, adesea pentru o experiență mai bună pentru dezvoltatori, care reduce, sau chiar elimină, nevoia de a cunoaște sau atinge ceea ce au fost în mod tradițional concepte front-end esențiale pe care probabil că toată lumea ar trebui să le cunoască. Luați în considerare modelul de obiecte CSS (CSSOM). S-ar putea să vă așteptați ca oricine care lucrează în CSS și JavaScript să aibă o mulțime de experiență practică CSSOM, dar acesta nu va fi întotdeauna cazul. A existat un proiect React pentru un site de comerț electronic la care am lucrat, unde trebuia să încărcăm o foaie de stil pentru furnizorul de plăți selectat în prezent. Problema a fost că foaia de stil se încărca pe fiecare pagină când era într-adevăr necesară doar pe o anumită pagină. Dezvoltatorul însărcinat să facă acest lucru nu încărcase niciodată o foaie de stil dinamic. Din nou, acest lucru este complet de înțeles atunci când React renunță la abordarea tradițională la care ați fi ajuns. Probabil că CSSOM nu este ceva de care aveți nevoie în munca de zi cu zi. Dar este probabil că va trebui să interacționați cu el la un moment dat, chiar și într-un caz unic. Aceste experiențe m-au inspirat să scriu acest articol. Există multe funcții și tehnologii web existente în sălbăticie pe care s-ar putea să nu le atingeți niciodată direct în munca de zi cu zi. Poate că sunteți destul de nou în dezvoltarea web și pur și simplu nu sunteți conștienți de ele, deoarece sunteți cufundat în abstractizarea unui cadru specific care nu necesită să-l cunoașteți profund, sau chiar deloc. Vorbesc în mod specific despre XML, despre care mulți dintre noi știm că este un limbaj străvechi, care nu este total diferit de HTML. Aduc în discuție acest lucru din cauza discuțiilor recente WHATWG care sugerează că o parte semnificativă a stivei XML cunoscută sub numele de programare XSLT ar trebui eliminată din browsere. Acesta este exact genul de tehnologie mai veche, existentă pe care o avem de ani de zile, care ar putea fi folosită pentru ceva la fel de practic precum situația CSSOM în care se afla echipa mea. Ați mai lucrat cu XSLT? Să vedem dacă ne aplecăm puternic în această tehnologie mai veche și ne folosim funcțiile în afara contextului XML pentru a aborda problemele din lumea reală de astăzi. XPath: API-ul central Cea mai importantă tehnologie XML care este poate cea mai utilă în afara unei perspective XML drepte este XPath, un limbaj de interogare care vă permite să găsiți orice nod sau atribut într-un arbore de marcare cu un element rădăcină. Am o afecțiune personală pentru XSLT, dar asta se bazează și pe XPath, iar afecțiunea personală trebuie lăsată deoparte în importanța clasamentului. Argumentul pentru eliminarea XSLT nu face nicio mențiune despre XPath, așa că presupun că este încă permis. Acest lucru este bine, deoarece XPath este API-ul central și cel mai important din această suită de tehnologii, mai ales atunci când încercați să găsiți ceva de folosit în afara utilizării normale XML. Este important pentru că, deși selectoarele CSS pot fi folosite pentru a găsi majoritatea elementelor din pagina dvs., ei nu le pot găsi pe toate. Mai mult, selectoarele CSS nu pot fi folosite pentru a găsi un element pe baza poziției sale curente în DOM. XPath poate. Acum, unii dintre voi care citiți acest lucru ar putea cunoaște XPath, iar alții ar putea să nu. XPath este o zonă destul de mare de tehnologie și nu pot să predau toate elementele de bază și, de asemenea, să vă arăt lucruri interesante de făcut cu el într-un singur articol ca acesta. De fapt, am încercat să scriu acel articol, dar publicația medie Smashing Magazine nu depășește 5.000 de cuvinte. Eram deja la mai mult de2.000 de cuvinte în timp ce doar la jumătatea noțiunilor de bază. Deci, voi începe să fac lucruri interesante cu XPath și voi oferi câteva link-uri pe care le puteți folosi pentru elementele de bază, dacă vi se pare că aceste lucruri sunt interesante. Combinând XPath și CSS XPath poate face o mulțime de lucruri pe care selectorii CSS nu le pot atunci când interogează elemente. Dar selectoarele CSS pot face, de asemenea, câteva lucruri pe care XPath nu le poate, și anume, interogă elemente după numele clasei.
CSS XPath .myClass /*[conține(@clasa, „Clasa mea”)]
În acest exemplu, CSS interogează elementele care conțin un nume de clasă .myClass. Între timp, exemplul XPath interogează elementele care conțin o clasă de atribute cu șirul „myClass”. Cu alte cuvinte, selectează elemente cu myClass în orice atribut, inclusiv elemente cu .myClass classname — precum și elemente cu „myClass” în șir, cum ar fi .myClass2. XPath este mai larg în acest sens. Deci, nu. Nu sugerez că ar trebui să aruncăm CSS și să începem să selectăm toate elementele prin XPath. Nu asta este ideea. Ideea este că XPath poate face lucruri pe care CSS nu poate și ar putea fi încă foarte util, chiar dacă este o tehnologie mai veche în stiva de browser și poate să nu pară evidentă la prima vedere. Să folosim cele două tehnologii împreună nu numai pentru că putem, ci și pentru că vom învăța ceva despre XPath în acest proces, transformându-l într-un alt instrument din stiva dvs. - unul despre care poate nu știați că a existat tot timpul! Problema este că metoda document.evaluate din JavaScript și diferitele metode de selectare a interogărilor pe care le folosim cu API-urile CSS pentru JavaScript sunt incompatibile. Am creat un API de interogare compatibil pentru a ne face să începem, deși, desigur, nu m-am gândit prea mult la asta, deoarece este o abatere de la ceea ce facem aici. Iată un exemplu de lucru destul de simplu al unui constructor de interogare reutilizabil: Vedeți Pen queryXPath [furcat] de Bryan Rasmussen. Am adăugat două metode pe obiectul document: queryCSSSelectors (care este în esență querySelectorAll) și queryXPaths. Ambele returnează un obiect queryResults:
{ queryType: noduri | șir | număr | boolean, rezultate: orice[] // elemente html, elemente xml, șiruri de caractere, numere, boolean, queryCSSSelectors: (interogare: șir, modificare: boolean) => queryResults, queryXpaths: (interogare: șir, modificare: boolean) => queryResults }
Funcțiile queryCSSSelectors și queryXpaths rulează interogarea pe care le oferiți asupra elementelor din matricea de rezultate, atâta timp cât matricea de rezultate este de tip noduri, desigur. În caz contrar, va returna un queryResult cu o matrice goală și un tip de noduri. Dacă proprietatea de modificare este setată la true, funcțiile își vor schimba propriile rezultate queryResults. În nicio circumstanță, acesta nu trebuie utilizat într-un mediu de producție. O fac în acest fel doar pentru a demonstra diferitele efecte ale utilizării împreună a celor două API-uri de interogare. Exemple de interogări Vreau să arăt câteva exemple de diferite interogări XPath care demonstrează unele dintre lucrurile puternice pe care le pot face și cum pot fi utilizate în locul altor abordări. Primul exemplu este //li/text(). Aceasta interogează toate elementele li și returnează nodurile lor text. Deci, dacă ar fi să interogăm următorul HTML:
- unu
- două
- trei
...asta este ceea ce este returnat:
{"queryType":"xpathEvaluate","results":["unu","două","trei"],"resultType":"string"}
Cu alte cuvinte, obținem următoarea matrice: ["unu","două","trei"]. În mod normal, ați interoga elementele li pentru a obține asta, ați transforma rezultatul acelei interogări într-o matrice, ați mapa matricea și a returna nodul text al fiecărui element. Dar putem face asta mai concis cu XPath: document.queryXPaths("//li/text()").rezultate.
Observați că modalitatea de a obține un nod text este să utilizați text(), care arată ca o semnătură a funcției - și este. Returnează nodul text al unui element. În exemplul nostru, există trei elemente li în marcaj, fiecare conținând text ("unu", "două" și "trei").
Să ne uităm la încă un exemplu de interogare text(). Să presupunem că acesta este marcajul nostru:
Să scriem o interogare care returnează valoarea atributului href: document.queryXPaths("//a[text() = 'Conectați-vă']/@href").rezultate.
Aceasta este o interogare XPath pe documentul curent, la fel ca ultimul exemplu, dar de data aceasta returnăm atributul href al unui link (un element) care conține textul „Sign In”. Actualul returnatrezultatul este ["/login.html"]. Prezentare generală a funcțiilor XPath Există o serie de funcții XPath și probabil că nu sunteți familiarizat cu ele. Sunt câteva, cred, despre care merită să știți, inclusiv următoarele:
începe cu Dacă un text începe cu un alt exemplu de text, începe cu(@href, 'http:') returnează adevărat dacă un atribut href începe cu http:. containsIf un text conține un anumit alt exemplu de text, contains(text(), „Smashing Magazine”) returnează true dacă un nod text conține cuvintele „Smashing Magazine” oriunde. countReturns un număr al câte potriviri există la o interogare. De exemplu, count(//*[starts-with(@href, 'http:']) returnează un număr al câte link-uri din nodul context au elemente cu un atribut href care conține textul care începe cu http:. substringFuncționează ca subșir JavaScript, cu excepția faptului că treceți șirul ca argument. De exemplu, substring(„textul meu”, 2, 4) returnează „y t”. substring-before Returnează partea dintr-un șir înaintea altui șir. De exemplu, substing-before("textul meu", " ") returnează "meu". În mod similar, substring-before("bună","pa") returnează un șir gol. substring-afterReturns partea unui șir după alt șir. De exemplu, substing-after("textul meu", " ") returnează "text". În mod similar, substring-after("bună","pa") returnează un șir gol. normalize-spaceReturnează șirul de argument cu spațiul alb normalizat prin eliminarea spațiilor albe de început și de final și înlocuind secvențele de caractere de spații albe cu un singur spațiu. notReturns un boolean adevărat dacă argumentul este fals, în caz contrar fals. trueReturns boolean adevărat. falseReturns boolean false. concat Același lucru ca JavaScript concat, cu excepția faptului că nu îl rulați ca metodă pe un șir. În schimb, puneți toate șirurile pe care doriți să le concatenați. string-lengthAceasta nu este același cu JavaScript string-length, ci mai degrabă returnează lungimea șirului pe care este dat ca argument. translateThis ia un șir și schimbă al doilea argument cu al treilea argument. De exemplu, translate("abcdef", "abc", "XYZ") scoate XYZdef.
Pe lângă aceste funcții XPath specifice, există o serie de alte funcții care funcționează la fel ca și omologii lor JavaScript - sau omologii în practic orice limbaj de programare - pe care probabil le-ați găsi utile, cum ar fi podea, tavan, rotund, sumă și așa mai departe. Următoarea demonstrație ilustrează fiecare dintre aceste funcții: Vedeți Funcțiile numerice Pen XPath [forked] de Bryan Rasmussen. Rețineți că, la fel ca majoritatea funcțiilor de manipulare a șirurilor, multe dintre cele numerice au o singură intrare. Acest lucru se datorează, desigur, pentru că ar trebui să fie utilizate pentru interogare, ca în ultimul exemplu XPath: //li[floor(text()) > 250]/@val
Dacă le folosiți, așa cum o fac majoritatea exemplelor, veți sfârși prin a-l rula pe primul nod care se potrivește cu calea. Există, de asemenea, unele funcții de conversie de tip pe care probabil ar trebui să le evitați, deoarece JavaScript are deja propriile probleme de conversie a tipului. Dar pot exista momente când doriți să convertiți un șir într-un număr pentru a-l compara cu un alt număr. Funcțiile care stabilesc tipul de ceva sunt boolean, număr, șir și nod. Acestea sunt tipurile de date XPath importante. Și după cum vă puteți imagina, majoritatea acestor funcții pot fi utilizate pe tipuri de date care nu sunt noduri DOM. De exemplu, substring-after preia un șir așa cum am descris deja, dar ar putea fi șirul dintr-un atribut href. Poate fi, de asemenea, doar un șir:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Evident, acest exemplu ne va da înapoi matricea de rezultate ca [„lume”]. Pentru a arăta acest lucru în acțiune, am făcut o pagină demonstrativă folosind funcții împotriva lucrurilor care nu sunt noduri DOM: Vedeți Pen queryXPath [furcat] de Bryan Rasmussen. Ar trebui să rețineți aspectul surprinzător al funcției de traducere, și anume că, dacă aveți un caracter în al doilea argument (adică, lista de caractere pe care doriți să le traduceți) și niciun caracter potrivit pentru a traduce, acel caracter este eliminat din rezultat. Astfel, aceasta:
translate('Bună, numele meu este Inigo Montoya, mi-ai ucis tatăl, pregătește-te să mori','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…rezultate în șir, inclusiv spații: [" ** ** "]
Aceasta înseamnă că litera „a” este tradusă cu un asterisc (*), dar orice alt caracter care nu are o traducere dat fiind șirul țintă este complet eliminat. Spațiile albe sunt tot ce ne mai rămâneîntre caracterele „a” traduse. Apoi, din nou, această interogare:
translate('Bună, numele meu este Inigo Montoya, mi-ai ucis tatăl, pregătește-te să mori','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','****************************************************')")
… nu are problema și emite un rezultat care arată astfel:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
S-ar putea să vă surprindă că nu există o modalitate ușoară în JavaScript de a face exact ceea ce face funcția de traducere XPath, deși pentru multe cazuri de utilizare, replaceAll cu expresii regulate poate face față. Ați putea folosi aceeași abordare pe care am demonstrat-o, dar aceasta este suboptimă dacă tot ce doriți este să traduceți șirurile. Următoarea demonstrație include funcția de traducere a XPath pentru a oferi o versiune JavaScript: Vezi funcția de traducere a stiloului [forked] de Bryan Rasmussen. Unde ai putea folosi asa ceva? Luați în considerare criptarea Caesar Cipher cu o compensare în trei locuri (de exemplu, criptare de vârf din 48 î.Hr.):
translate(„Cezar plănuiește să treacă Rubiconul!”, „ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz”, „XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw”)
Textul introdus „Cezar plănuiește să treacă Rubiconul!” rezultă în „Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Pentru a da un alt exemplu rapid de diferite posibilități, am creat o funcție metal care preia o intrare și folosește o funcție de traducere pentru a returna textul, inclusiv toate caracterele care preiau umlauts. Vezi funcția Pen metal [forked] de Bryan Rasmussen.
const metal = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
Și, dacă primește textul „Motley Crue rules, rock on dudes!”, returnează „Mötley Crüe rüles, röck ön düdes!” Evident, s-ar putea să aibă tot felul de utilizări parodie ale acestei funcții. Dacă ești tu, atunci acest articol TVTropes ar trebui să îți ofere o mulțime de inspirație. Utilizarea CSS cu XPath Amintiți-vă motivul principal pentru care folosim selectoarele CSS împreună cu XPath: CSS înțelege destul de mult ce este o clasă, în timp ce cel mai bun lucru pe care îl puteți face cu XPath este compararea șirurilor de caractere ale atributului clasei. Asta va funcționa în majoritatea cazurilor. Dar dacă ați ajunge vreodată într-o situație în care, să zicem, cineva a creat clase numite .primaryLinks și .primaryLinks2 și ați folosi XPath pentru a obține clasa .primaryLinks, atunci probabil că ați avea probleme. Atâta timp cât nu există nimic prostesc ca asta, probabil că ați folosi XPath. Dar sunt trist să raportez că am lucrat în locuri în care oamenii fac astfel de prostii. Iată o altă demonstrație folosind CSS și XPath împreună. Arată ce se întâmplă atunci când folosim codul pentru a rula un XPath pe un nod context care nu este nodul documentului. Vedeți Pen css și xpath împreună [forked] de Bryan Rasmussen. Interogarea CSS este .relatedarticles a, care preia cele două elemente a dintr-un div alocat o clasă .relatedarticles. După aceea sunt trei interogări „rele”, adică interogări care nu fac ceea ce dorim să facă atunci când rulează cu aceste elemente ca nod context. Pot să explic de ce se comportă diferit decât v-ați aștepta. Cele trei întrebări proaste în cauză sunt:
//text(): Returnează tot textul din document. //a/text(): Returnează tot textul din interiorul linkurilor din document. ./a/text(): nu returnează niciun rezultat.
Motivul pentru aceste rezultate este că, în timp ce contextul dvs. este un elemente returnate din interogarea CSS, // merge împotriva întregului document. Aceasta este puterea XPath; CSS nu poate trece de la un nod la un strămoș și apoi la un frate al acelui strămoș și să coboare la un descendent al acelui frate. Dar XPath poate. Între timp, ./ interogează copiii nodului curent, unde punctul (.) reprezintă nodul curent, iar bara oblică (/) reprezintă mersul către un nod copil - dacă este un atribut, element sau text este determinat de următoarea parte a căii. Dar nu există niciun element copil selectat de interogarea CSS, astfel că interogarea nu returnează nimic. Există trei întrebări bune în ultima demonstrație:
.//text(), ./text(), normalize-space(./text()).
Interogarea de normalizare a spațiului demonstrează utilizarea funcției XPath, dar rezolvă și o problemă inclusă în celelalte interogări. HTML-ul este structurat astfel:
Automatizarea testării caracteristicilor dvs. cu Selenium WebDriver
Interogarea returnează un avans de linie la începutul și la sfârșitul nodului text,și normalize-space elimină acest lucru. Utilizarea oricărei funcții XPath care returnează altceva decât un boolean cu o intrare XPath se aplică și altor funcții. Următoarea demonstrație prezintă o serie de exemple: Vedeți exemplele de funcții Pen xpath [furcat] de Bryan Rasmussen. Primul exemplu arată o problemă la care ar trebui să fii atent. Mai exact, următorul cod:
document.queryXPaths("substring-after(//a/@href,'https://')");
… returnează un șir:
„www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/”
Are sens, nu? Aceste funcții nu returnează tablouri, ci mai degrabă șiruri de caractere sau numere simple. Rularea funcției oriunde cu rezultate multiple returnează doar primul rezultat. Al doilea rezultat arată ce ne dorim cu adevărat:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Care returnează o matrice de două șiruri de caractere:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Funcțiile XPath pot fi imbricate la fel ca și funcțiile din JavaScript. Deci, dacă cunoaștem structura URL-ului Smashing Magazine, am putea face următoarele (se recomandă utilizarea literalelor șablonului): `traduce( subșir ( substring-after(./@href, „www.smashingmagazine.com/”) ,9), '/','')`
Acest lucru devine puțin prea complex, în măsura în care are nevoie de comentarii care să descrie ceea ce face: luați toată adresa URL din atributul href după www.smashingmagazine.com/, eliminați primele nouă caractere, apoi traduceți caracterul bară oblică (/) la nimic pentru a scăpa de bara oblică finală. Matricea rezultată:
[„feature-testing-selenium-webdriver","automated-test-results-improve-accessibility”]
Mai multe cazuri de utilizare XPath XPath poate străluci cu adevărat în testare. Motivul nu este greu de văzut, deoarece XPath poate fi folosit pentru a obține fiecare element din DOM, din orice poziție din DOM, în timp ce CSS nu poate. Nu vă puteți baza pe clasele CSS care rămân consistente în multe sisteme de construcție moderne, dar cu XPath, putem face potriviri mai solide cu privire la conținutul text al unui element, indiferent de schimbarea structurii DOM. Au existat cercetări asupra tehnicilor care vă permit să faceți teste XPath rezistente. Nimic nu este mai rău decât ca testele să se destrame și să eșueze doar pentru că un selector CSS nu mai funcționează pentru că ceva a fost redenumit sau eliminat. XPath este, de asemenea, foarte grozav la extragerea cu mai multe locatoare. Există mai multe modalități de a utiliza interogări XPath pentru a potrivi un element. Același lucru este valabil și cu CSS. Dar interogările XPath pot analiza lucrurile într-un mod mai direcționat, care limitează ceea ce este returnat, permițându-vă să găsiți o potrivire specifică în care pot exista mai multe potriviri posibile. De exemplu, putem folosi XPath pentru a returna un anumit element h2 care este conținut într-un div care urmează imediat un div frate care, la rândul său, conține un element imagine copil cu un atribut data-testID="leader" pe el:
nu primiți acest titlu
Nu primiți nici acest titlu
Antetul pentru imaginea lider
Aceasta este interogarea: document.queryXPaths(` //div[ următorul-frate::div[1] /img[@data-testID='lider'] ] /h2/ text() `);
Să lansăm o demonstrație pentru a vedea cum se reunesc toate acestea: A se vedea interogarea Pen Complex H2 [forked] de Bryan Rasmussen. Deci, da. Există o mulțime de căi posibile către orice element dintr-un test folosind XPath. XSLT 1.0 Depreciere Am menționat mai devreme că echipa Chrome intenționează să elimine suportul XSLT 1.0 din browser. Acest lucru este important deoarece XSLT 1.0 folosește programarea axată pe XML pentru transformarea documentelor care, la rândul său, se bazează pe XPath 1.0, care este ceea ce se găsește în majoritatea browserelor. Când se întâmplă acest lucru, vom pierde o componentă cheie a XPath. Dar dat fiind faptul că XPath este cu adevărat grozav pentru scrierea testelor, mi se pare puțin probabil ca XPath ca întreg să dispară în curând. Acestea fiind spuse, am observat că oamenii devin interesați de o funcție atunci când este eliminată. Și acest lucru este cu siguranță adevărat în cazul în care XSLT 1.0 este depreciat. La Hacker News are loc o întreagă discuție, plină de argumente împotriva deprecierii. Postarea în sine este un exemplu excelent de creare a unui cadru de blogging cu XSLT. Tuputeți citi discuția pentru dvs., dar intră în modul în care JavaScript ar putea fi folosit ca un shim pentru XLST pentru a gestiona astfel de cazuri. Am văzut, de asemenea, sugestii conform cărora browserele ar trebui să utilizeze SaxonJS, care este un port pentru motoarele JavaScript Saxon XSLT, XQUERY și XPath. Aceasta este o idee interesantă, mai ales că Saxon-JS implementează versiunea actuală a acestor specificații, în timp ce nu există niciun browser care să implementeze vreo versiune de XPath sau XSLT dincolo de 1.0 și niciunul care să implementeze XQuery. Am luat legătura cu Norm Tovey-Walsh la Saxonica, compania din spatele SaxonJS și a altor versiuni ale motorului Saxon. El a spus: „Dacă orice furnizor de browser ar fi interesat să ia SaxonJS ca punct de plecare pentru integrarea tehnologiilor XML moderne în browser, am fi încântați să discutăm despre asta cu ei.” – Norm Tovey-Walsh
Dar a mai adăugat: "Aș fi foarte surprins dacă cineva ar crede că luarea SaxonJS în forma sa actuală și introducerea acestuia neschimbată în versiunea browserului ar fi abordarea ideală. Un furnizor de browser, prin natura faptului că construiește browserul, ar putea aborda integrarea la un nivel mult mai profund decât putem noi „din exterior”.” - Norm Tovey-Walsh
Merită remarcat faptul că comentariile lui Tovey-Walsh au venit cu aproximativ o săptămână înainte de anunțul de depreciere a XSLT. Concluzie Aș putea continua și mai departe. Dar sper că acest lucru a demonstrat puterea XPath și ți-a oferit o mulțime de exemple care demonstrează cum să-l folosești pentru a realiza lucruri grozave. Este un exemplu perfect de tehnologie mai veche din stiva de browser, care are încă o mulțime de utilitate astăzi, chiar dacă nu ați știut niciodată că există sau nu v-ați gândit niciodată să o găsiți. Lectură suplimentară
„Îmbunătățirea rezistenței testelor automate web cu limbaj natural” (ACM Digital Library) de Maroun Ayli, Youssef Bakouny, Nader Jalloul și Rima KilanyAcest articol oferă multe exemple XPath pentru scrierea de teste rezistente. XPath (MDN) Acesta este un loc excelent pentru a începe dacă doriți o explicație tehnică care să detalieze cum funcționează XPath. Tutorial XPath (ZVON) Am considerat că acest tutorial este cel mai util în propria mea învățare, datorită unei multitudini de exemple și explicații clare. XPatherAcest instrument interactiv vă permite să lucrați direct cu codul.
