Intérêt de XML+XSLT vs XHTML classique [résolu]

Bonjour à tous.

Mise en garde : Ceci n'est pas un troll vendredesque mais bien une question sérieuse. D'ailleurs n'hésitez pas à déplacer ce topic dans un forum adéquat si nécessaire.

Cette nuit durant mes parcours webesques de geek insomniaque, je découvre un truc qui répond au nom de XSLT.
Ca a l'air pas mal comme truc... mais je me posais une question.
Aucun des tutoriels qu'on trouve à la pelle en français ou anglais grâce à notre meilleur ami ne m'a donné la réponse... les dits tutoriels se dirigeant immédiatement sur la syntaxe et le fonctionnement sans se poser d'autre question.

Quel est l'intérêt de faire un site web en XML+XSLT côté client plutôt que de délivrer des pages (X)HTML classiques ?

Ca a l'air peu utilisé... pourtant ça a l'air de passer même avec IE6.

Merci.
Modifié par QuentinC (25 Oct 2008 - 18:09)

Hello Quentin

Pour moi l'intérêt c"est qu'XML est multi-usage : tu en fais du Xhtml par XSLT, tu peux en faire du PDF, etc. bref, toutes sortes de réutilisations.
Il y a quelques années un pote à moi bossait dans une boite où ils ont monté un outil pour transcoder de l'Xpress (outil PAO) en XML, à partir de quoi ils ont pu "webiser" tous les documents Xpress (gros catals de VPC). Il serait sûrement possible d'effectuer l'opération inverse : transformer un site web en doc Xpress.
C'est plus à prendre comme un langage amont que comme une alternative possible à Xhtml.

- Tu diminue la charge serveur (tous ce qui est censé effectuer le moteur de template)
- Tu facilité un changement de type d'output (html, xhtml, pdf, etc...)

Par contre, tu te coupe des navigateurs n'ayant pas implémenté xsl.. (Niveau accessibilité, ce n'est pas top du coup)

Un choix à faire...

Bonjour,

En 2003, déjà...

OK. Donc dans le cadre d'un site web aucun intérêt et c'est même déconseillé (cf lien de LD)

Oui et non. Tel quel, sûrement. Mais importer des fichiers XML ayant leur utilité par ailleurs et tranformer le balisage auteur (<fiche><nom> par ex) par une simple regex (ou un tout bête str_replace) en balisage HTML rend de très grands services. Pas de XSLT dans ce cas... c'est ça qui pose problème, pas XML en soi. Faut le prendre comme une structuration en amont, pas comme alternative à Xhtml comme dit juste avant.
Modifié par Arsene (24 Oct 2008 - 12:45)

Arsene a écrit :
Faut le prendre comme une structuration en amont, pas comme alternative à Xhtml comme dit juste avant.

+1.

Juste une chose qui n'a pas été évoquée jusqu'ici dans ce sujet, il est tout à fait possible d'effectuer cette transformation du côté serveur afin de pallier aux manquements de certains navigateurs (alors oui ça peut sembler peut-être moins fun que côté client mais bon).

Je ne peux que plussoyer à ce qui a été dit : XSLT côté client, c'est une mauvaise idée. J'ai bien une page ou deux dans mes cours qui en parle, mais cela fait une éternité que je ne la maintiens plus, et en tout cas que je n'en parle plus à mes étudiants. L'intérêt était plus pédagogique qu'autre chose : les amener à amorcer d'eux-mêmes la réflexion sur l'utilité de mettre en page convenablement leur code, quand je les confrontais à des transformations XSLT combinées avec du JavaScript (aaah, les indexations de tableau commençant à 0 en JavaScript couplées à des expressions XPath pour lesquelles la numérotation commence à 1, avec des crochets dans tous les sens...)

