Dernier, j'ai entendu, Blizzard était l'une des rares entreprises à mettre la pratique du XSLT sur le client (2008). Est-ce encore le cas en 2011 ou plus de personnes explorent-elles maintenant cette technique en production?
Il semble que les navigateurs modernes (IE9, FF4, Chrome) et la puissance de traitement du client soient appris à exploiter cette norme pour économiser tangible dans la puissance de la CPU du serveur et la bande passante sur les propriétés à grande échelle. Est-ce que je manque quelque chose?
Les aspects négatifs que j'ai conscients d'inclure
Les avantages que je perçoivent incluent
Enfin, bien que je sache qu'il est impossible de prédire l'avenir, je suis curieux de connaître les opinions sur le point de savoir si la journée de XSLT de la clientèle sera ou non. Avec intérêt pour HTML5 Conduir des utilisateurs à mettre à niveau leurs navigateurs et développeurs pour explorer de nouvelles techniques, je suis impatient de voir ce qui se développe.
Merci d'avance,
Casey
EDIT:
Tout aperçu de la transformation XML est considérée par Google et les ramifications qu'il a sur le référencement est également appréciée.
6 Réponses :
Le problème avec les trucs XSLT sur le Web est qu'il y a tellement d'autres choses qui peuvent être utilisées à la place de celui-ci qui sont plus faciles sur les développeurs. Je ne peux jamais vraiment voir XSLT de prendre la prise sur le Web dans le formulaire que vous décrivez, je crois en fait que Blizzard a effectivement tiré les traductions XSLT du côté du client de leurs sites lorsqu'elles ont récemment fait des refontes pour consolider leurs marques.
Faire confiance, je voudrais que ce soit, j'ai écrit une solution pour une entreprise que j'ai travaillé dans le passé qui utilise des traductions XSLT pour tous leurs modèles avant. Il n'a pas utilisé les traductions côté client, car c'était en 2005, lorsqu'il y avait encore une part de marché importante des navigateurs qui ne prennent pas en charge le côté client XSLT. L'un des problèmes les plus importants que nous avons rencontrés lorsque vous travaillez avec ce système consistait à trouver des développeurs qui pourraient aider à travailler dessus. Et quand vous avez trouvé quelqu'un qui pourrait travailler avec elle, ils boucheraient beaucoup de la templature car le développement XSLT est une bête différente de tout autre langage de modèles.
Bien que les avantages de l'utilisation de XSLT soient énormes (effectuez une recherche Google de Symphony, un excellent CMS qui utilise XSLT en tant que système de modèles) Je ne vois pas cela en prenant beaucoup plus pour le développement frontal.
Merci pour vos pensées et pour avoir souligné le refroidissement de Blizzard - content de la dépendance wow. Je serais vraiment intéressé à savoir pourquoi ils se sont écartés; Dommage qu'ils n'ont pas de blog de dev. J'ai vu Symphony CMS et cela ressemble à une bonne idée - si / lorsque le côté client XSLT devient souhaitable, vous seriez amorcé pour un interrupteur sans douleur.
J'utilise XSLT sur le côté client sur kulsh.info . Je n'ai trouvé aucune différence dans IE 6-9, Chrome, Safari et Firefox. La transformation XSLT arrive très vite. Je n'ai effectué aucune mesure de vitesse, mais je ne vois aucune différence de comparaison de la version HTML pure (même sur la première génération d'iPod Touch).
mail.yandex.ru (grand fournisseur de messagerie en Russie) utilise également XSLT sur le côté client.
Lors de la prise de décision concernant l'utilisation de XSLT, il s'agit généralement d'un coût de la durée du développeur VS Prestation perçue dans les cycles du processeur. Pour un petit client, il signifie presque universellement: XSLT, si elle existe, passe du côté serveur. Il n'y a tout simplement pas assez d'avantage pour déterminer tous les problèmes du client.
Si une percée est à venir, ce sera sur les grands sites, tels que: Facebook ou Google. Sur ceux-ci, les cycles de la CPU déchargés à un client constitueront une figure de $$$ importante, suffisamment pour justifier le (s) développeur (s) de recrutement (s), qui reprochera les problèmes du client. Je regarderais ces joueurs à voir si un changement va arriver
Oui, le gros poisson conduira certainement ce changement - pensez aux avantages sur un site comme Wikipedia. Je suppose qu'une partie de ma question est - ce qui empêche les principaux joueurs de le faire aujourd'hui?
@Casey: Je ne sais pas ... j'imagine que c'est la même ancienne approche "assez bonne". Probablement bénéficie n'est probablement pas un coût de poids significatif.
Je suis peut-être perdu en traduction, mais je suppose que les problèmes de référencement sont la raison principale, empêchant ainsi beaucoup de personnes d'utiliser XSLT sur le côté client.
Je ne suis pas au courant des robots de recherche, capable d'analyser l'application / XML au lieu de HTML uni ou même flash.
Toujours c'est une bonne pratique (mail.yandex.ru est un exemple notable en effet) pour les applications Web hautement chargées d'utiliser XSLT partiellement sur le client, car le trafic est grand et la convivialité de la séance de séjour n'est pas nécessaire.
Intéressant, je pensais que Google a transformé le XML. Si ce n'est pas le cas, c'est une non-maîtrise
J'aimerais voir plus d'informations de quelqu'un familiarisé avec les systèmes de recherche. Mes inquiétudes ne peuvent être pas à jour.
Et n'oubliez pas que Google n'est pas le seul. Dans beaucoup de pays, il n'a même pas une part de marché de premier plan.
Quels pays? Selon ce site Google, Google est dominant partout: gs.statcounter.com/#search_Engine -ww-mensuel-200912-201012
Je n'ai pas vérifié ces statistiques particulières, mais vous devriez compter la Chine, la Russie, la Corée du Sud et d'autres.
@Flack: Vérifiez comment Google , < href = "http://siteexplorer.search.yahoo.com/search?p=www.aranedabieneshouses.com.ar" rel = "NOFOollow NOREFERRER"> Yahoo et Bing analyse mon ancien site d'assistance client XML / XSLT
@Alejandro, merci, vérifié. Je suppose que mes inquiétudes sont un peu exagérées. Mais toujours, en tant que client, je n'accepterais pas de tels risques sans histoires de réussite de grands sites. Et, enfin, je pense que si vous n'avez pas choisi un modèle de chaudière, des conséquences pourraient être différentes.
Google rampera les fichiers XML, mais les étiquettes importantes telles que le titre et la méta description doivent être présentes dans le XML; Si vous les insérez ou les modifiez avec XSLT, les modifications ne seront pas ramassées par Google. Pour moi, c'est un piège grave et une raison de s'éloigner de XSLT pour l'instant. J'ai choisi votre réponse pour cette raison. Merci!
Une autre chose à mentionner (vu cela sur une autre question similaire à la question) - www.sketchers.com utilise le côté client XSLT
Salut Flack, ne sont pas les mêmes considérations à propos de Séphémagrant également en vigueur pour les applications côté client (telles que le spa), qui obtiennent leurs données des serveurs via Ajax (probablement sérialisés comme JSON), puis effectuez une liaison de données dynamique pour produire le Marquage final? Des exemples sont des sites construits avec KO et récemment, avec angular.
Salut, dimitre. Vous devriez envisager d'utiliser JS sur le serveur et le client. De cette façon, vous pouvez utiliser les mêmes modèles et ainsi être capable de servir du contenu d'une manière différente. E.G., vous rendant des modèles sur le serveur pour la première fois que l'utilisateur est sur le site, puis il suffit de repérancer les pièces dont vous avez besoin sur le client. Vous faites donc desservir un HTML uni pour les robots et les mises à jour incrémentielles pour les utilisateurs parcourant plusieurs pages.
J'ai fait un site Web XML - XSLT il y a quelques années pour un projet à l'école et remarqua un bogue: Firefox ne prend pas en charge la désactivation-sortie-échappée.
Oui. Discutait récemment Stackoverflow.com/questions/ 4492303 / ... . Afair, ce n'est pas vraiment un bug, car le soutien de la DOE n'est pas obligatoire pour les exécutants.
@Flack: Vous avez raison, ce n'est pas un bug. Ils n'ont pas implémenté xpath noms de noms hax ... mais pour une feuille de style de production réelle qui ne devrait pas être un problème.
@Alejandro, ont-ils expliqué en quelque sorte l'absence d'axe des espaces de noms? Parce que ça ressemble à une gaffe pour moi.
@FLAck: Entre XSLT 1.0 et XSLT 2.0, il y avait un consensus dans W3C sur la dépréciation de l'espace de noms hax.
@Alejandro, merci, je ne le sais pas. Je suis totalement coincé dans 1,0 monde :(
dernier j'ai entendu, Blizzard était l'un des Peu d'entreprises à mettre le client XSLT côté client dans la pratique (2008). Est-ce encore l'affaire en 2011, ou sont plus de personnes maintenant explorer cette technique dans production?
Voici quelques exemples:
Le site de Jenni Tennison est complètement piloté sur le site client XSLT < / fort> et a été tellement depuis des années.
Ce site Web commercial est totalement basculé XSLT: http: //www.skechers. com / Nous avons déjà une implémentation de XQuery dans le navigateur: xqib
Michael Kay a blogué sur sa tentative de produire xslt 2.0 dans le navigateur et il y aurait quelque chose de travail bientôt.
Certaines personnes font valoir que XSLT n'est pas conçu pour "la programmation dans le grand" - par exemple, il manque de capacités de compilation distinctes. Espérons que le prochain XSLT 3.0 va changer cela.
Vous avez écrit: Je dirais oui. Que diriez-vous de vous? Cela pourrait être pris comme subjectif et argumentatif. Si vous souhaitez une réponse actuelle aujourd'hui pour Stackoverflow.com/questions/274290/... , vous devriez ajouter une prime à ce sujet
Bon point Alejandro - J'ai éliminé mes pensées personnelles maintenant qu'elles sont documentées dans votre commentaire :) J'ai vu cet article que vous avez lié (j'ai posté quelques commentaires avant de créer le mien) mais je ne savais pas que je pouvais commencer des primes pour les questions des autres, ou des questions qui ont déjà accepté des réponses. Je vais considérer cette approche la prochaine fois. Merci!
Bonne question, +1. Voir ma réponse pour les faits et les développements récents. :)