Websites et XML/XSLT

[Xenos]

Bonjour à tous.

Suite à la mélasse de code qui commençait à sentir la vase dans l'un des mes fichiers php (celui qui se charge de gérer le contenu de la page web à renvoyer au client), il m'est venu une idée de structure, que je trouve élégante, pratique et légère.
Le principe n'est pas novateur, puisqu'il consiste à séparer sémantique, design et graphisme. Sa description est la suivante:

• Créer une classe par page web
  
• Faire hériter chacune de ces classes d'une classe abstraite, 'Stream', qui se comporte comme un document XML
  
• Permettre aux classes filles de remplir ce doc XML de données
  
• Envoyer au client (le navigateur web) le fichier XML de 'Stream', ainsi qu'un lien vers un XSLT
  
• Laisser le navigateur transformer le XML en JSON, HTML ou autre via le XSLT
  

L'idée est donc d'envoyer le sens (sémantique) de la page web au client, de le laisser le transformer en page HTML/JSON via un XSLT (design), et de laisser ensuite le navigateur traiter le HTML pour lui appliquer le ou les CSS usuels (graphisme).

Mais je bute sur un point:
Vaut-il mieux appliquer le XSLT coté serveur et envoyer du HTML/JSON au client ou bien envoyer du XML avec un lien vers le XSLT et laisser le client faire la transformation vers HTML/JSON?
L'avantage de laisser le client faire la transformation est multiple:

• Le XSLT peut être mis en cache et n'est plus transféré, comme le XML est plus léger que la page HTML, je réduis mon trafic
  
• Si le client fait la transformation, le serveur se tourne les pouces: la charge serveur diminue
  
• Si l'utilisateur est un robot ou un autre site web, celui-ci a plus de faciliter de traiter un XML (qu'il ne transformera pas) qu'un HTML

Mais:

• Tous les clients web supportent-ils XSLT?
  
