Mi sono occupato di sviluppo front-end abbastanza a lungo da vedere una tendenza nel corso degli anni: sviluppatori più giovani che lavorano con un nuovo paradigma di programmazione senza comprenderne il contesto storico. Ovviamente è perfettamente comprensibile non sapere qualcosa. Il Web è un luogo molto vasto con un insieme diversificato di competenze e specialità e non sempre sappiamo ciò che non sappiamo. L'apprendimento in questo campo è un viaggio continuo piuttosto che qualcosa che accade una volta e finisce. Caso in questione: qualcuno del mio team ha chiesto se fosse possibile sapere se gli utenti escono da una particolare scheda nell'interfaccia utente. Ho sottolineato l'evento beforeunload di JavaScript. Ma coloro che hanno già affrontato questo problema sanno che ciò è possibile perché sono stati colpiti da avvisi sui dati non salvati su altri siti, per i quali prima dello scaricamento è un tipico caso d'uso. Ho anche segnalato gli eventi pageHide e visibilitàChange al mio collega per buona misura. Come lo sapevo? Perché è emerso in un altro progetto, non perché l'ho studiato durante l'apprendimento iniziale di JavaScript. Il fatto è che i moderni framework front-end poggiano sulle spalle dei giganti della tecnologia che li hanno preceduti. Astraggono le pratiche di sviluppo, spesso per una migliore esperienza di sviluppo che riduce, o addirittura elimina, la necessità di conoscere o toccare quelli che sono stati tradizionalmente concetti front-end essenziali che tutti probabilmente dovrebbero conoscere. Considera il modello a oggetti CSS (CSSOM). Potresti aspettarti che chiunque lavori con CSS e JavaScript abbia molta esperienza pratica con CSSOM, ma non sarà sempre così. C'era un progetto React per un sito di e-commerce su cui ho lavorato in cui dovevamo caricare un foglio di stile per il fornitore di pagamenti attualmente selezionato. Il problema era che il foglio di stile veniva caricato su ogni pagina quando era realmente necessario solo su una pagina specifica. Lo sviluppatore incaricato di realizzare ciò non aveva mai caricato un foglio di stile in modo dinamico. Ancora una volta, questo è del tutto comprensibile quando React astrae l'approccio tradizionale che potresti aver raggiunto. Probabilmente il CSSOM non è qualcosa di cui hai bisogno nel tuo lavoro quotidiano. Ma è probabile che prima o poi dovrai interagire con esso, anche in un caso isolato. Queste esperienze mi hanno ispirato a scrivere questo articolo. Esistono molte funzionalità e tecnologie web esistenti in circolazione che potresti non toccare mai direttamente nel tuo lavoro quotidiano. Forse sei abbastanza nuovo nello sviluppo web e semplicemente non ne sei consapevole perché sei immerso nell'astrazione di un framework specifico che non richiede che tu lo conosca profondamente, o addirittura del tutto. Sto parlando nello specifico di XML, che molti di noi sanno essere un linguaggio antico non del tutto dissimile dall'HTML. Ne parlo a causa delle recenti discussioni di WHATWG che suggeriscono che una parte significativa dello stack XML noto come programmazione XSLT dovrebbe essere rimossa dai browser. Questo è esattamente il tipo di tecnologia più vecchia ed esistente che abbiamo da anni e che potrebbe essere utilizzata per qualcosa di pratico come la situazione CSSOM in cui si trovava il mio team. Hai già lavorato con XSLT? Vediamo se ci appoggiamo pesantemente a questa vecchia tecnologia e sfruttiamo le sue funzionalità al di fuori del contesto di XML per affrontare i problemi del mondo reale di oggi. XPath: l'API centrale La tecnologia XML più importante e forse la più utile al di fuori di una prospettiva XML diretta è XPath, un linguaggio di query che consente di trovare qualsiasi nodo o attributo in un albero di markup con un elemento radice. Ho un affetto personale per XSLT, ma si basa anche su XPath e l'affetto personale deve essere messo da parte nell'importanza della classifica. L'argomento a favore della rimozione di XSLT non fa alcuna menzione di XPath, quindi suppongo che sia ancora consentito. Ciò è positivo perché XPath è l'API centrale e più importante in questa suite di tecnologie, soprattutto quando si cerca di trovare qualcosa da utilizzare al di fuori del normale utilizzo di XML. È importante perché, sebbene i selettori CSS possano essere utilizzati per trovare la maggior parte degli elementi nella tua pagina, non possono trovarli tutti. Inoltre, i selettori CSS non possono essere utilizzati per trovare un elemento in base alla sua posizione corrente nel DOM. XPath può. Ora, alcuni di voi che leggono questo articolo potrebbero conoscere XPath e altri no. XPath è un'area tecnologica piuttosto vasta e non posso davvero insegnarti tutte le nozioni di base e anche mostrarti cose interessanti da fare con essa in un singolo articolo come questo. In realtà ho provato a scrivere quell’articolo, ma la pubblicazione media di Smashing Magazine non supera le 5.000 parole. Ero già a più di2.000 parole mentre solo a metà delle nozioni di base. Quindi, inizierò a fare cose interessanti con XPath e ti fornirò alcuni collegamenti che puoi utilizzare per le nozioni di base se trovi queste cose interessanti. Combinazione di XPath e CSS XPath può fare molte cose che i selettori CSS non possono fare quando interrogano gli elementi. Ma i selettori CSS possono anche fare alcune cose che XPath non può, vale a dire interrogare gli elementi in base al nome della classe.
CSS XPath .miaClasse /*[contiene(@class, "miaClasse")]
In questo esempio, i CSS interrogano gli elementi che contengono un nome classe .myClass. Nel frattempo, l'esempio XPath interroga gli elementi che contengono una classe di attributo con la stringa "myClass". In altre parole, seleziona gli elementi con myClass in qualsiasi attributo, inclusi gli elementi con il nome classe .myClass, nonché gli elementi con "myClass" nella stringa, come .myClass2. XPath è più ampio in questo senso. Quindi no. Non sto suggerendo che dovremmo eliminare i CSS e iniziare a selezionare tutti gli elementi tramite XPath. Non è questo il punto. Il punto è che XPath può fare cose che i CSS non possono e potrebbe comunque essere molto utile, anche se è una tecnologia più vecchia nello stack del browser e potrebbe non sembrare ovvia a prima vista. Usiamo le due tecnologie insieme non solo perché possiamo, ma perché impareremo qualcosa su XPath nel processo, rendendolo un altro strumento nel tuo stack: uno che potresti non sapere fosse sempre stato lì! Il problema è che il metodo document.evaluate di JavaScript e i vari metodi di selezione delle query che utilizziamo con le API CSS per JavaScript sono incompatibili. Ho creato un'API di query compatibile per iniziare, anche se, devo ammetterlo, non ci ho pensato molto poiché è una deviazione da ciò che stiamo facendo qui. Ecco un esempio funzionante abbastanza semplice di un costruttore di query riutilizzabile: Vedi Pen queryXPath [forked] di Bryan Rasmussen. Ho aggiunto due metodi sull'oggetto documento: queryCSSSelectors (che è essenzialmente querySelectorAll) e queryXPaths. Entrambi restituiscono un oggetto queryResults:
{ queryType: nodi | stringa | numero | booleano, risultati: any[] // elementi html, elementi xml, stringhe, numeri, booleani, queryCSSSelectors: (query: stringa, modifica: booleano) => queryResults, queryXpaths: (query: stringa, modifica: booleano) => queryResults }
Le funzioni queryCSSSelectors e queryXpaths eseguono la query fornita sugli elementi nell'array dei risultati, purché l'array dei risultati sia di tipo nodes, ovviamente. Altrimenti, restituirà un queryResult con un array vuoto e un tipo di nodi. Se la proprietà amend è impostata su true, le funzioni modificheranno i propri queryResults. In nessun caso deve essere utilizzato in un ambiente di produzione. Lo faccio in questo modo esclusivamente per dimostrare i vari effetti dell'utilizzo combinato delle due API di query. Query di esempio Desidero mostrare alcuni esempi di diverse query XPath che dimostrano alcune delle cose potenti che possono fare e come possono essere utilizzate al posto di altri approcci. Il primo esempio è //li/text(). Questo interroga tutti gli elementi li e restituisce i loro nodi di testo. Quindi, se dovessimo interrogare il seguente codice HTML:
- uno
- due
- tre
…questo è ciò che viene restituito:
{"queryType":"xpathEvaluate","results":["uno","due","tre"],"resultType":"string"}
In altre parole, otteniamo il seguente array: ["uno","due","tre"]. Normalmente, dovresti interrogare gli elementi li per ottenerlo, trasformare il risultato di quella query in un array, mappare l'array e restituire il nodo di testo di ciascun elemento. Ma possiamo farlo in modo più conciso con XPath: document.queryXPaths("//li/text()").results.
Si noti che il modo per ottenere un nodo di testo è utilizzare text(), che assomiglia a una firma di funzione - e lo è. Restituisce il nodo di testo di un elemento. Nel nostro esempio, ci sono tre elementi li nel markup, ciascuno contenente testo ("uno", "due" e "tre").
Diamo un'occhiata a un altro esempio di query text(). Supponiamo che questo sia il nostro markup:
Scriviamo una query che restituisce il valore dell'attributo href: document.queryXPaths("//a[text() = 'Accedi']/@href").results.
Questa è una query XPath sul documento corrente, proprio come nell'ultimo esempio, ma questa volta restituiamo l'attributo href di un collegamento (un elemento) che contiene il testo “Accedi”. L'effettivo restituitoil risultato è ["/login.html"]. Panoramica delle funzioni XPath Esistono numerose funzioni XPath e probabilmente non le conosci. Credo che ce ne siano diversi che vale la pena conoscere, inclusi i seguenti:
inizia-conSe un testo inizia con un particolare altro esempio di testo, inizia-con(@href, 'http:') restituisce true se un attributo href inizia con http:. contieneSe un testo contiene un particolare altro esempio di testo, contiene(testo(), "Smashing Magazine") restituisce true se un nodo di testo contiene le parole "Smashing Magazine" ovunque al suo interno. countRestituisce il numero di corrispondenze con una query. Ad esempio, count(//*[starts-with(@href, 'http:']) restituisce un conteggio di quanti collegamenti nel nodo contesto hanno elementi con un attributo href che contiene il testo che inizia con http:. substringFunziona come la sottostringa JavaScript, tranne per il fatto che passi la stringa come argomento. Ad esempio, sottostringa("il mio testo", 2, 4) restituisce "y t". substring-beforeRestituisce la parte di una stringa prima di un'altra stringa. Ad esempio, substing-before("il mio testo", " ") restituisce "il mio". Allo stesso modo, substring-before("ciao","ciao") restituisce una stringa vuota. substring-afterRestituisce la parte di una stringa dopo un'altra stringa. Ad esempio, substing-after("il mio testo", " ") restituisce "testo". Allo stesso modo, substring-after("ciao","ciao") restituisce una stringa vuota. normalize-spaceRestituisce la stringa dell'argomento con gli spazi normalizzati eliminando gli spazi iniziali e finali e sostituendo sequenze di caratteri di spazi bianchi con un singolo spazio. notRestituisce un valore booleano vero se l'argomento è falso, altrimenti falso. trueRestituisce il booleano true. falseRestituisce un valore booleano falso. concatLa stessa cosa di concat JavaScript, tranne che non lo esegui come metodo su una stringa. Invece, inserisci tutte le stringhe che desideri concatenare. string-lengthNon è la stessa cosa di JavaScript string-length, ma restituisce piuttosto la lunghezza della stringa fornita come argomento. TranslateThis prende una stringa e cambia il secondo argomento nel terzo argomento. Ad esempio, Translate("abcdef", "abc", "XYZ") restituisce XYZdef.
A parte queste particolari funzioni XPath, ci sono una serie di altre funzioni che funzionano esattamente come le loro controparti JavaScript - o controparti praticamente in qualsiasi linguaggio di programmazione - che probabilmente troverai utili, come floor, ceiling, round, sum e così via. La seguente demo illustra ciascuna di queste funzioni: Vedere le funzioni numeriche Pen XPath [biforcute] di Bryan Rasmussen. Si noti che, come la maggior parte delle funzioni di manipolazione delle stringhe, molte di quelle numeriche accettano un singolo input. Questo, ovviamente, perché dovrebbero essere usati per eseguire query, come nell'ultimo esempio XPath: //li[piano(testo()) > 250]/@val
Se li usi, come fa la maggior parte degli esempi, finirai per eseguirlo sul primo nodo che corrisponde al percorso. Ci sono anche alcune funzioni di conversione del tipo che probabilmente dovresti evitare perché JavaScript ha già i suoi problemi di conversione del tipo. Ma ci possono essere momenti in cui vuoi convertire una stringa in un numero per confrontarla con qualche altro numero. Le funzioni che impostano il tipo di qualcosa sono booleano, numero, stringa e nodo. Questi sono i tipi di dati XPath importanti. E come puoi immaginare, la maggior parte di queste funzioni possono essere utilizzate su tipi di dati che non sono nodi DOM. Ad esempio, substring-after accetta una stringa come abbiamo già spiegato, ma potrebbe essere la stringa di un attributo href. Può anche essere solo una stringa:
const testSubstringAfter = document.queryXPaths("substring-after('ciao mondo',' ')");
Ovviamente, questo esempio ci restituirà l'array dei risultati come ["world"]. Per mostrarlo in azione, ho creato una pagina demo utilizzando funzioni su cose che non sono nodi DOM: Vedi Pen queryXPath [forked] di Bryan Rasmussen. Dovresti notare l'aspetto sorprendente della funzione di traduzione, ovvero che se hai un carattere nel secondo argomento (cioè l'elenco dei caratteri che vuoi tradurre) e nessun carattere corrispondente in cui tradurre, quel carattere viene rimosso dall'output. Quindi, questo:
Translate('Ciao, mi chiamo Inigo Montoya, hai ucciso mio padre, preparati a morire','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…risulta nella stringa, compresi gli spazi: [" * * ** "]
Ciò significa che la lettera "a" viene tradotta in un asterisco (*), ma ogni altro carattere che non ha una traduzione data la stringa di destinazione viene completamente rimosso. Lo spazio bianco è tutto ciò che ci restatra i caratteri “a” tradotti. Poi di nuovo, questa domanda:
Translate('Ciao, mi chiamo Inigo Montoya, hai ucciso mio padre, preparati a morire','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','**************************************************')")
…non presenta il problema e restituisce un risultato simile al seguente:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Potrebbe sembrare che non esista un modo semplice in JavaScript per fare esattamente ciò che fa la funzione di traduzione XPath, sebbene per molti casi d'uso, replaceAll con le espressioni regolari possa gestirlo. Potresti utilizzare lo stesso approccio che ho dimostrato, ma non è ottimale se tutto ciò che desideri è tradurre le stringhe. La seguente demo racchiude la funzione di traduzione di XPath per fornire una versione JavaScript: Vedi la funzione di traduzione della penna [biforcuta] di Bryan Rasmussen. Dove potresti usare qualcosa di simile? Considera la crittografia Caesar Cipher con un offset di tre posizioni (ad esempio, crittografia top di gamma dal 48 a.C.):
Translate("Cesare sta progettando di attraversare il Rubicone!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Il testo in input "Cesare sta progettando di attraversare il Rubicone!" il risultato è "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Per fornire un altro rapido esempio di diverse possibilità, ho creato una funzione metal che accetta una stringa in input e utilizza una funzione di traduzione per restituire il testo, inclusi tutti i caratteri che accettano dieresi. Vedi la funzione Pen metal [biforcuta] di Bryan Rasmussen.
const metallo = (str) => { return traduci(str, "AOUaou","ÄÖÜäöü"); }
E, se viene fornito il testo "Motley Crue regole, rock on dudes!", restituisce "Mötley Crüe rüles, röck ön düdes!" Ovviamente, si potrebbero avere tutti i tipi di usi parodia di questa funzione. Se sei tu, allora questo articolo di TVTropes dovrebbe fornirti molta ispirazione. Utilizzo dei CSS con XPath Ricorda il motivo principale per cui utilizziamo i selettori CSS insieme a XPath: i CSS praticamente capiscono cos'è una classe, mentre il meglio che puoi fare con XPath sono confronti di stringhe dell'attributo class. Funzionerà nella maggior parte dei casi. Ma se mai dovessi imbatterti in una situazione in cui, ad esempio, qualcuno ha creato classi denominate .primaryLinks e .primaryLinks2 e tu stavi utilizzando XPath per ottenere la classe .primaryLinks, allora probabilmente incontreresti dei problemi. Finché non c'è niente di stupido, probabilmente utilizzeresti XPath. Ma sono triste nel riferire che ho lavorato in posti dove le persone fanno questo tipo di cose stupide. Ecco un'altra demo che utilizza CSS e XPath insieme. Mostra cosa succede quando utilizziamo il codice per eseguire un XPath su un nodo di contesto che non è il nodo del documento. Guarda i Pen css e xpath insieme [biforcati] di Bryan Rasmussen. La query CSS è .parentarticles a, che recupera i due elementi a in un div a cui è stata assegnata una classe .latedarticles. Dopodiché ci sono tre query "cattive", vale a dire query che non fanno ciò che vogliamo che facciano quando vengono eseguite con questi elementi come nodo di contesto. Posso spiegare perché si comportano diversamente da quanto potresti aspettarti. Le tre query errate in questione sono:
//text(): restituisce tutto il testo nel documento. //a/text(): restituisce tutto il testo all'interno dei collegamenti nel documento. ./a/text(): non restituisce risultati.
Il motivo di questi risultati è che mentre il contesto è un elemento restituito dalla query CSS, // va contro l'intero documento. Questa è la forza di XPath; I CSS non possono andare da un nodo fino a un antenato e poi a un fratello di quell'antenato, e scendere fino a un discendente di quel fratello. Ma XPath può. Nel frattempo, ./ interroga i figli del nodo corrente, dove il punto (.) rappresenta il nodo corrente e la barra (/) rappresenta il passaggio a qualche nodo figlio: se si tratta di un attributo, elemento o testo è determinato dalla parte successiva del percorso. Ma non esiste un elemento figlio selezionato dalla query CSS, quindi anche quella query non restituisce nulla. Ci sono tre buone query nell'ultima demo:
.//testo(), ./testo(), normalize-space(./text()).
La query normalize-space dimostra l'utilizzo della funzione XPath, ma risolve anche un problema incluso nelle altre query. L'HTML è strutturato in questo modo:
Automatizzazione del test delle funzionalità con Selenium WebDriver
La query restituisce un avanzamento riga all'inizio e alla fine del nodo di testo,e normalize-space lo rimuove. L'utilizzo di qualsiasi funzione XPath che restituisce qualcosa di diverso da un valore booleano con un input XPath si applica ad altre funzioni. La demo seguente mostra una serie di esempi: Vedere gli esempi di funzioni Pen xpath [biforcute] di Bryan Rasmussen. Il primo esempio mostra un problema a cui dovresti prestare attenzione. Nello specifico il seguente codice:
document.queryXPaths("substring-after(//a/@href,'https://')");
…restituisce una stringa:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Ha senso, vero? Queste funzioni non restituiscono array ma piuttosto singole stringhe o singoli numeri. L'esecuzione della funzione ovunque con più risultati restituisce solo il primo risultato. Il secondo risultato mostra ciò che vogliamo veramente:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Che restituisce un array di due stringhe:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Le funzioni XPath possono essere annidate proprio come le funzioni in JavaScript. Quindi, se conosciamo la struttura dell'URL di Smashing Magazine, potremmo fare quanto segue (si consiglia di utilizzare i valori letterali del modello): `traduci( sottostringa( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Questo sta diventando un po' troppo complesso al punto che necessita di commenti che descrivano ciò che fa: prendi tutto l'URL dall'attributo href dopo www.smashingmagazine.com/, rimuovi i primi nove caratteri, quindi traduci il carattere barra (/) in nulla in modo da eliminare la barra finale. La matrice risultante:
["test-delle-funzionalità-selenium-webdriver","risultati-del-test-automatizzato-migliorano-l'accessibilità"]
Altri casi d'uso di XPath XPath può davvero brillare nei test. Il motivo non è difficile da capire, poiché XPath può essere utilizzato per ottenere ogni elemento nel DOM, da qualsiasi posizione nel DOM, mentre i CSS no. Non puoi contare sul fatto che le classi CSS rimangano coerenti in molti sistemi di build moderni, ma con XPath siamo in grado di creare corrispondenze più solide su quale sia il contenuto testuale di un elemento, indipendentemente da una struttura DOM che cambia. Sono state effettuate ricerche sulle tecniche che consentono di effettuare test XPath resilienti. Non c'è niente di peggio che vedere dei test fallire e fallire solo perché un selettore CSS non funziona più perché qualcosa è stato rinominato o rimosso. XPath è davvero eccezionale anche nell'estrazione di più localizzatori. Esiste più di un modo per utilizzare le query XPath per trovare una corrispondenza con un elemento. Lo stesso vale con i CSS. Ma le query XPath possono approfondire le cose in un modo più mirato che limita ciò che viene restituito, permettendoti di trovare una corrispondenza specifica dove potrebbero esserci diverse corrispondenze possibili. Ad esempio, possiamo utilizzare XPath per restituire un elemento h2 specifico contenuto all'interno di un div che segue immediatamente un div fratello che, a sua volta, contiene un elemento immagine figlio con un attributo data-testID="leader" su di esso:
non capisco questo titolo
Non capisco neanche questo titolo
L'intestazione dell'immagine leader
Questa è la domanda: document.queryXPaths(` //div[ fratello-seguente::div[1] /img[@data-testID='leader'] ] /h2/ testo() `);
Facciamo una demo per vedere come tutto ciò si combina: Vedi la query Pen Complex H2 [biforcuta] di Bryan Rasmussen. Quindi sì. Esistono molti percorsi possibili per qualsiasi elemento in un test utilizzando XPath. XSLT 1.0 Deprecazione Ho accennato all'inizio che il team di Chrome prevede di rimuovere il supporto XSLT 1.0 dal browser. Questo è importante perché XSLT 1.0 utilizza una programmazione incentrata su XML per la trasformazione dei documenti che, a sua volta, si basa su XPath 1.0, che è ciò che si trova nella maggior parte dei browser. Quando ciò accadrà, perderemo un componente chiave di XPath. Ma dato che XPath è davvero ottimo per scrivere test, trovo improbabile che XPath nel suo insieme scompaia presto. Detto questo, ho notato che le persone si interessano a una funzionalità quando gli viene tolta. E questo è certamente vero nel caso in cui XSLT 1.0 venga deprecato. Su Hacker News è in corso un'intera discussione piena di argomenti contro la deprecazione. Il post stesso è un ottimo esempio di creazione di una struttura di blogging con XSLT. Voipuoi leggere tu stesso la discussione, ma spiega come JavaScript potrebbe essere utilizzato come spessore per XLST per gestire questo tipo di casi. Ho anche visto suggerimenti secondo cui i browser dovrebbero utilizzare SaxonJS, che è un port per i motori Saxon XSLT, XQUERY e XPath di JavaScript. Si tratta di un'idea interessante, soprattutto perché Saxon-JS implementa la versione corrente di queste specifiche, mentre non esiste alcun browser che implementi una versione di XPath o XSLT successiva alla 1.0 e nessuno che implementi XQuery. Ho contattato Norm Tovey-Walsh di Saxonica, la società dietro SaxonJS e altre versioni del motore Saxon. Ha detto: "Se qualche fornitore di browser fosse interessato a prendere SaxonJS come punto di partenza per integrare le moderne tecnologie XML nel browser, saremmo entusiasti di discuterne con loro."— Norm Tovey-Walsh
Ma ha anche aggiunto: "Sarei molto sorpreso se qualcuno pensasse che prendere SaxonJS nella sua forma attuale e inserirlo nella build del browser senza modifiche sarebbe l'approccio ideale. Un fornitore di browser, per la natura del fatto che costruisce il browser, potrebbe avvicinarsi all'integrazione a un livello molto più profondo di quanto possiamo fare "dall'esterno"."— Norm Tovey-Walsh
Vale la pena notare che i commenti di Tovey-Walsh sono arrivati circa una settimana prima dell’annuncio della deprecazione di XSLT. Conclusione Potrei andare avanti all'infinito. Ma spero che questo abbia dimostrato la potenza di XPath e fornito numerosi esempi che dimostrano come utilizzarlo per ottenere grandi risultati. È un perfetto esempio di vecchia tecnologia nello stack dei browser che ha ancora molta utilità oggi, anche se non hai mai saputo che esistesse o non hai mai pensato di utilizzarla. Ulteriori letture
"Migliorare la resilienza dei test Web automatizzati con il linguaggio naturale" (Biblioteca digitale ACM) di Maroun Ayli, Youssef Bakouny, Nader Jalloul e Rima Kilany Questo articolo fornisce molti esempi XPath per scrivere test resilienti. XPath (MDN) Questo è un ottimo punto di partenza se desideri una spiegazione tecnica che descriva in dettaglio come funziona XPath. Tutorial XPath (ZVON) Ho trovato questo tutorial molto utile per il mio apprendimento, grazie alla ricchezza di esempi e spiegazioni chiare. XPatherQuesto strumento interattivo ti consente di lavorare direttamente con il codice.
