He estat al desenvolupament frontal prou temps com per veure una tendència al llarg dels anys: els desenvolupadors més joves treballen amb un nou paradigma de programació sense entendre el context històric d'aquest. Per descomptat, és perfectament comprensible no saber alguna cosa. El web és un lloc molt gran amb un conjunt divers d'habilitats i especialitats, i no sempre sabem el que no sabem. L'aprenentatge en aquest camp és un viatge continu en lloc d'una cosa que passa una vegada i acaba. Cas concret: algú del meu equip va preguntar si era possible saber si els usuaris s'allunyen d'una pestanya concreta de la interfície d'usuari. Vaig assenyalar l'esdeveniment abans de descàrrega de JavaScript. Però aquells que han abordat això abans saben que això és possible perquè han rebut alertes sobre dades no desades en altres llocs, per als quals abans de descarregar és un cas d'ús típic. També vaig assenyalar els esdeveniments pageHide and visibilityChange al meu col·lega com a mesura. Com vaig saber això? Perquè va sorgir en un altre projecte, no perquè ho vaig estudiar quan vaig aprendre JavaScript inicialment. El fet és que els marcs de front-end moderns estan a les espatlles dels gegants tecnològics que els van precedir. Abstreuen les pràctiques de desenvolupament, sovint per a una millor experiència de desenvolupador que redueix, o fins i tot elimina, la necessitat de conèixer o tocar els que tradicionalment han estat conceptes de front-end essencials que tothom probablement hauria de conèixer. Considereu el model d'objectes CSS (CSSOM). Podríeu esperar que qualsevol persona que treballi en CSS i JavaScript tingui una gran experiència pràctica en CSSOM, però no sempre serà així. Hi havia un projecte React per a un lloc de comerç electrònic on vaig treballar on havíem de carregar un full d'estil per al proveïdor de pagament seleccionat actualment. El problema era que el full d'estil es carregava a cada pàgina quan només es necessitava en una pàgina específica. El desenvolupador encarregat de fer que això succeís no havia carregat mai un full d'estil de manera dinàmica. De nou, això és totalment comprensible quan React fa abstracte de l'enfocament tradicional que podríeu haver aconseguit. És probable que el CSSOM no sigui una cosa que necessiteu en el vostre treball diari. Però és probable que hàgiu d'interactuar amb ell en algun moment, fins i tot en un cas puntual. Aquestes experiències m'han inspirat a escriure aquest article. Hi ha moltes funcions i tecnologies web existents a la natura que potser mai no toqueu directament en el vostre dia a dia. Potser sou bastant nou en el desenvolupament web i simplement no els coneixeu perquè esteu impregnat de l'abstracció d'un marc específic que no requereix que el conegueu a fons, ni tan sols en absolut. Parlo específicament d'XML, que molts de nosaltres sabem que és un llenguatge antic no totalment diferent de l'HTML. Ho estic plantejant a causa de les recents discussions de WHATWG que suggereixen que una part important de la pila XML coneguda com a programació XSLT s'hauria d'eliminar dels navegadors. Aquest és exactament el tipus de tecnologia més antiga i existent que hem tingut durant anys que es podria utilitzar per a alguna cosa tan pràctica com la situació CSSOM en què es trobava el meu equip. Heu treballat amb XSLT abans? Vegem si ens recolzem molt en aquesta tecnologia més antiga i aprofitem les seves característiques fora del context d'XML per fer front als problemes del món real d'avui. XPath: l'API central La tecnologia XML més important que potser és la més útil fora d'una perspectiva XML directa és XPath, un llenguatge de consulta que us permet trobar qualsevol node o atribut en un arbre de marques amb un element arrel. Tinc un afecte personal per XSLT, però això també depèn de XPath, i l'afecte personal s'ha de deixar de banda en la importància de la classificació. L'argument per eliminar XSLT no fa cap menció a XPath, de manera que suposo que encara està permès. Això és bo perquè XPath és l'API central i més important d'aquest conjunt de tecnologies, especialment quan s'intenta trobar alguna cosa per utilitzar fora de l'ús normal d'XML. És important perquè, tot i que els selectors CSS es poden utilitzar per trobar la majoria dels elements de la vostra pàgina, no els trobaran tots. A més, els selectors CSS no es poden utilitzar per trobar un element en funció de la seva posició actual al DOM. XPath pot. Ara, alguns de vosaltres que llegiu això potser coneixeu XPath, i alguns potser no. XPath és una àrea de tecnologia bastant gran, i realment no puc ensenyar tots els conceptes bàsics i també mostrar-vos coses interessants per fer-hi en un sol article com aquest. De fet, vaig intentar escriure aquest article, però la publicació mitjana de Smashing Magazine no supera les 5.000 paraules. Jo ja estava a més de2.000 paraules mentre només a la meitat dels conceptes bàsics. Per tant, començaré a fer coses interessants amb XPath i us donaré alguns enllaços que podeu utilitzar per als conceptes bàsics si trobeu aquestes coses interessants. Combinant XPath i CSS XPath pot fer moltes coses que els selectors CSS no poden quan consulten elements. Però els selectors CSS també poden fer algunes coses que XPath no pot, és a dir, consultar elements pel nom de classe.
CSS XPath .myClass /*[conté(@classe, "la mevaClasse")]
En aquest exemple, CSS consulta elements que contenen un nom de classe .myClass. Mentrestant, l'exemple XPath consulta elements que contenen una classe d'atributs amb la cadena "myClass". En altres paraules, selecciona elements amb myClass en qualsevol atribut, inclosos els elements amb el nom de classe .myClass, així com els elements amb "myClass" a la cadena, com ara .myClass2. XPath és més ampli en aquest sentit. Per tant, no. No estic suggerint que hauríem de treure CSS i començar a seleccionar tots els elements mitjançant XPath. Aquest no és el punt. La qüestió és que XPath pot fer coses que CSS no poden i encara poden ser molt útils, tot i que és una tecnologia més antiga a la pila del navegador i pot no semblar òbvia a primera vista. Utilitzem les dues tecnologies juntes no només perquè puguem, sinó perquè aprendrem alguna cosa sobre XPath en el procés, convertint-lo en una altra eina de la vostra pila, una que potser no sabíeu que hi ha estat durant tot el temps! El problema és que el mètode document.evaluate de JavaScript i els diferents mètodes de selecció de consultes que fem servir amb les API CSS per a JavaScript són incompatibles. He creat una API de consulta compatible per començar, tot i que és cert que no hi he pensat gaire, ja que és una desviació del que estem fent aquí. Aquí teniu un exemple de treball bastant senzill d'un constructor de consultes reutilitzables: Vegeu el Pen queryXPath [forked] de Bryan Rasmussen. He afegit dos mètodes a l'objecte del document: queryCSSSelectors (que és essencialment querySelectorAll) i queryXPaths. Tots dos retornen un objecte queryResults:
{ queryType: nodes | cadena | nombre | booleà, resultats: qualsevol[] // elements html, elements xml, cadenes, números, booleans, queryCSSSelectors: (consulta: cadena, modificació: booleà) => queryResults, queryXpaths: (consulta: cadena, modificació: booleà) => queryResults }
Les funcions queryCSSSelectors i queryXpaths executen la consulta que els doneu sobre els elements de la matriu de resultats, sempre que la matriu de resultats sigui del tipus nodes, és clar. En cas contrari, retornarà un queryResult amb una matriu buida i un tipus de nodes. Si la propietat modifica s'estableix en true, les funcions canviaran els seus propis queryResults. En cap cas s'ha d'utilitzar en un entorn de producció. Ho faig d'aquesta manera només per demostrar els diferents efectes d'utilitzar les dues API de consulta juntes. Exemples de consultes Vull mostrar alguns exemples de diferents consultes XPath que demostrin algunes de les coses poderoses que poden fer i com es poden utilitzar en lloc d'altres enfocaments. El primer exemple és //li/text(). Això consulta tots els elements li i retorna els seus nodes de text. Per tant, si haguéssim de consultar el següent HTML:
- un
- dos
- tres
… això és el que es retorna:
{"queryType":"xpathEvaluate","results":["un","dos","tres"],"resultType":"cadena"}
En altres paraules, obtenim la següent matriu: ["un","dos","tres"]. Normalment, hauríeu de consultar els elements li per obtenir-ho, convertir el resultat d'aquesta consulta en una matriu, mapejar la matriu i retornar el node de text de cada element. Però ho podem fer de manera més concisa amb XPath: document.queryXPaths("//li/text()").results.
Tingueu en compte que la manera d'obtenir un node de text és utilitzar text(), que sembla una signatura de funció, i ho és. Retorna el node de text d'un element. En el nostre exemple, hi ha tres elements li al marcatge, cadascun conté text ("un", "dos" i "tres").
Vegem un exemple més d'una consulta text(). Suposem que aquest és el nostre marcatge:
Escrivim una consulta que retorni el valor de l'atribut href: document.queryXPaths("//a[text() = 'Iniciar sessió']/@href").results.
Aquesta és una consulta XPath al document actual, igual que l'últim exemple, però aquesta vegada tornem l'atribut href d'un enllaç (un element) que conté el text "Iniciar sessió". El real retornatel resultat és ["/login.html"]. Visió general de les funcions XPath Hi ha diverses funcions XPath i probablement no les coneixeu. Crec que n'hi ha diverses que val la pena conèixer, entre elles les següents:
comença amb Si un text comença amb un altre exemple de text concret, comença amb(@href, 'http:') retorna cert si un atribut href comença per http:. containsSi un text conté un altre exemple de text concret, contains(text(), "Smashing Magazine") retorna true si un node de text conté les paraules "Smashing Magazine" en qualsevol lloc. countRetorna un recompte de quantes coincidències hi ha a una consulta. Per exemple, count(//*[starts-with(@href, 'http:']) retorna un recompte de quants enllaços al node de context tenen elements amb un atribut href que conté el text que comença per http:. subcadenaFunciona com la subcadena de JavaScript, excepte que passeu la cadena com a argument. Per exemple, substring("el meu text", 2, 4) retorna "y t". substring-before Retorna la part d'una cadena abans d'una altra. Per exemple, substing-before("el meu text", " ") retorna "el meu". De la mateixa manera, substring-before("hola","adéu") retorna una cadena buida. substring-afterRetorna la part d'una cadena després d'una altra. Per exemple, substing-after("el meu text", " ") retorna "text". De la mateixa manera, substring-after("hola","adéu") retorna una cadena buida. normalize-spaceRetorna la cadena d'arguments amb espais en blanc normalitzats eliminant els espais en blanc inicials i posteriors i substituint les seqüències de caràcters d'espais en blanc per un únic espai. notReturns un booleà true si l'argument és fals, en cas contrari fals. trueReturns boolean cert. falseReturns booleà fals. concatEl mateix que JavaScript concat, excepte que no l'executeu com a mètode en una cadena. En lloc d'això, poseu totes les cadenes que voleu concatenar. string-lengthAquest no és el mateix que JavaScript string-length, sinó que retorna la longitud de la cadena que es dóna com a argument. translateThis pren una cadena i canvia el segon argument pel tercer argument. Per exemple, translate("abcdef", "abc", "XYZ") dóna sortida a XYZdef.
A part d'aquestes funcions XPath particulars, hi ha una sèrie d'altres funcions que funcionen igual que els seus homòlegs de JavaScript, o homòlegs bàsicament en qualsevol llenguatge de programació, que probablement també trobareu útils, com ara terra, sostre, rodó, suma, etc. La demostració següent il·lustra cadascuna d'aquestes funcions: Vegeu les funcions numèriques de Pen XPath [forked] de Bryan Rasmussen. Tingueu en compte que, com la majoria de les funcions de manipulació de cadenes, moltes de les numèriques prenen una única entrada. Això és, per descomptat, perquè se suposa que s'utilitzen per fer consultes, com en l'últim exemple de XPath: //li[floor(text()) > 250]/@val
Si els feu servir, com fan la majoria dels exemples, l'acabareu executant al primer node que coincideixi amb el camí. També hi ha algunes funcions de conversió de tipus que probablement hauríeu d'evitar perquè JavaScript ja té els seus propis problemes de conversió de tipus. Però hi pot haver moments en què vulgueu convertir una cadena en un número per contrastar-la amb un altre nombre. Les funcions que estableixen el tipus d'alguna cosa són booleà, nombre, cadena i node. Aquests són els tipus de dades XPath importants. I com us podeu imaginar, la majoria d'aquestes funcions es poden utilitzar en tipus de dades que no són nodes DOM. Per exemple, substring-after pren una cadena com ja hem tractat, però podria ser la cadena d'un atribut href. També pot ser només una cadena:
const testSubstringAfter = document.queryXPaths("substring-after('hola món',' ')");
Òbviament, aquest exemple ens retornarà la matriu de resultats com a ["món"]. Per mostrar-ho en acció, he fet una pàgina de demostració utilitzant funcions contra coses que no són nodes DOM: Vegeu el Pen queryXPath [forked] de Bryan Rasmussen. Heu de tenir en compte l'aspecte sorprenent de la funció de traducció, que és que si teniu un caràcter al segon argument (és a dir, la llista de caràcters que voleu traduir) i cap caràcter coincident per traduir, aquest caràcter s'elimina de la sortida. Així, això:
translate('Hola, em dic Inigo Montoya, vas matar el meu pare, prepara't per morir','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
… resultats a la cadena, inclosos els espais: [" ** ** "]
Això significa que la lletra "a" s'està traduint a un asterisc (*), però tots els altres caràcters que no tenen traducció donada la cadena de destinació s'eliminen completament. L'espai en blanc és tot el que ens quedaentre els caràcters "a" traduïts. De nou, aquesta consulta:
translate('Hola, em dic Inigo Montoya, vas matar el meu pare, prepara't per morir','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','****************************************************')")
... no té el problema i produeix un resultat semblant a aquest:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Potser us semblarà que no hi ha una manera fàcil a JavaScript de fer exactament el que fa la funció de traducció XPath, encara que en molts casos d'ús, substituirAll amb expressions regulars ho pot gestionar. Podeu utilitzar el mateix enfocament que he demostrat, però això no és òptim si tot el que voleu és traduir les cadenes. La demostració següent inclou la funció de traducció de XPath per proporcionar una versió de JavaScript: Vegeu la funció de traducció del llapis [forked] de Bryan Rasmussen. On podríeu utilitzar alguna cosa com aquesta? Penseu en el xifratge Caesar Cipher amb un desplaçament de tres llocs (per exemple, el xifratge de primera línia del 48 aC):
translate("Cèsar planeja creuar el Rubicó!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
El text d'entrada "Cèsar planeja creuar el Rubicó!" resultats a "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" Per donar un altre exemple ràpid de diferents possibilitats, vaig fer una funció metàl·lica que pren una entrada de cadena i utilitza una funció de traducció per retornar el text, inclosos tots els caràcters que prenen dièresi. Vegeu la funció Pen metall [forked] de Bryan Rasmussen.
const metall = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
I, si es dóna el text "Motley Crue rules, rock on dudes!", retorna "Mötley Crüe rüles, röck ön düdes!" Òbviament, es podria tenir tota mena d'usos paròdics d'aquesta funció. Si ets tu, aquest article de TVTropes t'ha de proporcionar molta inspiració. Ús de CSS amb XPath Recordeu el nostre motiu principal per utilitzar selectors CSS juntament amb XPath: CSS entén pràcticament què és una classe, mentre que el millor que podeu fer amb XPath són comparacions de cadenes de l'atribut de classe. Això funcionarà en la majoria dels casos. Però si alguna vegada us trobeu amb una situació en què, per exemple, algú creés classes anomenades .primaryLinks i .primaryLinks2 i utilitzeu XPath per obtenir la classe .primaryLinks, és probable que tingueu problemes. Mentre no hi hagi res tonto com això, probablement utilitzaríeu XPath. Però em fa pena informar que he treballat en llocs on la gent fa aquest tipus de tonteries. Aquí hi ha una altra demostració que utilitza CSS i XPath junts. Mostra què passa quan fem servir el codi per executar un XPath en un node de context que no és el node del document. Vegeu el Pen css i xpath junts [forked] de Bryan Rasmussen. La consulta CSS és .relatedarticles a, que obté els dos elements a en un div assignat a una classe .relatedarticles. Després hi ha tres consultes "dolentes", és a dir, consultes que no fan el que volem que facin quan s'executen amb aquests elements com a node de context. Puc explicar per què es comporten de manera diferent del que podríeu esperar. Les tres consultes dolentes en qüestió són:
//text(): retorna tot el text del document. //a/text(): retorna tot el text dins dels enllaços del document. ./a/text(): no retorna cap resultat.
El motiu d'aquests resultats és que si bé el vostre context és un element retornat de la consulta CSS, // va en contra de tot el document. Aquesta és la força de XPath; CSS no pot passar d'un node a un avantpassat i després a un germà d'aquest avantpassat, i baixar fins a un descendent d'aquest germà. Però XPath pot. Mentrestant, ./ consulta els fills del node actual, on el punt (.) representa el node actual i la barra inclinada (/) representa anar a algun node fill; si es tracta d'un atribut, element o text està determinat per la següent part del camí. Però no hi ha cap element secundari seleccionat per la consulta CSS, per tant, aquesta consulta tampoc retorna res. Hi ha tres bones consultes en aquesta darrera demostració:
.//text(), ./text(), normalitzar-espai(./text()).
La consulta de normalització d'espai demostra l'ús de la funció XPath, però també soluciona un problema inclòs a les altres consultes. L'HTML s'estructura així:
Automatització de les proves de funcions amb Selenium WebDriver
La consulta retorna un avanç de línia al principi i al final del node de text,i normalize-space elimina això. L'ús de qualsevol funció XPath que retorni alguna cosa que no sigui un booleà amb una entrada XPath s'aplica a altres funcions. La demostració següent mostra una sèrie d'exemples: Vegeu els exemples de funcions Pen xpath [forked] de Bryan Rasmussen. El primer exemple mostra un problema que hauríeu de tenir en compte. En concret, el codi següent:
document.queryXPaths("substring-after(//a/@href,'https://')");
...retorna una cadena:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Té sentit, oi? Aquestes funcions no retornen matrius, sinó cadenes individuals o números individuals. L'execució de la funció a qualsevol lloc amb diversos resultats només retorna el primer resultat. El segon resultat mostra el que realment volem:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Que retorna una matriu de dues cadenes:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Les funcions XPath es poden imbricar igual que les funcions a JavaScript. Per tant, si coneixem l'estructura de l'URL de Smashing Magazine, podríem fer el següent (es recomana utilitzar literals de plantilla): `tradueix( subcadena( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Això s'està tornant una mica massa complex en la mesura que necessita comentaris que descriguin el que fa: agafeu tot l'URL de l'atribut href després de www.smashingmagazine.com/, elimineu els primers nou caràcters i, a continuació, traduïu el caràcter de barra inclinada (/) a res per desfer-se de la barra inclinada final. La matriu resultant:
["feature-testing-selenium-webdriver","resultats-de-proves-automatitzats-millora-accessibilitat"]
Més casos d'ús de XPath XPath realment pot brillar a les proves. El motiu no és difícil de veure, ja que XPath es pot utilitzar per obtenir tots els elements del DOM, des de qualsevol posició del DOM, mentre que CSS no. No podeu comptar amb que les classes CSS es mantinguin coherents en molts sistemes de construcció moderns, però amb XPath, podem fer coincidències més sòlides quant a quin és el contingut de text d'un element, independentment de l'estructura DOM canviant. S'han investigat tècniques que permeten fer proves XPath resistents. No hi ha res pitjor que que les proves surtin i fallin només perquè un selector CSS ja no funciona perquè alguna cosa s'ha canviat de nom o s'ha eliminat. XPath també és molt bo per a l'extracció de múltiples localitzadors. Hi ha més d'una manera d'utilitzar les consultes XPath per fer coincidir un element. El mateix passa amb CSS. Però les consultes XPath poden analitzar les coses d'una manera més específica que limita el que es retorna, cosa que us permet trobar una coincidència específica on hi pot haver diverses coincidències possibles. Per exemple, podem utilitzar XPath per retornar un element h2 específic que es troba dins d'un div que segueix immediatament un div germà que, al seu torn, conté un element d'imatge fill amb un atribut data-testID="leader":
no rep aquest títol
Tampoc rep aquest títol
La capçalera de la imatge líder
Aquesta és la consulta: document.queryXPaths(` //div[ germà següent::div[1] /img[@data-testID='líder'] ] /h2/ text() `);
Anem a fer una demostració per veure com s'ajunta tot això: Vegeu la consulta Pen Complex H2 [forked] de Bryan Rasmussen. Així que sí. Hi ha molts camins possibles a qualsevol element d'una prova utilitzant XPath. Desactivació de XSLT 1.0 Vaig esmentar al principi que l'equip de Chrome té previst eliminar el suport XSLT 1.0 del navegador. Això és important perquè XSLT 1.0 utilitza una programació centrada en XML per a la transformació de documents que, al seu torn, es basa en XPath 1.0, que és el que es troba a la majoria de navegadors. Quan això passi, perdrem un component clau de XPath. Però tenint en compte que XPath és realment fantàstic per escriure proves, em sembla poc probable que XPath en conjunt desaparegui aviat. Dit això, m'he adonat que la gent s'interessa per una funció quan la treuen. I això és certament cert en el cas que XSLT 1.0 estigui obsolet. Hi ha una discussió sencera a Hacker News plena d'arguments en contra de la desestimació. La publicació en si és un gran exemple de creació d'un marc de blocs amb XSLT. tupodeu llegir la discussió per vosaltres mateixos, però s'explica com es pot utilitzar JavaScript com a compensació per a XLST per gestionar aquest tipus de casos. També he vist suggeriments que els navegadors haurien d'utilitzar SaxonJS, que és un port per als motors Saxon XSLT, XQUERY i XPath de JavaScript. Aquesta és una idea interessant, sobretot perquè Saxon-JS implementa la versió actual d'aquestes especificacions, mentre que no hi ha cap navegador que implementi cap versió de XPath o XSLT més enllà de la 1.0, i cap que implementi XQuery. Em vaig posar en contacte amb Norm Tovey-Walsh a Saxonica, l'empresa darrere de SaxonJS i altres versions del motor Saxon. Ell va dir: "Si algun proveïdor de navegadors estigués interessat a prendre SaxonJS com a punt de partida per integrar les tecnologies XML modernes al navegador, estaríem encantats de parlar-ne amb ells." - Norm Tovey-Walsh
Però també va afegir: "Estaria molt sorprès que algú pensi que prendre SaxonJS en la seva forma actual i deixar-lo anar a la compilació del navegador sense canvis seria l'enfocament ideal. Un venedor de navegadors, per la naturalesa del fet que construeix el navegador, podria abordar la integració a un nivell molt més profund del que podem 'des de l'exterior'. "- Norm Tovey-Walsh
Val la pena assenyalar que els comentaris de Tovey-Walsh van arribar aproximadament una setmana abans de l'anunci de desestimació de XSLT. Conclusió Podria seguir i seguir. Però espero que això hagi demostrat el poder de XPath i us hagi donat molts exemples que demostrin com utilitzar-lo per aconseguir grans coses. És un exemple perfecte de tecnologia antiga a la pila de navegadors que encara té molta utilitat avui, fins i tot si mai no heu sabut que existia o mai no heu pensat en aconseguir-la. Lectura addicional
"Millora de la resiliència de les proves web automatitzades amb llenguatge natural" (Biblioteca digital ACM) de Maroun Ayli, Youssef Bakouny, Nader Jalloul i Rima KilanyAquest article ofereix molts exemples XPath per escriure proves resilients. XPath (MDN)Aquest és un excel·lent lloc per començar si voleu una explicació tècnica que detalli com funciona XPath. Tutorial XPath (ZVON)He trobat que aquest tutorial és el més útil per al meu propi aprenentatge, gràcies a una gran quantitat d'exemples i explicacions clares. XPatherAquesta eina interactiva us permet treballar directament amb el codi.
