> div[not(contains(@id, 'alpha'))]
> $("div:not(#alpha)")
Pas la même chose : ne fonctionne que pour l’attribut id (et si je veux title ou href pour un lien ?), et c’est contains, pas equals.
Au passage, je viens de retester, et la solution div:not([@id*="alpha"]) fonctionne enfin (il y a quelques temps, il n’aimait pas cette syntaxe)
> a[@href='x' or @href='y']
> $(a[href=x],$a[href=y])
Pas la même chose: si ton sélecteur "a" est en fait un truc long comme un bras, tu es content de pouvoir faire un ou juste dans ton [...]. Sans compter que dans ta version jQuery, tu parcoures l’arbre deux fois — en xpath, tu le fais qu’une fois. Et plus important, pour certains usages, l’ordre des résultats ne sera pas le même : dans le premier cas, tu as les liens dans l’ordre dans lequel ils apparaissent dans l’arbre DOM ; dans le second cas, tu as tous les liens "x" dans l’ordre d’apparition puis tous les éléments "y".
> La beauté de jquery est de s'appuyer sur du map reduce avec des fonctions anonymes, et de très puissantes fonctions de manipulations du DOM qui rend le code lisible.
Tu confonds l’API jQuery et la syntaxe de sélecteur jQuery. Tu peux très bien faire une API jQuery-like qui utilise xpath pour exprimer les sélecteurs, tout comme tu peux faire une syntaxe de sélecteurs jQuery-like qui n’ait pas une API jQuery-like (avec du map-reduce, comme tu dis).
Tout ce que je te dis, moi, c’est que la syntaxe des sélecteurs de xpath est plus lourde mais permet de faire plus de chose que celle de jQuery.
> Ce n'est pas un hasard si ce sont les non informaticiens qui se sont emparés de ce langage
Non informaticiens ? Des développeurs Javascript/PHP/Python/Ruby/... ?
Tu me fais peur là.
[^] # Re: Xpath
Posté par Moonz . En réponse à la dépêche libroxml : une bibliothèque XML qui ne fait pas le poids, mais qui fait le reste.... Évalué à 4.
> $("div:not(#alpha)")
Pas la même chose : ne fonctionne que pour l’attribut id (et si je veux title ou href pour un lien ?), et c’est contains, pas equals.
Au passage, je viens de retester, et la solution div:not([@id*="alpha"]) fonctionne enfin (il y a quelques temps, il n’aimait pas cette syntaxe)
> a[@href='x' or @href='y']
> $(a[href=x],$a[href=y])
Pas la même chose: si ton sélecteur "a" est en fait un truc long comme un bras, tu es content de pouvoir faire un ou juste dans ton [...]. Sans compter que dans ta version jQuery, tu parcoures l’arbre deux fois — en xpath, tu le fais qu’une fois. Et plus important, pour certains usages, l’ordre des résultats ne sera pas le même : dans le premier cas, tu as les liens dans l’ordre dans lequel ils apparaissent dans l’arbre DOM ; dans le second cas, tu as tous les liens "x" dans l’ordre d’apparition puis tous les éléments "y".
> La beauté de jquery est de s'appuyer sur du map reduce avec des fonctions anonymes, et de très puissantes fonctions de manipulations du DOM qui rend le code lisible.
Tu confonds l’API jQuery et la syntaxe de sélecteur jQuery. Tu peux très bien faire une API jQuery-like qui utilise xpath pour exprimer les sélecteurs, tout comme tu peux faire une syntaxe de sélecteurs jQuery-like qui n’ait pas une API jQuery-like (avec du map-reduce, comme tu dis).
Tout ce que je te dis, moi, c’est que la syntaxe des sélecteurs de xpath est plus lourde mais permet de faire plus de chose que celle de jQuery.
> Ce n'est pas un hasard si ce sont les non informaticiens qui se sont emparés de ce langage
Non informaticiens ? Des développeurs Javascript/PHP/Python/Ruby/... ?
Tu me fais peur là.