Je ne me sers maintenant de la transformation côté client qu'en développement : cela me permet de tester rapidement ma feuille de style en local, sans avoir à basculer sur un serveur mon fichier : j'ouvre mon fichier XML avec l'appel dynamique à la feuille de style, et après je n'ai plus qu'à bosser sur elle et à faire de temps en temps des F5 dans mon navigateur. Ensuite seulement, je retire l'appel à la feuille de style et j'envoie le tout sur le serveur.

a écrit :
Juste une chose qui n'a pas été évoquée jusqu'ici dans ce sujet, il est tout à fait possible d'effectuer cette transformation du côté serveur afin de pallier
aux manquements de certains navigateurs (alors oui ça peut sembler peut-être moins fun que côté client mais bon).

Ca paraît surtout extrêmement lourd par rapport aux ressources nécessaires pour envoyer directement une page XHTML normale.

Merci pour les éclaircissements. Je laisse encore le sujet ouvert mais je le passerai en résolu demain s'il n'y a pas de nouveaux apports.

QuentinC a écrit :
Ca paraît surtout extrêmement lourd par rapport aux ressources nécessaires pour envoyer directement une page XHTML normale.

En effet, cela peut paraître extrêmement lourd ... mais c'est à mon sens une (excellente) solution pour un système de templates.

En ce qui concerne les ressources nécessaires, il serait intéressant d'avoir des retours là-dessus (charge serveur et cetera) ... si quelqu'un à des documents ou des études à ce sujet, je suis preneur ...

PS : il me semble que dans le livre "PHP 5 avancé" d'Eric Daspet, il est dit que les ressources consommées par une telle solution ne sont pas spécialement beaucoup plus élevés qu'une autre solution.

J'ai aussi lu par ci par là que depuis php 5 tout ce qui concerne la manipulation d'XML a grandement été améliorer grace a la classe DOMDocument , y compris les transformations XSLT (gérer auparavant par le gourmand sablotron).

En ce qui me concerne je trouve que XSL répond parfaitement bien aux problématiques d'une pattern MVC.

Dans le cas du moteur de tamplate, ça me paraît surtout lourd parce que :
De toute façon, il faut bien le générer, le XML de départ. Générer du XML format perso ou du XHTML bien structuré directement, ça ne fait pas grande différence pour un script php, je pense. Par contre après le XML il faut le passer à la moulinette supplémentaire XSLT. Ca fait une étape de plus dans le processus, c'est donc à priori plus long. Evidemment c'est de l'à-priori donc c'est peut-être faux. Quelqu'un a une preuve ou une contre-preuve ?

Oui, tu as entièrement raison, la structure
BDD -> XML -> XHTML
est plus lourde que BDD->XHTML.
(BDD = Base De Donnée)


Seulement voila, dans beaucoup de cas cette étape intermediaire va permettre de multiplié les rendus :
BDD -> XML
puis
XML -> XHTML ou XML->HTML4 ou XML->PDF ou XML->Flash etc ...

Quelque soit le rendu, la couche BDD->XML est la même.
L'action qui génère le XML est toujours la même.

Par exemple sur un site de e-commerce tu peut proposer à tes clients de consulter leurs factures au format HTML comme au format PDF.
le XML servant a générer les 2 format est le même, tu n'aura a developper qu'une seule action php et 2 template XSL (un pour HTML l'autre pour PDF).
Sur une autre page tu peux lui afficher un tableau récapitulatif de ses achats au format HTML, puis réutiliser le même XML qui à servit a afficher ce tableau html pour en faire des courbes sous Flash ou avec une transformation XSLT sortir un SVG, pourquoi pas même un format exel.

La donnée et totalement séparer de son rendu, c'est ça la puissance du XSL.
Modifié par Citron.mecanik (25 Oct 2008 - 15:22)

Avec ce dernier post, cette fois-ci le sujet est définitivement résolu. Enfin, je pense.
Merci à tous les intervenants.

P.S. Si vous avez quelque chose à ajouter, même si le sujet est résolu, n'hésitez pas.
Modifié par QuentinC (25 Oct 2008 - 18:08)