Détecter qu'un browser supporte XSLT

par **jojolapine** » 07 févr. 2008, 20:58

[...] Et je crois avoir aperçu un bot utilisant Gecko aussi...

t'a pas réussit à l'attraper? Mince t'aurais pu lui soutirer des infos...

Hummm, désolé pour cette blague minable, j'ai pas pu m'empêcher!

par **Hubert Roksor** » 07 févr. 2008, 20:40

Oui, Slurp = Yahoo.

Pour le support des moteurs de rendu, il faudra que je vérifie que les bots qui utilisent ces moteurs supportent aussi XSLT. Par exemple, l'un d'entre eux s'annonce comme

Code : Tout sélectionner

Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko) (Exabot-Thumbnails)

Et je crois avoir aperçu un bot utilisant Gecko aussi...

par **Hywan** » 07 févr. 2008, 20:36

Slurp c'est Yahoo! c'est ça ?

Attention à ne pas considérer les navigateurs mais plutôt les moteurs de rendus : Gecko, WebKit, Opera, et Trident, respectivement pour Mozilla/Firefox/Camino/SeaMonkey/..., Safari et bientôt Konqueror, Opera et Internet Explorer. Ce sera plus judicieux àmha.

par **Hubert Roksor** » 07 févr. 2008, 20:29

Pour info, après vérification il s'avère que beaucoup de bots ne renseignent pas l'en-tête "From", dont

Mediapartners-Google
VoilaBot
certains(?) Slurp
Twiceler
Majestic12

Puisque l'utilisation d'une blacklist est difficilement réalisable, je songe à utiliser une whitelist à la place, pour ne servir du XML qu'à IE6+, Firefox, Safari, Konqueror et Opera. Mais franchement ça fait mal de devoir utiliser de tels moyens pour un truc qui (devrait être|est) standardisé

par **Hywan** » 04 févr. 2008, 00:42

je peux me permettre de te contre-dire (si si, j'ose )
En réalité je dirais que tu abondes dans mon sens même si tu préfères voir le verre à moitié plein et mettre l'accent sur les bons côtés de XSLT, et je pense qu'on a globalement le même point de vue sur le langage : c'est fastidieux à taper et/ou construire, et celui qui aborde XSLT comme un langage impératif* aura tôt fait de l'abandonner. Ceci dit, je reconnais que le langage a aussi ses bons côtés --sinon je ne l'utiliserais pas -- et que c'est la meilleure façon de transformer du XML. C'est juste incroyablement ennuyeux à écrire et à debugger.

+1. Quand je disais contre-dire, ce n'était pas méchant, c'était pour une petite blagounette (petite petite blague donc). XSLT est quand même formidable pour manipuler XML, on n'a pas encore fait mieux, mais c'est vrai que c'est rebutant.

* la honte c'est que j'ai été obligé d'aller sur Wikipedia pour retrouver quel était le contraire de "langage fonctionnel"

Ça arrive au meilleur d'entre nous

.

Il existe des boucles en XSLT
Désolé, il manquait un mot dans ma phrase, je parlais des boucles "for". Par exemple, si tu veux appliquer un traitement à chacun des caractère d'une chaîne tu es obligé de le faire par une fonction récursive et un pointeur que tu fais avancer "à la main". Et pour les programmeurs en PHP, avoir des centaines de fonctions dans la pile est une hérésie, donc il y a une petite gymnastique mentale à pratiquer lorsque l'on passe d'un langage à l'autre.

Exact. On appréciera des années (je blague hein, juste 1an, mais c'est suffisant ...) de Caml et de Scheme pour la récursivité ^^ (et je n'ai pas encore attaqué Prolog ...).

il n'y a pas de else, mais un otherwise
En effet, les gens simulent "else" par "otherwise" et en réalité je comprends pourquoi "else" n'existe pas en XSLT, mais il faut avouer que c'est le premier truc qu'on voit dans XSLT : pas de "else".

Oui, mais comme else devient otherwise, je vois pas où est le problème

.

regarde la source que j'avais faite pour Docbook sur Hoa
Euh, merci mais ça ira, j'ai suffisament d'exemples à rallonge sur mon propre disque

Pas de soucis

. Si jamais tu ne connaissais pas, tu pouvais jeter un oeil.
Je remarque que tu n'en es pas à ton premier script XSLT (hehe, malheureusement hein

), donc ma remarque est inutile.

par **Hubert Roksor** » 04 févr. 2008, 00:31