• Le résultat du XSLT sera-t-il bien traité par le navigateur (le HTML résultant du XSLT sera-t-il traité comme s'il venait du serveur, ce qui inclus le traitement des balises meta/CSS et script/AJAX)?
  
• Quid des crawlers web? Google va-t-il bien voir le HTML après transformation ou va-t-il coincer sur le XML?

Car je peux, sinon, utiliser un XML coté serveur, le transformer coté serveur via le XSLT, et envoyer le résultat au client, mais cela alourdis la charge du serveur...
Ou alors, peut-être pourrai-je faire la transformation coté serveur sur toutes les pages accessibles en tant que visiteur, et laisser le client faire la transformation si ce client est connecté (et donc, plus que probablement humain, en tous cas, ce n'est pas un SEO).

Votre avis, vos remarques?

[Maks]

Pourquoi tu veux toujours faire des trucs compliqués pour des choses qui peuvent se faire simplement ?

[srm]

Parce qu'il aime bien ça

[Xenos]

Parce que:

• Complexe n'est pas compliqué:
  un site PHP→XML puis XML+XSLT→HTML puis HTML+CSS→rendu final n'est pas compliqué, chaque étape est un langage, assez simple souvent, indépendant du reste
  
• La maintenance est facilité:
  séparer les mécanismes de jeu (PHP), sémantique (XML), design (XSLT) et graphisme (CSS) est bénéfique pour la maintenance (or, c'est la maintenance qui fait la force d'un projet car c'est à partir de sa sortie que le projet "vit" au grand jour, s'il n'est pas maintenu, c'est un projet mort-né)
  
• Standardisation:
  Générer du HTML est souvent impossible à traiter ensuite par un autre site (si un autre site veut suivre le fil d'actualité de votre site, ou s'il veut connaître les statistiques de votre jeu, il aura beaucoup de mal à le faire si vous n'avez pas un XML pour cela et s'il vous faut faire un HTML pour les visiteurs + un XML pour les développeurs des autres sites, c'est bis repetita non placent)
  
• Alléger la charge de votre serveur:
  Donc, cela réduit vos couts ("blabla on peut bien payer 200€/an pour un serveur dédié plus puissant", oui mais encore faut-il que l'on soit capable d'assumer ces 200€/an, si les coûts augmente, il faut augmenter les revenus générés par le site, ou alors, on joue la philantropie qui est tout sauf viable ou pérenne)
  

Enfin, peut-être trouves-tu cela "compliqué", mais penses-tu que, il y a 10 ans, les développeurs trouvaient PHP "simple"? Penses-tu que, il y a 20 ans, ces mêmes développeurs trouvaient HTML "simple"?
L'informatique a un énorme atout sur le monde réel qui est la répétabilité: une fois qu'un truc "compliqué" (complexe) a été débattu, testé et standardisé, il devient très simple.
Si ton but est de rester bien au chaud dans ce que tu connais, je n'ai aucun soucis avec cela, mais moi, j'aime bien m'aventurer au-delà des montagnes noires, même si l'escalade n'est pas forcément aisée. Au moins, une fois là-haut, je pourrais planter un piquet et y accrocher une échelle qui permettra aux autres de monter facilement

Tout ce que j'essaie de savoir avant de commencer l'ascension, c'est sa faisabilité... Je n'ai pas envie que mon site, s'il est fait en XML dont la compilation est à charge du client, ne soit pas lisible par google ou autre moteurs de recherche, ou bien que les lecteurs d'écrans se résument à lire les tags XML.

D'ailleurs, je te paries que dans 10 ans au plus, tous les sites "pros" utiliseront un mécanisme similaire. Cela fait quelques années que l'on nous rabâche de séparer (à raison) la sémantique et le design, alors, mettons ces conseils en pratique :p

[Sephi-Chan]

Tiens, tu vas devenir très ami avec Roworll !


Dans la théorie je trouve l'idée excellente :

• On limite l'utilisation de bande passante ;
  
• On transforme le site en une simple API, plus facile à tester et à maintenir ;
  
• On distribue le travail de rendue pour une meilleur utilisation des ressources des serveurs ;
  

Dans la pratique, je pense que c'est assez pénible à faire pour un gain assez faible : aussi intéressant soit-il, XSLT est loin d'être trivial. Grâce à Javascript, XHR et JSON on limite déjà pas mal la quantité de données inutiles transférées.

De plus, si XSLT transforme le XML en HTML, il faut encore faire une nouvelle couche cliente pour ajouter les interactions Javascript.

Du coup, l'alternatives des applications Javascript (réalisées avec Backbone, Angular, Spine, Ember, Batman, Sproutcore, Knockout, etc.) est plus intéressante selon moi dans la mesure où elle transforme une page vide (ou contenant un peu de données envoyées dans le Javascript) retournée par le serveur en une application complète : les templates et tout le code est embarqué dans des fichiers Javascript (qui peuvent être conservées en cache).

Au final, on n'a plus qu'une couche côté client. C'est plus performant et épargne l'apprentissage de XSLT.

Pour une application à contenu qui nécessite d'être indexée, il faut soit proposer du contenu statique, soit recourir à des techniques alternatives (Making AJAX Applications Crawlable). Mais pour l'intérieur d'un jeu, c'est top moumoute.

[niahoo]

Le XML c'est beuurk ! Le XSLT c'est insupportable.

Sinon je rejoins un peu Sephi et Maks, comme concept c'est bon mais c'est du travail pour pas grand chose.

De plus, la charge serveur de rendu des pages c'est un chose, mais généralement tu voudras mettre en cache les pages. Et le cache, qu'il serve du XML ou du HTML ça ne change pas grand chose. De plus, si tu veux qu'on puisse parser tes pages, tu peux servir du XHTML (qui est comme tu le sais du XML valide). Et comme tu aimes bien séparer les couches, à juste titre, ton XHTML sera assez simple, le CSS étant chargé de la mise en forme -- il y aura tout au plus quelques classes/id que le parseur pourra simplement ignorer. Et à chaque nouvelle page, ça t'évite de devoir coder en plus le XSLT, ce qui, de mon point de vue, est un grand bienfait apporté à l'humanité : tu vivras plus vieux, tu auras moins de calvitie, tu seras plus performant au pieu, tu seras beau gosse encore à 80 ans et tu pourras sortir avec des jeunes de 20 ans sans dépenser des fortunes en v!agra.

[Maks]

Ahah toi aussi tu es un traumatisé du XSLT. Pendant mes stages on me refilait parfois ça, un XML bien verbeux et long avec une couche de XS(paghetti)LT par dessus :malade:

[niahoo]

non pas traumatisé. J'ai lu ce que c'était, j'ai trouvé ça génial, j'ai joué avec toute une après midi. ensuite j'ai fait [^A] [Suppr.] [^W] et je suis retourné jouer à mon jeu vidéo du moment en promettant de ne jamais plus toucher à ce truc

---

Pour info j'ai découvert ça en me rendant compte que le code source de la page d'accueil du site WoW Fr était du XML et ça m'a interloqué.

[Xenos]

Trop tard, j'ai déjà appris le XSLT :p Tant pis, je serais vieux, grincheux, boutonneux, célibataire et avec le spaghetti tout mou...

HTML simple ou pas, on se retrouvera toujours coincé par la liste des balises admissibles... Impossible d'avoir une balise <carte> contenant des balises <case> avec des <batiment>... D'accord, je peux faire des <div> ou autre avec des "data-class='batiment'", mais c'est non seulement bien plus verbeux, mais aussi bien moins aisé à lire.

Pourquoi beurks-tu le XML, niahoo?
Ok, le XSLT, je conçois que c'est assez... exotique, sans pour autant être totalement invivable (on s'y habitue finalement, même si niveau "fonctions déjà faites", c'est le désert...). C'est un langage exotique, mais c'est aussi un langage fonctionnel

...Il s'avère donc impossible de remplacer inc(i) + inc(i) par 2 * inc(i) car la valeur de inc(i) (function inc(i){global i; i++}) diffère à chaque appel. À l'échelle d'un programme important, cela signifie que le remplacement d'une fonction par une autre peut nécessiter des modifications à d'autres endroits du programme, et qu'il peut s'avérer nécessaire de retester l'intégralité du système, car on n'est pas assuré qu'un tel remplacement n'a pas modifié son comportement global. Au fur et à mesure que la complexité du système augmente, le coût d'un changement s'accroît aussi. À l'inverse, la propriété de transparence référentielle permet d'assurer que le remplacement d'une fonction par une autre équivalente ne risque pas de modifier le comportement global du programme. Autrement dit, elles sont mathématiquement égales. Cette propriété facilite la maintenance logicielle. Elle permet aussi d'appliquer de façon automatique des preuves de fonctionnement. Elle a enfin pour autre avantage de sensiblement réduire l'importance de l'ordre d'exécution, celui-ci étant assuré par l'ordre d'appel des fonctions ; un corollaire est que la parallélisation d'un programme fonctionnel peut être réalisée de façon automatique et que les optimisations que peuvent effectuer les compilateurs sont plus faciles à mettre en œuvre.

En termes simples: avec XSLT, on n'a pas le même fonctionnement, mais on peut faire des petites boites et les changer à la volée sans aucun impact sur l'ensemble du code final: stable et maintenable.

Ok, Sephi, je prend note. J'irai voir ces API javascript et la page google dans le week end.

[niahoo]

Je parlais d'un point de vue externe si je voulais parser tes données : un <carte> ou un <div.carte> c'est pareil pour moi, du moment que je le sais.