Je travaille dans le développement front-end depuis assez longtemps pour constater une tendance au fil des années : de jeunes développeurs travaillant avec un nouveau paradigme de programmation sans en comprendre le contexte historique. Il est évidemment tout à fait compréhensible de ne pas savoir quelque chose. Le Web est un espace très vaste avec un ensemble diversifié de compétences et de spécialités, et nous ne savons pas toujours ce que nous ne savons pas. L’apprentissage dans ce domaine est un voyage continu plutôt que quelque chose qui se produit une fois et se termine. Exemple concret : un membre de mon équipe a demandé s'il était possible de savoir si les utilisateurs quittent un onglet particulier de l'interface utilisateur. J'ai souligné l'événement beforeunload de JavaScript. Mais ceux qui ont déjà abordé ce problème savent que cela est possible car ils ont reçu des alertes concernant des données non enregistrées sur d'autres sites, pour lesquelles beforeunload est un cas d'utilisation typique. J'ai également signalé les événements pageHide et visibleChange à mon collègue pour faire bonne mesure. Comment ai-je su cela ? Parce que cela a été abordé dans un autre projet, pas parce que je l'ai étudié lors de mon apprentissage initial de JavaScript. Le fait est que les frameworks front-end modernes reposent sur les épaules des géants de la technologie qui les ont précédés. Ils font abstraction des pratiques de développement, souvent pour une meilleure expérience de développement qui réduit, voire élimine, le besoin de connaître ou de toucher à des concepts front-end traditionnellement essentiels que tout le monde devrait probablement connaître. Considérez le modèle d'objet CSS (CSSOM). Vous pourriez vous attendre à ce que toute personne travaillant avec CSS et JavaScript possède une grande expérience pratique de CSSOM, mais ce ne sera pas toujours le cas. Il y avait un projet React pour un site de commerce électronique sur lequel j'ai travaillé et dans lequel nous devions charger une feuille de style pour le fournisseur de paiement actuellement sélectionné. Le problème était que la feuille de style se chargeait sur chaque page alors qu'elle n'était vraiment nécessaire que sur une page spécifique. Le développeur chargé de réaliser cela n’avait jamais chargé une feuille de style de manière dynamique. Encore une fois, cela est tout à fait compréhensible lorsque React fait abstraction de l'approche traditionnelle que vous auriez pu adopter. Le CSSOM n’est probablement pas quelque chose dont vous avez besoin dans votre travail quotidien. Mais il est probable que vous ayez besoin d’interagir avec lui à un moment donné, même de manière ponctuelle. Ces expériences m’ont inspiré pour écrire cet article. Il existe de nombreuses fonctionnalités et technologies Web existantes que vous ne toucherez peut-être jamais directement dans votre travail quotidien. Peut-être que vous êtes relativement nouveau dans le développement Web et que vous ne les connaissez tout simplement pas parce que vous êtes imprégné de l'abstraction d'un cadre spécifique qui ne nécessite pas que vous le connaissiez en profondeur, voire pas du tout. Je parle spécifiquement de XML, dont beaucoup d’entre nous savent qu’il s’agit d’un langage ancien qui n’est pas totalement différent du HTML. J'évoque ce sujet en raison des récentes discussions du WHATWG suggérant qu'une partie importante de la pile XML connue sous le nom de programmation XSLT devrait être supprimée des navigateurs. C’est exactement le genre de technologie plus ancienne et existante que nous utilisons depuis des années et qui pourrait être utilisée pour quelque chose d’aussi pratique que la situation CSSOM dans laquelle se trouvait mon équipe. Avez-vous déjà travaillé avec XSLT ? Voyons si nous nous appuyons fortement sur cette ancienne technologie et exploitons ses fonctionnalités en dehors du contexte XML pour résoudre les problèmes du monde réel d’aujourd’hui. XPath : l'API centrale La technologie XML la plus importante et peut-être la plus utile en dehors d'une perspective XML simple est XPath, un langage de requête qui vous permet de trouver n'importe quel nœud ou attribut dans une arborescence de balisage avec un élément racine. J'ai une affection personnelle pour XSLT, mais cela repose également sur XPath, et l'affection personnelle doit être mise de côté dans le classement. L'argument en faveur de la suppression de XSLT ne fait aucune mention de XPath, donc je suppose qu'il est toujours autorisé. C’est une bonne chose car XPath est l’API centrale et la plus importante de cette suite de technologies, en particulier lorsque l’on essaie de trouver quelque chose à utiliser en dehors de l’utilisation normale de XML. C’est important car, même si les sélecteurs CSS peuvent être utilisés pour trouver la plupart des éléments de votre page, ils ne peuvent pas tous les trouver. De plus, les sélecteurs CSS ne peuvent pas être utilisés pour rechercher un élément en fonction de sa position actuelle dans le DOM. XPath le peut. Maintenant, certains d'entre vous qui lisez ceci connaissent peut-être XPath, et d'autres non. XPath est un domaine technologique assez vaste, et je ne peux pas vraiment enseigner toutes les bases ni vous montrer des choses intéressantes à faire avec dans un seul article comme celui-ci. En fait, j’ai essayé d’écrire cet article, mais la publication moyenne de Smashing Magazine ne dépasse pas 5 000 mots. J'en étais déjà à plus de2 000 mots alors que nous n'en sommes qu'à la moitié des bases. Je vais donc commencer à faire des trucs sympas avec XPath et vous donner quelques liens que vous pouvez utiliser pour les bases si vous trouvez ces trucs intéressants. Combiner XPath et CSS XPath peut faire beaucoup de choses que les sélecteurs CSS ne peuvent pas faire lors de l'interrogation d'éléments. Mais les sélecteurs CSS peuvent également faire certaines choses que XPath ne peut pas faire, à savoir interroger des éléments par nom de classe.
CSS XPath .maClasse /*[contient (@class, "myClass")]
Dans cet exemple, CSS interroge les éléments qui contiennent un nom de classe .myClass. Pendant ce temps, l'exemple XPath interroge les éléments qui contiennent une classe d'attributs avec la chaîne « myClass ». En d'autres termes, il sélectionne les éléments avec myClass dans n'importe quel attribut, y compris les éléments avec le nom de classe .myClass — ainsi que les éléments avec « myClass » dans la chaîne, tels que .myClass2. XPath est plus large en ce sens. Alors non. Je ne suggère pas que nous devrions abandonner CSS et commencer à sélectionner tous les éléments via XPath. Ce n’est pas le sujet. Le fait est que XPath peut faire des choses que CSS ne peut pas faire et pourrait encore être très utile, même s'il s'agit d'une technologie plus ancienne dans la pile du navigateur et qui peut ne pas sembler évidente à première vue. Utilisons les deux technologies ensemble non seulement parce que nous le pouvons, mais aussi parce que nous apprendrons quelque chose sur XPath au cours du processus, ce qui en fera un autre outil dans votre pile – dont vous ne saviez peut-être pas qu'il était là depuis le début ! Le problème est que la méthode document.evaluate de JavaScript et les différentes méthodes de sélection de requêtes que nous utilisons avec les API CSS pour JavaScript sont incompatibles. J'ai créé une API de requête compatible pour nous aider à démarrer, même si, certes, je n'y ai pas beaucoup réfléchi car cela s'écarte de ce que nous faisons ici. Voici un exemple fonctionnel assez simple de constructeur de requêtes réutilisable : Voir la requête Pen XPath [forked] par Bryan Rasmussen. J'ai ajouté deux méthodes sur l'objet document : queryCSSSelectors (qui est essentiellement querySelectorAll) et queryXPaths. Ces deux éléments renvoient un objet queryResults :
{ queryType : nœuds | chaîne | numéro | booléen, résultats : any[] // éléments html, éléments xml, chaînes, nombres, booléens, queryCSSSelectors : (requête : chaîne, modification : booléen) => queryResults, queryXpaths : (requête : chaîne, modification : booléen) => queryResults }
Les fonctions queryCSSSelectors et queryXpaths exécutent la requête que vous leur donnez sur les éléments du tableau de résultats, à condition que le tableau de résultats soit de type nœuds, bien sûr. Sinon, il renverra un queryResult avec un tableau vide et un type de nœuds. Si la propriété amend est définie sur true, les fonctions modifieront leurs propres queryResults. En aucun cas, cela ne doit être utilisé dans un environnement de production. Je le fais de cette façon uniquement pour démontrer les différents effets de l’utilisation conjointe des deux API de requête. Exemples de requêtes Je souhaite montrer quelques exemples de différentes requêtes XPath qui démontrent certaines des choses puissantes qu'elles peuvent faire et comment elles peuvent être utilisées à la place d'autres approches. Le premier exemple est //li/text(). Cela interroge tous les éléments li et renvoie leurs nœuds de texte. Donc, si nous devions interroger le code HTML suivant :
- un
- deux
- trois
… voici ce qui est renvoyé :
{"queryType": "xpathEvaluate", "results": ["un", "deux", "trois"],"resultType": "string"}
En d'autres termes, nous obtenons le tableau suivant : ["un", "deux", "trois"]. Normalement, vous devez rechercher les éléments li pour obtenir cela, transformer le résultat de cette requête en un tableau, mapper le tableau et renvoyer le nœud de texte de chaque élément. Mais nous pouvons le faire de manière plus concise avec XPath : document.queryXPaths("//li/text()").results.
Notez que la façon d'obtenir un nœud de texte consiste à utiliser text(), qui ressemble à une signature de fonction - et c'est le cas. Il renvoie le nœud de texte d'un élément. Dans notre exemple, il y a trois éléments li dans le balisage, chacun contenant du texte (« un », « deux » et « trois »).
Regardons un autre exemple de requête text(). Supposons qu'il s'agisse de notre balisage :
Écrivons une requête qui renvoie la valeur de l'attribut href : document.queryXPaths("//a[text() = 'Connexion']/@href").results.
Il s'agit d'une requête XPath sur le document actuel, tout comme le dernier exemple, mais cette fois nous renvoyons l'attribut href d'un lien (un élément) qui contient le texte « Connexion ». Le réel retournéle résultat est ["/login.html"]. Présentation des fonctions XPath Il existe un certain nombre de fonctions XPath et vous ne les connaissez probablement pas. Il y en a plusieurs, je pense, qui valent la peine d'être connus, notamment les suivants :
Commence par Si un texte commence par un autre exemple de texte particulier, commence par (@href, 'http:') renvoie vrai si un attribut href commence par http :. containSi un texte contient un autre exemple de texte particulier, contain(text(), "Smashing Magazine") renvoie true si un nœud de texte contient les mots "Smashing Magazine" n'importe où. countRenvoie le nombre de correspondances avec une requête. Par exemple, count(//*[starts-with(@href, 'http:']) renvoie le nombre de liens dans le nœud contextuel contenant des éléments avec un attribut href qui contient le texte commençant par http :. substringFonctionne comme la sous-chaîne JavaScript, sauf que vous transmettez la chaîne comme argument. Par exemple, substring("my text", 2, 4) renvoie "y t". substring-beforeRenvoie la partie d'une chaîne avant une autre chaîne. Par exemple, substing-before("my text", " ") renvoie "my". De même, substring-before("hi","bye") renvoie une chaîne vide. substring-afterRenvoie la partie d'une chaîne après une autre chaîne. Par exemple, substing-after("my text", " ") renvoie "text". De même, substring-after("hi","bye") renvoie une chaîne vide. normalize-spaceRenvoie la chaîne d'argument avec des espaces normalisés en supprimant les espaces de début et de fin et en remplaçant les séquences de caractères d'espacement par un seul espace. notRenvoie un booléen vrai si l'argument est faux, sinon faux. trueRenvoie le booléen true. falseRenvoie le booléen false. concatLa même chose que JavaScript concat, sauf que vous ne l'exécutez pas en tant que méthode sur une chaîne. Au lieu de cela, vous insérez toutes les chaînes que vous souhaitez concaténer. string-lengthCe n'est pas la même chose que JavaScript string-length, mais renvoie plutôt la longueur de la chaîne qui lui est donnée en argument. TranslateThis prend une chaîne et remplace le deuxième argument par le troisième argument. Par exemple, Translate("abcdef", "abc", "XYZ") génère XYZdef.
Outre ces fonctions XPath particulières, il existe un certain nombre d'autres fonctions qui fonctionnent de la même manière que leurs homologues JavaScript - ou leurs homologues dans pratiquement n'importe quel langage de programmation - que vous trouverez probablement également utiles, telles que plancher, plafond, arrondi, somme, etc. La démo suivante illustre chacune de ces fonctions : Voir les fonctions numériques Pen XPath [forked] par Bryan Rasmussen. Notez que, comme la plupart des fonctions de manipulation de chaînes, la plupart des fonctions numériques nécessitent une seule entrée. C'est bien sûr parce qu'ils sont censés être utilisés pour les requêtes, comme dans le dernier exemple XPath : //li[étage(text()) > 250]/@val
Si vous les utilisez, comme le font la plupart des exemples, vous finirez par l'exécuter sur le premier nœud qui correspond au chemin. Il existe également certaines fonctions de conversion de type que vous devriez probablement éviter car JavaScript a déjà ses propres problèmes de conversion de type. Mais il peut arriver que vous souhaitiez convertir une chaîne en nombre afin de la comparer à un autre nombre. Les fonctions qui définissent le type de quelque chose sont booléennes, nombres, chaînes et nœuds. Ce sont les types de données XPath importants. Et comme vous pouvez l'imaginer, la plupart de ces fonctions peuvent être utilisées sur des types de données qui ne sont pas des nœuds DOM. Par exemple, substring-after prend une chaîne comme nous l'avons déjà vu, mais il pourrait s'agir de la chaîne d'un attribut href. Il peut aussi s'agir simplement d'une chaîne :
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Évidemment, cet exemple nous renverra le tableau de résultats sous la forme ["world"]. Pour montrer cela en action, j'ai créé une page de démonstration utilisant des fonctions sur des éléments qui ne sont pas des nœuds DOM : Voir la requête Pen XPath [forked] par Bryan Rasmussen. Vous devez noter l'aspect surprenant de la fonction de traduction, à savoir que si vous avez un caractère dans le deuxième argument (c'est-à-dire la liste des caractères que vous souhaitez traduire) et aucun caractère correspondant vers lequel traduire, ce caractère est supprimé de la sortie. Ainsi, ceci :
traduire('Bonjour, je m'appelle Inigo Montoya, tu as tué mon père, prépare-toi à mourir','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…résultats dans la chaîne, espaces compris : [" * * ** "]
Cela signifie que la lettre « a » est traduite en astérisque (*), mais que tous les autres caractères qui n'ont pas de traduction étant donné la chaîne cible sont complètement supprimés. L'espace blanc est tout ce qu'il nous resteentre les caractères « a » traduits. Là encore, cette requête :
traduire('Bonjour, je m'appelle Inigo Montoya, tu as tué mon père, prépare-toi à mourir','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*****************************************************')")
…n'a pas de problème et génère un résultat qui ressemble à ceci :
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Vous pourriez être frappé par le fait qu'il n'existe pas de moyen simple en JavaScript de faire exactement ce que fait la fonction de traduction XPath, bien que dans de nombreux cas d'utilisation, replaceAll avec des expressions régulières puisse le gérer. Vous pouvez utiliser la même approche que celle que j'ai démontrée, mais ce n'est pas optimal si tout ce que vous voulez est de traduire les chaînes. La démo suivante englobe la fonction de traduction de XPath pour fournir une version JavaScript : Voir la fonction de traduction Pen [forked] par Bryan Rasmussen. Où pourriez-vous utiliser quelque chose comme ça ? Considérez le chiffrement du chiffre de César avec un décalage à trois places (par exemple, un chiffrement haut de gamme datant de 48 av. J.-C.) :
traduire("César envisage de franchir le Rubicon !", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Le texte saisi « César envisage de franchir le Rubicon ! » donne « Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk ! » Pour donner un autre exemple rapide de différentes possibilités, j'ai créé une fonction metal qui prend une chaîne d'entrée et utilise une fonction de traduction pour renvoyer le texte, y compris tous les caractères qui prennent des trémas. Voir la fonction Pen metal [forked] de Bryan Rasmussen.
const métal = (str) => { return traduire(str, "AOUaou","ÄÖÜäöü"); }
Et, si on lui donne le texte « Motley Crue règles, rock on dudes ! », renvoie « Mötley Crüe règles, röck ön düdes ! Évidemment, on pourrait avoir toutes sortes d’utilisations parodiques de cette fonction. Si c’est votre cas, alors cet article de TVTropes devrait vous fournir beaucoup d’inspiration. Utiliser CSS avec XPath Rappelez-vous la principale raison pour laquelle nous utilisons les sélecteurs CSS avec XPath : CSS comprend à peu près ce qu'est une classe, alors que le mieux que vous puissiez faire avec XPath est la comparaison de chaînes de l'attribut de classe. Cela fonctionnera dans la plupart des cas. Mais si jamais vous deviez vous retrouver dans une situation où, par exemple, quelqu'un créait des classes nommées .primaryLinks et .primaryLinks2 et que vous utilisiez XPath pour obtenir la classe .primaryLinks, vous rencontreriez probablement des problèmes. Tant qu’il n’y a rien de stupide, vous utiliserez probablement XPath. Mais je suis triste d'annoncer que j'ai travaillé dans des endroits où les gens font ce genre de choses stupides. Voici une autre démo utilisant CSS et XPath ensemble. Il montre ce qui se passe lorsque nous utilisons le code pour exécuter un XPath sur un nœud contextuel qui n'est pas le nœud du document. Voir le Pen css et xpath ensemble [forked] par Bryan Rasmussen. La requête CSS est .ratedarticles a, qui récupère les deux éléments a dans un div auquel est attribuée une classe .ratedarticles. Viennent ensuite trois « mauvaises » requêtes, c'est-à-dire des requêtes qui ne font pas ce que nous voulons qu'elles fassent lorsqu'elles sont exécutées avec ces éléments comme nœud de contexte. Je peux expliquer pourquoi ils se comportent différemment de ce à quoi on pourrait s'attendre. Les trois mauvaises requêtes en question sont :
//text() : renvoie tout le texte du document. //a/text() : renvoie tout le texte à l'intérieur des liens dans le document. ./a/text() : ne renvoie aucun résultat.
La raison de ces résultats est que même si votre contexte est un élément renvoyé par la requête CSS, // va à l'encontre de l'ensemble du document. C'est la force de XPath ; CSS ne peut pas passer d'un nœud à un ancêtre, puis à un frère de cet ancêtre, et descendre jusqu'à un descendant de ce frère. Mais XPath le peut. Pendant ce temps, ./ interroge les enfants du nœud actuel, où le point (.) représente le nœud actuel et la barre oblique (/) représente l'accès à un nœud enfant - qu'il s'agisse d'un attribut, d'un élément ou d'un texte est déterminé par la partie suivante du chemin. Mais il n’y a pas d’élément enfant sélectionné par la requête CSS, donc cette requête ne renvoie rien non plus. Il y a trois bonnes requêtes dans cette dernière démo :
.//texte(), ./texte(), normaliser-espace(./text()).
La requête de normalisation de l'espace démontre l'utilisation de la fonction XPath, mais corrige également un problème inclus dans les autres requêtes. Le HTML est structuré comme ceci :
Automatisation de vos tests de fonctionnalités avec Selenium WebDriver
La requête renvoie un saut de ligne au début et à la fin du nœud de texte,et normalize-space supprime cela. L'utilisation de n'importe quelle fonction XPath qui renvoie autre chose qu'un booléen avec une entrée XPath s'applique aux autres fonctions. La démo suivante montre un certain nombre d'exemples : Voir les exemples de fonctions Pen XPath [forked] par Bryan Rasmussen. Le premier exemple montre un problème auquel vous devez faire attention. Plus précisément, le code suivant :
document.queryXPaths("substring-after(//a/@href,'https://')");
…renvoie une chaîne :
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
C'est logique, non ? Ces fonctions ne renvoient pas de tableaux mais plutôt des chaînes simples ou des nombres uniques. L'exécution de la fonction n'importe où avec plusieurs résultats ne renvoie que le premier résultat. Le deuxième résultat montre ce que nous voulons réellement :
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Ce qui renvoie un tableau de deux chaînes :
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Les fonctions XPath peuvent être imbriquées tout comme les fonctions en JavaScript. Ainsi, si nous connaissons la structure de l'URL de Smashing Magazine, nous pourrions procéder comme suit (l'utilisation de modèles littéraux est recommandée) : `traduire( sous-chaîne ( sous-chaîne après (./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Cela devient un peu trop complexe dans la mesure où il nécessite des commentaires décrivant ce qu'il fait : prenez toute l'URL de l'attribut href après www.smashingmagazine.com/, supprimez les neuf premiers caractères, puis traduisez la barre oblique (/) en rien afin de supprimer la barre oblique finale. Le tableau résultant :
["test-de-fonctionnalités-sélénium-webdriver","résultats-de-test-automatisés-améliorer-l'accessibilité"]
Plus de cas d'utilisation de XPath XPath peut vraiment briller lors des tests. La raison n'est pas difficile à voir, car XPath peut être utilisé pour obtenir chaque élément du DOM, à partir de n'importe quelle position dans le DOM, alors que CSS ne le peut pas. Vous ne pouvez pas compter sur la cohérence des classes CSS dans de nombreux systèmes de construction modernes, mais avec XPath, nous sommes en mesure d'établir des correspondances plus robustes quant au contenu textuel d'un élément, quelle que soit la structure DOM changeante. Des recherches ont été menées sur des techniques permettant d'effectuer des tests XPath résilients. Rien n'est pire que de voir des tests échouer simplement parce qu'un sélecteur CSS ne fonctionne plus parce que quelque chose a été renommé ou supprimé. XPath est également très efficace pour l'extraction de plusieurs localisateurs. Il existe plusieurs façons d'utiliser les requêtes XPath pour faire correspondre un élément. La même chose est vraie avec CSS. Mais les requêtes XPath peuvent explorer les choses de manière plus ciblée, ce qui limite ce qui est renvoyé, vous permettant ainsi de trouver une correspondance spécifique là où il peut y avoir plusieurs correspondances possibles. Par exemple, nous pouvons utiliser XPath pour renvoyer un élément h2 spécifique contenu dans un div qui suit immédiatement un div frère qui, à son tour, contient un élément d'image enfant avec un attribut data-testID="leader" :
je ne comprends pas ce titre
Ne comprenez pas non plus ce titre
L'en-tête de l'image de leader
Voici la requête : document.queryXPaths(` //div[ frère-suivant ::div[1] /img[@data-testID='leader'] ] /h2/ texte() `);
Lançons une démo pour voir comment tout cela se déroule : Voir la requête Pen Complex H2 [forked] par Bryan Rasmussen. Alors oui. Il existe de nombreux chemins possibles vers n’importe quel élément d’un test utilisant XPath. Dépréciation de XSLT 1.0 J'ai mentionné plus tôt que l'équipe Chrome prévoyait de supprimer la prise en charge de XSLT 1.0 du navigateur. C'est important car XSLT 1.0 utilise une programmation axée sur XML pour la transformation de documents qui, à son tour, s'appuie sur XPath 1.0, que l'on trouve dans la plupart des navigateurs. Lorsque cela se produit, nous perdrons un composant clé de XPath. Mais étant donné que XPath est vraiment génial pour écrire des tests, je trouve peu probable que XPath dans son ensemble disparaisse de sitôt. Cela dit, j’ai remarqué que les gens s’intéressent à une fonctionnalité lorsqu’elle est supprimée. Et c’est certainement vrai dans le cas où XSLT 1.0 est obsolète. Il y a toute une discussion en cours chez Hacker News remplie d’arguments contre la dépréciation. L'article lui-même est un excellent exemple de création d'un cadre de blog avec XSLT. ToiVous pouvez lire la discussion par vous-même, mais elle explique comment JavaScript pourrait être utilisé comme cale pour XLST pour gérer ce genre de cas. J'ai également vu des suggestions selon lesquelles les navigateurs devraient utiliser SaxonJS, qui est un portage vers les moteurs Saxon XSLT, XQUERY et XPath de JavaScript. C'est une idée intéressante, d'autant plus que Saxon-JS implémente la version actuelle de ces spécifications, alors qu'il n'existe aucun navigateur qui implémente une version de XPath ou XSLT au-delà de 1.0, et aucun qui implémente XQuery. J'ai contacté Norm Tovey-Walsh chez Saxonica, la société derrière SaxonJS et d'autres versions du moteur Saxon. Il a dit : « Si un fournisseur de navigateur souhaitait prendre SaxonJS comme point de départ pour intégrer les technologies XML modernes dans le navigateur, nous serions ravis d'en discuter avec lui. » — Norm Tovey-Walsh
Mais il a également ajouté : "Je serais très surpris si quelqu'un pensait que prendre SaxonJS dans sa forme actuelle et l'intégrer sans modification dans la version du navigateur serait l'approche idéale. Un fournisseur de navigateur, de par la nature du fait qu'il construit le navigateur, pourrait aborder l'intégration à un niveau beaucoup plus profond que nous ne le pouvons "de l'extérieur". "- Norm Tovey-Walsh
Il convient de noter que les commentaires de Tovey-Walsh sont intervenus environ une semaine avant l'annonce de la dépréciation de XSLT. Conclusion Je pourrais continuer encore et encore. Mais j'espère que cela a démontré la puissance de XPath et vous a donné de nombreux exemples démontrant comment l'utiliser pour réaliser de grandes choses. C’est un exemple parfait d’une technologie plus ancienne dans la pile de navigateurs qui a encore beaucoup d’utilité aujourd’hui, même si vous n’avez jamais su qu’elle existait ou si vous n’avez jamais envisagé de l’utiliser. Lectures complémentaires
« Améliorer la résilience des tests Web automatisés avec le langage naturel » (Bibliothèque numérique ACM) par Maroun Ayli, Youssef Bakouny, Nader Jalloul et Rima KilanyCet article fournit de nombreux exemples XPath pour écrire des tests résilients. XPath (MDN)C'est un excellent point de départ si vous souhaitez une explication technique détaillant le fonctionnement de XPath. Tutoriel XPath (ZVON) J'ai trouvé ce tutoriel le plus utile dans mon propre apprentissage, grâce à une multitude d'exemples et d'explications claires. XPatherCet outil interactif vous permet de travailler directement avec le code.
