C'est vrai, mais ça nécessite de penser le DTD de son format xml en fonction du rendu final, ce qui est contraire à l'esprit. De plus, si il y a plusieurs sorties totalement différentes (xhtml, pdf...), ça devient quasi-impossible. Et je ne parle même pas du cas où le format de sortie change : il faudrait alors revoir son format xml de stockage de donnée brute parce que le format proposé au monde extérieur a changé ?
Quant au parsages gourmands, rien à dire sur l'état actuel des choses, mais je ferais remarquer que même si ça serait bien compliqué à implémenter, rien n'interdit d'envisager un système à la templeet, avec système de cache à tous les étages, sauf que le langage de templates serait xslt (après tout, dans le cas d'un site web, rien n'oblige que le traitement du fichier de style xls se fasse côté client. J'irais même plus loin : templeet a prouvé que ça pouvait être bien plus malin de faire la chose côté serveur de façon à ne faire les choses qu'une fois, et non pas une fois par client, même si ça soulagerait le serveur ;). Bref, ce n'est pas une limitation intrinséque au language à mon avis, mais bien un problème qui pourrait être grandement aplani via une implémentation performante.
En attendant, xml+xlst est déjà un couple formidable pour automatiser la gestion et les mises à jour d'un site statique, ou même dynamique en intégrant du php au fichier transformé qui sera utilisé pour le site.
[^] # Re: Comprendre XSLT, critique du livre
Posté par JSL . En réponse à la dépêche Comprendre XSLT, critique du livre. Évalué à 1.
Quant au parsages gourmands, rien à dire sur l'état actuel des choses, mais je ferais remarquer que même si ça serait bien compliqué à implémenter, rien n'interdit d'envisager un système à la templeet, avec système de cache à tous les étages, sauf que le langage de templates serait xslt (après tout, dans le cas d'un site web, rien n'oblige que le traitement du fichier de style xls se fasse côté client. J'irais même plus loin : templeet a prouvé que ça pouvait être bien plus malin de faire la chose côté serveur de façon à ne faire les choses qu'une fois, et non pas une fois par client, même si ça soulagerait le serveur ;). Bref, ce n'est pas une limitation intrinséque au language à mon avis, mais bien un problème qui pourrait être grandement aplani via une implémentation performante.
En attendant, xml+xlst est déjà un couple formidable pour automatiser la gestion et les mises à jour d'un site statique, ou même dynamique en intégrant du php au fichier transformé qui sera utilisé pour le site.