je peux me permettre de te contre-dire (si si, j'ose )

En réalité je dirais que tu abondes dans mon sens même si tu préfères voir le verre à moitié plein et mettre l'accent sur les bons côtés de XSLT, et je pense qu'on a globalement le même point de vue sur le langage : c'est fastidieux à taper et/ou construire, et celui qui aborde XSLT comme un langage impératif* aura tôt fait de l'abandonner. Ceci dit, je reconnais que le langage a aussi ses bons côtés --sinon je ne l'utiliserais pas

-- et que c'est la meilleure façon de transformer du XML. C'est juste incroyablement ennuyeux à écrire et à debugger.

* la honte c'est que j'ai été obligé d'aller sur Wikipedia pour retrouver quel était le contraire de "langage fonctionnel"

Il existe des boucles en XSLT

Désolé, il manquait un mot dans ma phrase, je parlais des boucles "for". Par exemple, si tu veux appliquer un traitement à chacun des caractère d'une chaîne tu es obligé de le faire par une fonction récursive et un pointeur que tu fais avancer "à la main". Et pour les programmeurs en PHP, avoir des centaines de fonctions dans la pile est une hérésie, donc il y a une petite gymnastique mentale à pratiquer lorsque l'on passe d'un langage à l'autre.

il n'y a pas de else, mais un otherwise

En effet, les gens simulent "else" par "otherwise" et en réalité je comprends pourquoi "else" n'existe pas en XSLT, mais il faut avouer que c'est le premier truc qu'on voit dans XSLT : pas de "else".

regarde la source que j'avais faite pour Docbook sur Hoa

Euh, merci mais ça ira, j'ai suffisament d'exemples à rallonge sur mon propre disque

par **Hywan** » 03 févr. 2008, 22:50

Utiliser des fichiers statiques et faire du XSLT chez le client a aussi ses mauvais côtés :
XSLT est reconnu comme un moyen de torture d'après la convention de Genève
la syntaxe est extrêmement verbeuse,

le fonctionnement est radicalement différent de ce que l'on connait en PHP, JS, etc... Par exemple il n'y a pas de boucles, il faut procéder par récursion. Oh, et il n'y a pas de "else" dans XSLT 1.0. Vous avez bien lu, ils ont implémenté "if", mais pas "else"

il n'y a pas vraiment d'éditeurs spécialisés (à part quelques vieux trucs hors de prix, à ma connaissance)

Mince, c'est si grave que ça que même Genève a mis son nez là-dedans

.

Pour avoir passer tout mon mois de janvier dans DocBook et ces feuilles XSLT, je peux me permettre de te contre-dire

(si si, j'ose

).
Certes XSLT est une torture. Rien n'est franchement évident, mais il y a pire que XSLT (prologue par exemple ...). Il faut comprendre que tout les traitements sont des fonctions à travers des structurations, ça facilite un peu la vie. On manipule un arbre, pas des données. Les données sont situées dans les branches, et sont manipulables à travers des fonctions. C'est sûr ce point que c'est différent de langage comme PHP. Mais ce n'est pas du tout le même but, on en convient.
En revanche, ton exemple est faux. Il existe des boucles en XSLT. Je te l'accorde, c'est fastidieux. Il faut définir un sous-arbre comme comportant les clés, et tu peux faire une boucle de type foreach sur un arbre, en testant les clés précédemment définies (en général, les clés sont dans l'arbre parcouru, logique).
Les recommandations W3C préfèrent utiliser le terme Repetitions plutôt que boucle, et je trouve ça plus juste (voir le chapitre 8 : Repetitions pour XSLT).
Ensuite, il n'y a pas de else, mais un otherwise que l'on utilise dans un choose, ce qui permet un switch ou une suite de elseif. Je t'invite à regarde la source que j'avais faite pour Docbook sur Hoa pour gérer les glossaires des acronymes et abréviations (voir les lignes 11 à 18 et 82 à 91 par exemple, tu auras des boucles, des si, sinon etc.).
Concernant l'éditeur spécialisé : Vi ne suffit pas

? (je me trompe de sujet pour troller je crois

).

Sinon, concernant vraiment ton sujet, c'est intéressant, mais n'ai pas d'idée. Je continue de lire, ça peut toujours être utile

.

par **Hubert Roksor** » 03 févr. 2008, 02:09

C'est plus une reflexion générale que des intentions précises. L'idée derrière tout ça, c'est d'être en mesure de mettre en cache, via des fichiers statiques ou un reverse proxy, les données d'une page. Comme je le disais dans un autre sujet, un fichier statique est servi au minimum 10 fois plus rapidement qu'un script PHP, par conséquent on peut extrapoler et penser que même si une page demande 2-3 fichiers XML et un fichier XSL, le résultat sera plus performant qu'un script PHP. De plus, je pense que cette technique créerait d'autres synergies, par exemple la gestion automatique des réponses 304 par le serveur web, la possibilité de combiner les mêmes fichiers XML pour différentes pages et donc rentabiliser la mise en cache chez le client (chaque fichier possède ses propres paramètres de mise en cache), une réduction de la bande puisque seules les données "utiles" voyages, et sûrement d'autres, notamment vis-à-vis d'AJAX. (en majuscules, et avec un X qui veut dire XML)

Utiliser des fichiers statiques et faire du XSLT chez le client a aussi ses mauvais côtés :

XSLT est reconnu comme un moyen de torture d'après la convention de Genève
- la syntaxe est extrêmement verbeuse,
- le fonctionnement est radicalement différent de ce que l'on connait en PHP, JS, etc... Par exemple il n'y a pas de boucles, il faut procéder par récursion. Oh, et il n'y a pas de "else" dans XSLT 1.0. Vous avez bien lu, ils ont implémenté "if", mais pas "else"
- il n'y a pas vraiment d'éditeurs spécialisés (à part quelques vieux trucs hors de prix, à ma connaissance)
- le debugging chez le client est extraordinairement opaque
aucun mécanisme standard pour négocier l'utilisation de XSLT, principalement vis-à-vis des bots puisque la plupart des clients le supporte
nécessiter d'invalider (effacer) les fichiers statiques à chaque modification des données
d'autres trucs auxquels je n'ai pas pensé

Est-ce qu'une version cache déjà transformée via PHP ou un autre langage ne serait pas une solution?

Si on est prêt à se séparer du caractère "statique" des fichiers, en effet c'est une solution tout-à-fait acceptable. Il est étonamment facile de faire du XSLT du côté de PHP. On pourrait imaginer faire un "moteur de template" sous la forme d'un simple objet SimpleXML contenant les données de la page, couplé à un callback appelé par l'Output Buffering qui snifferait le client et ferait la transformation si nécessaire. Toutefois, on perd les avantages des fichiers statiques et la mise en cache par un tiers est pratiquement impossible.

Si tu dois créer une version différente pour un visiteur normal et un robot, quel sera le gain en bout de ligne?

Ce serait le même programme. Pour reprendre l'exemple du dessus, un bot est un utilisateur comme un autre, à la différence près qu'il faut effectuer la transformation du côté du serveur.

par **Xenon_54** » 03 févr. 2008, 01:18

Quel est le concept de créer un site en XML et de faire transformer le tout par le client via XSLT? Et d'ensuite créer toute sorte de détection pour savoir si finalement le client supporte XSLT?

Est-ce qu'une version cache déjà transformée via PHP ou un autre langage ne serait pas une solution? Si tu dois créer une version différente pour un visiteur normal et un robot, quel sera le gain en bout de ligne?

Merci de m'éclairer sur tes intentions.

par **Hubert Roksor** » 02 févr. 2008, 15:44

Oui, bien sûr, mais ça veut aussi dire qu'il faut maintenir une (potentiellement longue) liste de règles pour identifier ces robots et leurs variantes.

Je n'y avais jamais réfléchi auparavant, mais je m'aperçois qu'il n'y a en fait aucun moyen standard d'identifier un bot. On pourrait argumenter qu'après tout, on s'en fiche de savoir s'il s'agit d'un bot ou pas puisque servir un contenu différent selon qu'il s'agit d'un robot ou d'un humain est mal vu par ces derniers, mais il reste quand même quelques cas où il est important de pouvoir faire la distinction et il n'existe à ma connaissance aucun moyen standard pour la faire, pas même une base de données officielle des User-Agent utilisés. Une astuce à ce sujet, pour chaque moteur, on peut recueillir ces infos à la source en cherchant "inurl:phpinfo.php". À partir des phpinfo() que les gens laissent en ligne, on peut se faire une idée des en-têtes envoyés par chaque robot (même si tous les robots n'ont pas forcément d'interface publique, par exemple le robot d'Adsense).

par **Sékiltoyai** » 02 févr. 2008, 14:51

Pour le mod_rewrite, tu peux aussi te faire une condition sur le user-agent : http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html

par **Hubert Roksor** » 02 févr. 2008, 13:31

Oh, hai.

Ça fait un moment que je me pose cette question, lié à cette technique secrète du futur de l'an 2000 consistant à utiliser des fichiers XML pour un site, transformés via XSLT chez le client. Est-ce que quelqu'un aurait une bonne idée pour détecter qu'un navigateur supporte XSLT ? La plupart des navigateurs envoient un peu tout et n'importe quoi dans l'en-tête Accept mais aucun n'envoit de "Accept: text/xsl" alors que XSLT est largement supporté : IE6+, FF1.5+, Opera 9 (9.5 pour le support de document()), Safari... En fait à l'heure actuelle je me dis qu'on peut simplement présumer que le navigateur supporte XSLT.

Reste les robots d'indexation, qui pour la plupart (tous ?) ne supportent pas XSLT et se contentent d'indexer un fichier XML "tel quel" même lorsque celui-ci comporte une instruction <?xsl-stylesheet ?>. À partir d'un script PHP, ce n'est pas trop dur de comparer la valeur de l'en-tête User-Agent, mais quid des fichiers XML statiques que l'on voudrait dynamiquement --via mod_rewrite par exemple-- transformer en HTML pour ceux qui ne le supportent pas ? La plupart des robots envoient un en-tête From, je me demande si c'est un indicateur suffisament fiable... (en tout cas ça a l'air de suffire pour Google/Yahoo!/MSN)

Toute réflexion sera la bienvenue.

Détecter qu'un browser supporte XSLT

Répondre

Étendre la vue Revue du sujet : Détecter qu'un browser supporte XSLT

Détecter qu'un browser supporte XSLT