XSLT en vaut-il la peine?
Il y a quelque temps, j'ai commencé un projet où j'ai conçu un schéma XML html-esque afin que les auteurs puissent écrire leur contenu (matériel pédagogique) dans un format simplifié qui serait ensuite transformé en HTML via XSLT. J'ai joué avec (me suis débattu) pendant un certain temps et je suis arrivé à un niveau très basique, mais j'étais trop ennuyé par les limites que je rencontrais (qui pourraient bien être des limites de mes connaissances) et quand j'ai lu un blog suggérant d'abandonner XSLT et écrivez simplement votre propre analyseur XML vers n'importe quel dans la langue de votre choix, je me suis empressé de sauter dessus et cela a fonctionné brillamment.
J'y travaille encore à ce jour ( je suis en fait censé y travailler en ce moment, au lieu de jouer sur SO), et je vois de plus en plus de choses qui font je pense que la décision d'abandonner XSLT a été bonne.
Je sais que XSLT a sa place, en ce sens que c'est une norme acceptée, et que si tout le monde écrit ses propres interprètes, 90% d'entre eux se retrouveront sur TheDailyWTF . Mais étant donné qu'il s'agit d'un langage de style fonctionnel au lieu du style procédural que la plupart des programmeurs connaissent, pour quelqu'un qui se lance dans un projet comme le mien, voudriez-vous recommandent-ils de suivre le chemin que j'ai suivi ou de le respecter avec XSLT ?
Avantages de XSLT:
- Spécifique au domaine pour XML, donc par exemple pas besoin de citer le littéral XML dans la sortie.
- Prend en charge XPath/XQuery, qui peut être un bon moyen d'interroger les DOM, de la même manière que les expressions régulières peuvent être un bon moyen d'interroger des chaînes.
- Langage fonctionnel.
Inconvénients de XSLT:
- Peut être obscurément verbeux - vous n'avez pas à citer le XML littéral, ce qui signifie effectivement que vous devez citer le code. Et pas d'une jolie manière. Mais là encore, ce n'est pas bien pire que votre SSI typique.
- Ne fait pas certaines choses que la plupart des programmeurs tiennent pour acquises. Par exemple, la manipulation de chaînes peut être une corvée. Cela peut conduire à des "moments malheureux" lorsque les novices conçoivent du code, puis recherchent frénétiquement sur le Web des astuces pour implémenter des fonctions qu'ils supposaient être là et ne se donnaient pas le temps d'écrire.
- Langage fonctionnel.
Soit dit en passant, une façon d'obtenir un comportement procédural est de chaîner plusieurs transformations ensemble. Après chaque étape, vous avez un tout nouveau DOM à travailler qui reflète les changements de cette étape. Certains processeurs XSL ont des extensions pour le faire efficacement en une seule transformation, mais j'oublie les détails.
Donc, si votre code est principalement produit et pas beaucoup de logique, XSLT peut être un moyen très soigné de l'exprimer. S'il y a beaucoup de logique, mais surtout de formes intégrées à XSLT (sélectionnez tous les éléments qui ressemblent à blah et pour chaque sortie blah), il est probable que ce soit un environnement assez convivial. Si vous avez envie de penser à XML en permanence, essayez XSLT 2.
Sinon, je dirais que si votre langage de programmation préféré a une bonne implémentation DOM prenant en charge XPath et vous permettant de créer des documents de manière utile, l'utilisation de XSLT présente peu d'avantages. Les liaisons vers libxml2 et gdome2 devraient bien fonctionner, et il n'y a aucune honte à s'en tenir aux langages à usage général que vous connaissez bien.
Les analyseurs XML faits maison sont généralement soit incomplets (auquel cas vous vous décollez un jour), soit pas beaucoup plus petits que quelque chose que vous auriez pu obtenir sur le marché (auquel cas vous perdez probablement votre temps), et donnez vous un certain nombre d'occasions d'introduire de graves problèmes de sécurité autour des entrées malveillantes. N'en écrivez pas à moins de savoir exactement ce que vous gagnez en le faisant. Ce qui ne veut pas dire que vous ne pouvez pas écrire un analyseur pour quelque chose de plus simple que XML comme format d'entrée, si vous n'avez pas besoin de tout ce que XML offre.
Tant de négativité!
J'utilise XSLT depuis quelques années maintenant et je l'adore vraiment. La chose clé que vous devez réaliser est que ce n'est pas un langage de programmation, c'est un langage de modèles (et à cet égard, je le trouve indescriptiblement supérieur à asp.net/spit).
XML est le format de données de facto du développement web aujourd'hui, qu'il s'agisse de fichiers de configuration, de données brutes ou de représentation en mémoire. XSLT et XPath vous offrent un énormément moyen puissant et très efficace de transformer ces données en n'importe quel format de sortie que vous pourriez aimer, vous donnant instantanément cet aspect MVC de séparation de la présentation des données.
Ensuite, il y a les capacités utilitaires: nettoyer les espaces de noms, reconnaître les définitions de schéma disparates, fusionner les documents.
Il doit mieux vaut gérer XSLT que développer vos propres méthodes internes. Au moins XSLT est une norme et quelque chose que vous pourriez louer, et si c'est vraiment vraiment un problème pour votre équipe, c'est la nature même qui vous permettrait de garder la plupart de votre équipe travaillant avec seulement XML.
Un cas d'utilisation réel: je viens d'écrire une application qui gère les documents XML en mémoire dans tout le système et se transforme en JSON, HTML ou XML comme demandé par l'utilisateur final. J'ai eu une demande assez aléatoire pour fournir des données Excel. Un ancien collègue avait fait quelque chose de similaire par programme mais cela nécessitait un module de quelques fichiers de classe et que le serveur avait MS Office installé! Il s'avère qu'Excel a un XSD: nouvelle fonctionnalité avec un impact minimal sur le code de base en 3 heures.
Personnellement, je pense que c'est l'une des choses les plus propres que j'ai rencontrées dans ma carrière, et je pense que tous ses problèmes apparents (débogage, manipulation de chaînes, structures de programmation) sont dus à une mauvaise compréhension de l'outil.
Évidemment, je crois fermement que cela "en vaut la peine".
Je dois admettre un parti pris ici parce que j'enseigne le XSLT pour vivre. Mais, cela vaut peut-être la peine de couvrir les domaines dans lesquels je vois mes étudiants travailler. Ils se répartissent généralement en trois groupes: l'édition, la banque et le Web.
Jusqu'à présent, bon nombre des réponses peuvent être résumées comme suit: "ce n'est pas bon pour créer des sites Web" ou "ce n'est pas comme le langage X". De nombreux techniciens suivent leur carrière sans être exposés à des langages fonctionnels/déclaratifs. Quand j'enseigne, les gens expérimentés Java/VB/C/etc sont ceux qui ont des problèmes avec le langage (les variables sont des variables au sens de l'algèbre et non de la programmation procédurale par exemple). C'est beaucoup de gens qui répondent ici - je ne me suis jamais entendu avec Java mais je ne vais pas prendre la peine de critiquer le langage à cause de cela.
Dans de nombreuses circonstances, il s'agit d'un outil inapproprié pour créer des sites Web - un langage de programmation à usage général peut être préférable. J'ai souvent besoin de prendre de très gros documents XML et de les présenter sur le Web; XSLT rend cela trivial. Les étudiants que je vois dans cet espace ont tendance à traiter des ensembles de données et à les présenter sur le Web. XSLT n'est certainement pas le seul outil applicable dans cet espace. Cependant, beaucoup d'entre eux utilisent le DOM pour ce faire et XSLT est certainement moins douloureux.
Les étudiants en banque que je vois utilisent une boîte DataPower en général. Il s'agit d'un appareil XML et il est utilisé pour s'asseoir entre des services parlant différents dialectes XML. La transformation d'un langage XML à un autre est presque triviale en XSLT et le nombre d'étudiants qui suivent mes cours sur ce sujet augmente.
Le dernier groupe d'étudiants que je vois vient d'un milieu de l'édition (comme moi). Ces personnes ont tendance à avoir d'immenses documents en XML (croyez-moi, la publication en tant qu'industrie est très en XML - la publication technique existe depuis des années et l'édition commerciale y arrive maintenant). Ces documents doivent être traités (DocBook to ePub me vient à l'esprit ici).
Quelqu'un ci-dessus a déclaré que les scripts avaient tendance à être inférieurs à 60 lignes ou qu'ils devenaient trop lourds. Si cela devient difficile à manier, il y a de fortes chances que le codeur n'ait pas vraiment compris l'idée - XSLT est un état d'esprit très différent de beaucoup d'autres langues. Si vous ne comprenez pas l'état d'esprit, cela ne fonctionnera pas.
Ce n'est certainement pas une langue mourante (la quantité de travail que je reçois me le dit). En ce moment, c'est un peu "bloqué" jusqu'à ce que Microsoft termine sa mise en œuvre (très tardive) de XSLT 2. Mais il est toujours là et semble aller fort de mon point de vue.
Nous utilisons largement XSLT pour des choses comme la documentation et pour rendre certains paramètres de configuration complexes utilisables par l'utilisateur.
Pour la documentation, nous utilisons beaucoup de DocBook, qui est un format basé sur XML. Cela nous permet de stocker et de gérer notre documentation avec tout notre code source, car les fichiers sont en texte brut. Avec XSLT, nous pouvons facilement créer nos propres formats de documentation, ce qui nous permet à la fois de générer automatiquement le contenu de manière générique et de rendre le contenu plus lisible. Par exemple, lorsque nous publions des notes de publication, nous pouvons créer du XML qui ressemble à quelque chose comme:
<ReleaseNotes>
<FixedBugs>
<Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
<Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
<Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
</FixedBugs>
</ReleaseNotes>
Et puis en utilisant XSLT (qui transforme ce qui précède en DocBook), nous nous retrouvons avec des notes de version de Nice (PDF ou HTML généralement) où les ID de bogue sont automatiquement liés à notre outil de suivi des bogues, les bogues sont regroupés par composant et le format de tout est parfaitement cohérent . Et le XML ci-dessus peut être généré automatiquement en interrogeant notre outil de suivi des bogues pour savoir ce qui a changé entre les versions.
L'autre endroit où nous avons trouvé XSLT utile est en fait dans notre produit principal. Parfois, lors de l'interfaçage avec des systèmes tiers, nous devons en quelque sorte traiter les données dans une page HTML complexe. L'analyse HTML est moche, donc nous alimentons les données à travers quelque chose comme TagSoup (qui génère des événements XML SAX appropriés, nous permettant essentiellement de traiter le HTML comme s'il était correctement écrit XML), puis nous pouvons en exécuter XSLT contre lui, pour transformer les données en un format "stable connu" avec lequel nous pouvons réellement travailler. En séparant cette transformation en un fichier XSLT, cela signifie que si et lorsque le format HTML change, l'application elle-même n'a pas besoin d'être mise à niveau, mais l'utilisateur final peut simplement modifier le fichier XSLT lui-même, ou nous pouvons envoyer un courrier électronique leur un fichier XSLT mis à jour sans que l'ensemble du système ait besoin d'être mis à niveau.
Je dirais que pour les projets Web, il existe de meilleures façons de gérer la vue que XSLT aujourd'hui, mais en tant que technologie, il existe certainement des utilisations pour XSLT. Ce n'est pas la langue la plus facile à utiliser au monde, mais elle n'est certainement pas morte, et de mon point de vue, elle a encore beaucoup de bonnes utilisations.
XSLT est un exemple de langage programmation déclarative .
D'autres exemples de langages de programmation déclaratifs incluent les expressions régulières, Prolog et SQL. Tous ces éléments sont très expressifs et compacts, et généralement très bien conçus et puissants pour la tâche pour laquelle ils sont conçus.
Cependant, les développeurs de logiciels détestent généralement ces langages, car ils sont si différents des langages plus courants OO ou procéduraux qu'ils sont difficiles à apprendre et à déboguer. Leur nature compacte le rend généralement très facile à faire beaucoup de dégâts par inadvertance.
Ainsi, bien que XSLT soit un mécanisme efficace pour fusionner des données dans une présentation, il échoue dans le département de facilité d'utilisation. Je crois que c'est pourquoi cela n'a pas vraiment fait son chemin.
Je me souviens de tout le battage médiatique autour de XSLT lorsque la norme a été récemment publiée. Toute l'excitation de pouvoir construire une interface HTML complète avec une transformation "simple".
Avouons-le, il est difficile à utiliser, presque impossible à déboguer, souvent insupportablement lent. Le résultat final est presque toujours décalé et loin d'être idéal.
Je vais plus tôt ronger ma propre jambe que d'utiliser un XSLT alors qu'il existe de meilleures façons de faire les choses. Pourtant, il a sa place, son bon pour les tâches de transformation simples.
J'ai beaucoup utilisé XSLT (et aussi XQuery) pour diverses choses - pour générer du code C++ dans le cadre du processus de construction, pour produire de la documentation à partir de commentaires de doc, et dans une application qui devait travailler avec XML en général et XHTML en particulier beaucoup . Le générateur de code en particulier comptait plus de 10 000 lignes de code XSLT 2.0 réparties autour d'une douzaine de fichiers distincts (il faisait beaucoup de choses - en-têtes pour les clients, procurations/talons distants, wrappers COM, wrappers .NET, ORM - pour ne nommer que quelques). Je l'ai hérité d'un autre gars qui ne comprenait pas vraiment bien la langue, et les morceaux les plus anciens étaient donc un vrai gâchis. Cependant, les nouvelles choses que nous avons écrites sont restées généralement saines et lisibles, et je ne me souviens d'aucun problème particulier pour y parvenir. Ce n'était certainement pas plus difficile que de le faire pour C++.
En parlant de versions, traiter avec XSLT 2.0 vous aide certainement à rester sain d'esprit, mais 1.0 est toujours correct pour des transformations plus simples. Dans son créneau, c'est un outil extrêmement pratique, et la productivité que vous obtenez de certaines fonctionnalités spécifiques au domaine (surtout, la répartition dynamique via la correspondance de modèles) est difficile à égaler. Malgré la verbosité perçue de la syntaxe XML de XSLT, la même chose dans LINQ to XML (même dans VB avec les littéraux XML) était généralement plusieurs fois plus longue. Très souvent, cependant, cela devient un flack immérité en raison de l'utilisation inutile de XML dans certains cas en premier lieu.
Pour résumer: c'est un outil incroyablement utile à avoir dans sa boîte à outils, mais c'est un outil très spécialisé, donc il est bon tant que vous l'utilisez correctement et pour son usage prévu. Je souhaite vraiment qu'il y ait une implémentation .NET native appropriée de XSLT 2.0.
J'utilise XSLT (faute de meilleure alternative), mais pas pour la présentation, juste pour la transformation:
J'écris de courtes transformations XSLT pour effectuer des modifications de masse sur nos fichiers maven pom.xml.
J'ai écrit un pipeline de transformations pour générer des schémas XML à partir de XMI (diagramme UML). Cela a fonctionné pendant un certain temps, mais c'est finalement devenu trop complexe et nous avons dû le retirer derrière la grange.
J'ai utilisé des transformations pour refactoriser les schémas XML.
J'ai contourné certaines limitations de XSLT en l'utilisant pour générer un XSLT pour faire le vrai travail. (Avez-vous déjà essayé d'écrire un XSLT qui produit une sortie à l'aide d'espaces de noms inconnus jusqu'à l'exécution?)
Je continue d'y revenir parce qu'il fait un meilleur travail de détourner le XML qu'il traite que d'autres approches que j'ai essayées, qui ont semblé inutilement perdues ou simplement mal comprises XML. XSLT est désagréable, mais je trouve que l'utilisation de Oxygen le rend supportable.
Cela dit, j'envisage d'utiliser Clojure (un LISP) pour effectuer des transformations de XML, mais je ne suis pas encore allé assez loin pour savoir si cette approche m'apportera des avantages.
Personnellement, j'ai utilisé XSLT dans un contexte totalement différent. Le jeu informatique sur lequel je travaillais à l'époque utilisait des tonnes de pages d'interface définies en XML. Lors d'un remaniement majeur peu de temps après une version, nous voulions changer la structure de ces documents XML. Nous avons fait en sorte que le format d'entrée du jeu suive une structure bien meilleure et adaptée aux schémas.
XSLT semblait le choix parfait pour cette traduction de l'ancien format -> Nouveau format. En deux semaines, j'ai eu une conversion fonctionnelle de l'ancien au nouveau pour nos centaines de pages. J'ai également pu l'utiliser pour extraire de nombreuses informations sur la mise en page de nos pages d'interface utilisateur. J'ai créé des listes dont les composants étaient intégrés dans lesquels relativement facilement que j'ai ensuite utilisé XSLT pour écrire dans nos définitions de schéma.
De plus, venant d'un arrière-plan C++, c'était un langage très amusant et intéressant à maîtriser.
Je pense qu'en tant qu'outil pour traduire XML d'un format à un autre, c'est fantastique. Cependant, ce n'est pas le seul moyen de définir un algorithme qui prend XML comme entrée et sorties Quelque chose. Si votre algorithme est suffisamment complexe, le fait que l'entrée soit XML devient sans importance pour votre choix d'outil - c'est-à-dire que vous pouvez lancer le vôtre en C++/Python/peu importe.
Spécifique à votre exemple, j'imagine que la meilleure idée serait de créer votre propre conversion XML-> XML qui suit votre logique métier. Ensuite, écrivez un traducteur XSLT qui connaît simplement le formatage et ne fait rien d'intelligent. C'est peut-être un bon compromis, mais cela dépend totalement de ce que vous faites. La présence d'un traducteur XSLT sur la sortie facilite la création de formats de sortie alternatifs - imprimables, pour mobiles, etc.
Oui, je l'utilise beaucoup. En utilisant différents fichiers xslt, je peux utiliser la même source XML pour créer plusieurs fichiers polyglottes (X) HTML (présentant les mêmes données de différentes manières), un flux RSS, un Atom feed, un RDF fichier descripteur et fragment d'un plan du site.
Ce n'est pas une panacée. Il y a des choses qu'il fait bien, et des choses qu'il ne fait pas bien, et comme tous les autres aspects de la programmation, il s'agit d'utiliser le bon outil pour le bon travail. C'est un outil qui vaut bien d'avoir dans votre boîte à outils, mais il ne doit être utilisé que lorsque cela est approprié.
Je recommanderais certainement de le tenir. Surtout si vous utilisez Visual Studio qui a intégré des outils d'édition, de visualisation et de débogage pour XSLT.
Oui, c'est une douleur pendant que vous apprenez, mais la plupart de la douleur est liée à la familiarité. La douleur diminue à mesure que vous apprenez la langue.
W3schools a deux articles qui ont une valeur particulière: http://www.w3schools.com/xpath/xpath_functions.asphttp://www.w3schools.com/xsl/xsl_functions. asp
XSLT est difficile à utiliser, mais une fois que vous l'aurez conquis, vous aurez une compréhension très approfondie du DOM et du schéma. Si vous aussi XPath, alors vous êtes sur le point d'apprendre la programmation fonctionnelle et cela vous exposera à de nouvelles techniques et façons de résoudre les problèmes. Dans certains cas, la transformation successive est plus puissante que les solutions procédurales.
Je pensais que XSLT était une excellente idée. Je veux dire est une excellente idée.
Là où il échoue, c'est l'exécution.
Le problème que j'ai découvert au fil du temps était que les langages de programmation en XML ne sont qu'une mauvaise idée. Cela rend le tout impénétrable. Plus précisément, je pense que XSLT est très difficile à apprendre, à coder et à comprendre. Le XML en plus des aspects fonctionnels rend tout cela trop confus. J'ai essayé de l'apprendre environ 5 fois dans ma carrière, et ça ne colle pas.
OK, vous pouvez l'outiller - je pense que c'était en partie le but de sa conception - mais c'est le deuxième échec: tous les outils XSLT sur le marché sont, tout simplement ... merde!
J'ai utilisé XML, XSD et XSLT sur un projet d'intégration entre des systèmes de base de données très différents en 2004. J'ai dû apprendre XSD et XSLT à partir de zéro mais ce n'était pas difficile. La grande chose à propos de ces outils est qu'ils m'ont permis d'écrire du code C++ indépendant des données, en s'appuyant sur XSD et XSLT pour valider/vérifier puis transformer les documents XML. Modifiez le format des données, modifiez les documents XSD et XSLT et non le code C++ qui utilisait les bibliothèques Xerces.
Pour l'intérêt: le XSD principal était de 150 Ko et la taille moyenne du XSLT était <5 Ko IIRC.
L'autre grand avantage est que le XSD est un document de spécification sur lequel le XSLT est basé. Les deux travaillent en harmonie. Et les spécifications sont rares dans le développement de logiciels de nos jours.
Bien que je n'ai pas eu trop de mal à apprendre la nature déclarative XSD et XSLT, j'ai trouvé que d'autres programmeurs C/C++ avaient beaucoup de mal à s'adapter à la manière déclarative. Quand ils ont vu que c'était ça, ah procédurale ils ont marmonné, maintenant que je comprends! Et ils ont procédé (jeu de mots?) Pour écrire du XSLT procédural! La chose est que vous devez apprendre XPath et comprendre les axes de XML. Me rappelle les anciens programmeurs C s'adaptant à l'utilisation de OO lors de l'écriture de C++.
J'ai utilisé ces outils car ils m'ont permis d'écrire une petite base de code C++ qui était isolée de toutes les modifications de structure de données, sauf la plus fondamentale, et ces dernières étaient des modifications de structure de base de données. Même si je préfère le C++ à tout autre langage, j'utiliserai ce que je considère comme utile pour bénéficier de la viabilité à long terme d'un projet logiciel.
J'utilise beaucoup XSLT, pour un frontal de style MVC personnalisé. Le modèle est "sérialisé" en xml (pas via sérialisation xml), puis converti en html via xslt. L'avantage par rapport à ASP.NET réside dans l'intégration naturelle avec XPath et les exigences de forme bien plus rigoureuses (il est beaucoup plus facile de raisonner sur la structure du document dans xslt que dans la plupart des autres langues).
Malheureusement, le langage contient plusieurs limitations (par exemple, la possibilité de transformer la sortie d'une autre transformation), ce qui signifie qu'il est parfois frustrant de travailler avec.
Néanmoins, la séparation facilement réalisable et fortement appliquée des préoccupations qu'elle accorde n'est pas quelque chose que je vois une autre technologie fournir en ce moment - donc pour les documents transformés, c'est toujours quelque chose que je recommanderais.
J'ai trouvé que XSLT était assez difficile à travailler.
J'ai de l'expérience en travaillant sur un système quelque peu similaire à celui que vous décrivez. Mon entreprise a noté que les données que nous renvoyions du "niveau intermédiaire" étaient en XML, et que les pages devaient être rendues en HTML qui pourrait aussi bien être en XHTML, et ils avaient entendu dire que XSL était une norme pour la conversion entre XML formats. Les "architectes" (j'entends par là des gens qui pensent en profondeur mais qui ne codent apparemment pas) ont donc décidé que notre premier niveau serait implémenté en écrivant des scripts XSLT qui transformeraient les données en XHTML pour l'affichage.
Le choix s'est avéré désastreux. Il s'avère que le XSLT est pénible à écrire. Et donc toutes nos pages étaient difficiles à écrire et à maintenir. Nous aurions fait beaucoup mieux d'avoir utilisé JSP (c'était en Java) ou une approche similaire qui utilisait un type de balisage (crochets) pour le format de sortie (le HTML) et un autre type de balisage (comme <% ... %>) pour les métadonnées. La chose la plus déroutante à propos de XSLT est qu'il est écrit en XML et qu'il se traduit de XML en XML ... il est assez difficile de garder les 3 documents XML différents directement dans l'esprit.
Votre situation est légèrement différente: au lieu de créer chaque page en XSLT comme je l'ai fait, il vous suffit d'écrire UN bit de code en XSLT (le code à convertir des modèles à afficher). Mais il semble que vous ayez rencontré le même genre de difficulté que moi. Je dirais qu'essayer d'interpréter un simple DSL basé sur XML (langage spécifique au domaine) comme vous le faites n'est PAS l'un des points forts du XSLT. (Bien qu'il puisse faire le travail ... après tout, il IS Turing complet!)
Cependant, si ce que vous aviez était plus simple: vous avez des données dans un format XML et vouliez y apporter de simples modifications - pas une DSL de description de page complète, mais quelques modifications simples et simples, alors XSLT est un excellent outil à cet effet. Sa nature déclarative (et non procédurale) est en fait un avantage à cette fin.
- Michael Chermside
Cela se résume à ce dont vous avez besoin. Sa principale force est la facilité de maintenance de la transformation, et l'écriture de votre propre analyseur efface généralement cela. Cela dit, parfois un système est petit et simple et n'a vraiment pas besoin d'une solution "sophistiquée". Tant que votre générateur de code est remplaçable sans avoir à changer d'autre code, ce n'est pas grave.
Quant à la laideur de XSL, oui c'est moche. Oui, il faut un certain temps pour s'y habituer. Mais une fois que vous avez compris (cela ne devrait pas prendre longtemps IMO), la navigation est en douceur. D'après mon expérience, les transformations compilées s'exécutent assez rapidement et vous pouvez certainement les déboguer.
Le spécification XSLT définit XSLT comme "un langage pour transformer des documents XML en d'autres documents XML". Si vous essayez de faire autre chose que le traitement de données le plus basique dans XSLT, il y a probablement de meilleures solutions.
Il convient également de noter que les capacités de traitement des données de XSLT peuvent être étendues dans .NET à l'aide de fonctions d'extension personnalisées:
Je crois toujours que XSLT peut être utile, mais c'est un langage laid et peut conduire à un terrible gâchis illisible et incontrôlable. En partie parce que XML n'est pas suffisamment lisible par l'homme pour constituer un "langage" et en partie parce que XSLT est coincé entre être déclaratif et procédural. Cela dit, et je pense qu'une comparaison peut être établie avec des expressions régulières, elle a ses utilités lorsqu'il s'agit de problèmes simples et bien définis.
L'utilisation de l'approche alternative et de l'analyse XML dans le code peut être tout aussi désagréable et vous voulez vraiment utiliser une sorte de technologie de marshaling/liaison XML (comme JiBX en Java) qui convertira directement votre XML en objet.
Je maintiens un système de documentation en ligne pour mon entreprise. Les rédacteurs créent la documentation en SGML (un langage similaire à xml). Le SGML est ensuite combiné avec XSLT et transformé en HTML.
Cela nous permet de modifier facilement la mise en page de la documentation sans faire de codage. C'est juste une question de changer le XSLT.
Cela fonctionne bien pour nous. Dans notre cas, c'est un document en lecture seule. L'utilisateur n'interagit pas avec la documentation.
De plus, en utilisant XSLT, vous travaillez plus près de votre domaine problématique (HTML). Je considère toujours que c'est une bonne idée.
Enfin, si votre système actuel fonctionne, laissez-le tranquille. Je ne suggérerais jamais de jeter votre code existant. Si je partais de zéro, j'utiliserais XSLT, mais dans votre cas, j'utiliserais ce que vous avez.
Si vous pouvez utiliser XSLT dans un style déclaratif (même si je ne suis pas entièrement d'accord pour dire qu'il s'agit d'un langage déclaratif), je pense qu'il est utile et expressif.
J'ai écrit des applications Web qui utilisent un langage OO (C # dans mon cas) pour gérer la couche de données/traitement, mais produisent du XML plutôt que du HTML. Cela peut ensuite être consommé directement par les clients en tant que une API de données, ou rendue au format HTML par les XSLT. Comme le C # produisait du XML structurellement compatible avec cette utilisation, il était très fluide et la logique de présentation était déclarative. Il était plus facile de suivre et de modifier que d'envoyer les balises depuis C #.
Cependant, comme vous avez besoin de plus de logique de traitement au niveau XSLT, cela devient compliqué et verbeux - même si vous "obtenez" le style fonctionnel.
Bien sûr, ces jours-ci, j'aurais probablement écrit ces applications Web à l'aide d'une interface RESTful - et je pense que les "langages" de données tels que JSON gagnent du terrain dans les domaines où XML a traditionnellement été transformé par XSLT. Mais pour l'instant XSLT est toujours une technologie importante et utile.
Dans une entreprise précédente, nous avons beaucoup fait avec XML et XSLT. XML et XSLT gros.
Oui, il existe une courbe d'apprentissage, mais vous disposez alors d'un outil puissant pour gérer XML. Et vous pouvez même utiliser XSLT sur XSLT (ce qui peut parfois être utile).
Les performances sont également un problème (avec un XML très volumineux), mais vous pouvez y remédier en utilisant le XSLT intelligent et en effectuant un prétraitement avec le XML (généré).
Toute personne connaissant XSLT peut modifier l'apparence du produit fini car il n'est pas compilé.
J'ai déjà utilisé XSLT. Le groupe de 6 fichiers .xslt (refactorisé sur un grand) était d'environ 2750 lignes bien avant que je ne le réécris en C #. Le code C # est actuellement de 4000 lignes contenant beaucoup de logique; Je ne veux même pas penser à ce que cela aurait pris pour écrire en XSLT.
Le point où j'ai abandonné, c'est quand j'ai réalisé que ne pas avoir XPATH 2.0 nuisait considérablement à mes progrès.
Pour répondre à vos trois questions:
- J'ai utilisé XSLT il y a quelques années.
- Je crois que XSLT pourrait être la bonne solution dans certaines circonstances. (Ne jamais dire jamais)
- J'ai tendance à être d'accord avec votre appréciation selon laquelle elle est surtout utile pour les transformations "simples". Mais je pense que tant que vous comprenez bien le XSLT, il y a lieu de l'utiliser pour des tâches plus importantes telles que la publication d'un site Web au format XML transformé en HTML.
Je crois que la raison pour laquelle de nombreux développeurs n'aiment pas XSLT est qu'ils ne comprennent pas le paradigme fondamentalement différent sur lequel il est basé. Mais avec l'intérêt récent pour la programmation fonctionnelle, nous pourrions voir XSLT faire un retour ...
J'ai passé beaucoup de temps dans XSLT et j'ai découvert que même si c'est un outil utile dans certaines situations, ce n'est certainement pas une solution miracle. Il fonctionne très bien à des fins B2B lorsqu'il est utilisé pour la traduction de données pour les entrées/sorties XML lisibles par machine. Je ne pense pas que vous soyez sur la mauvaise voie dans votre énoncé de ses limites. L'une des choses qui m'a le plus frustré a été les nuances dans les implémentations de XSLT.
Vous devriez peut-être consulter certains des autres langages de balisage disponibles. Je crois que Jeff a fait un article sur ce sujet concernant Stack Overflow.
HTML est-il un langage de balisage humain?
Je regarderais ce qu'il a écrit. Vous pouvez probablement trouver un progiciel qui fait ce que vous voulez "prêt à l'emploi", ou du moins très proche au lieu d'écrire vos propres trucs à partir de zéro.
Un endroit où xslt brille vraiment est de générer des rapports. J'ai trouvé qu'un processus en 2 étapes, avec la première étape exportant les données du rapport sous forme de fichier xml, et la deuxième étape générant le rapport visuel à partir du xml en utilisant xslt. Cela permet des rapports visuels Nice tout en conservant les données brutes comme mécanisme de validation si besoin est.
Personnellement, j'aime XSLT, et vous voudrez peut-être donner à la syntaxe simplifiée (pas de modèles explicites, juste un vieux fichier HTML ordinaire avec quelques balises XSLT pour y cracher des valeurs), mais ce n'est pas pas pour tout le monde.
Peut-être que vous voulez simplement offrir à vos auteurs une interface Wiki ou Markdown simple. Il existe également des bibliothèques pour cela, et si XSLT ne fonctionne pas pour vous, peut-être que XML ne fonctionne pas non plus pour eux.
Je suis actuellement chargé de gratter les données d'un site public (ouais, je sais). Heureusement, il est conforme à xhtml, je peux donc utiliser xslt pour collecter les données dont j'ai besoin. La solution résultante est lisible, propre et facile à changer en cas de besoin. Parfait!
Je pense que vous avez fait la bonne chose. D'après mon expérience, les développeurs XSLT sont parmi les plus difficiles à embaucher, car c'est un langage qui n'a jamais attiré l'attention des développeurs Web ni des programmeurs occasionnels.
Vous finissez donc par devoir payer la prime "programmeur avancé qui connaît une langue en dehors du courant dominant", mais pour une langue qui n'est probablement pas la préférée de ce programmeur.
J'ai eu une assez bonne expérience avec XSLT, mais je ne me transformais pas en HTML. Il se peut que le combo XSLT-HTML soit très difficile à faire avancer les choses.
À mon avis, oui.
Pour un excellent exemple d'une utilisation vraiment cool de XSLT, consultez le World of Warcraft Armory de Blizzard.
XSLT 1.0 est l'un des codes les plus portables, au moins sur les ordinateurs de bureau et serveurs. Parce qu'il a un (et souvent plusieurs) runtime sur la plupart de ces systèmes:
- Microsoft Windows a MSXML qui est installé dans le système de base depuis au moins Windows 2000. Il peut être utilisé à la fois à partir de MSIE, à partir de la ligne de commande (à l'aide de WSH) ou à partir d'applications Office
- Java Runtime Environment (JRE) a un runtime XSLT, et un JRE est installé sur la plupart des bureaux)
- Presque tous les principaux navigateurs Web en ont un. Opera est l'exception.
- Il existe des implémentations gratuites installées par défaut sur les principaux systèmes d'exploitation basés sur GNU (libxslt, xsltproc)
- Je n'ai pas vérifié MacOS X, mais il a au moins une implémentation dans Safari
Cela en fait un bon choix pour créer certaines applications qui nécessitent à la fois une portabilité et une installation légère/sans installation.
De plus, XSLT nécessite uniquement un runtime (aucun compilateur nécessaire) et vous pouvez créer le code avec n'importe quel éditeur de texte. Vous pouvez donc créer des programmes facilement (enfin, une fois que vous maîtrisez la langue) à partir de n'importe quel bureau.
J'ai beaucoup utilisé XSLT ... pendant quelques heures. C'est cool pour des choses comme changer les noms des éléments ou filtrer un document d'entrée (supprimer les choses dont vous n'avez pas besoin).
Tout le reste devient complexe très rapidement. Cette complexité héritée ainsi que le manque de la plupart des choses que vous utilisez dans tous les autres langages de programmation (comme les variables) et les moyens faciles de rendre les expressions XPath illisibles, sont vraiment blessants.
En fin de compte, XSLT souffre d'un schisme: les programmeurs ne l'aiment pas en raison des limitations et tout le monde ne peut pas l'utiliser du tout (par exemple, les concepteurs de sites Web ou tout autre type non programmeur).
Si XSLT avait été promu comme une sorte de SQL pour XML, les choses seraient un peu différentes. Tout d'abord, les gens n'auraient même pas pris la peine de le regarder. Et ceux qui l'ont fait n'auraient pas été surpris par la douleur.
Je pense que le concept est solide, peut-être que l'exécution n'est pas aussi "propre" qu'elle pourrait l'être.
Cependant, je pense qu'il doit être traité comme un outil, il n'est peut-être pas judicieux de l'utiliser dans tous les cas, mais il ne faut jamais ignorer un outil lors de la résolution de solutions.
J'ai vu un très bon XSLT, et aussi une très mauvaise utilisation du XSLT, et je conclus que cela peut être en partie dû à la compétence du développeur. Je pense que c'est celui qui nécessite que le développeur pense dans plusieurs domaines en même temps.
Est-ce l'avenir? peut-être pas, il y a peut-être de meilleures solutions ..
Je ne sais pas quelle nouvelle technologie va arriver, mais au moins de son mieux pour l'apprendre, augmenter ses propres outils ne peut certainement pas être une mauvaise chose?
J'utilise XSLT pour corriger des erreurs dans des fichiers xml très complexes. Donc, au lieu de gérer les erreurs dans le xml, j'utilise xslt pour les corriger.
C'est bien. Parce que le langage est si puissant et qu'il s'adapte au cas d'utilisation xml. Pour faire les mêmes choses dans un langage de programmation usuel, il me fallait beaucoup de temps pour adapter mon code chaque fois qu'une nouvelle saveur se présentait.
Il est également utile de migrer des solutions Visual Studio sans laisser Microsoft décider des éléments à modifier. Convertissez donc une solution. Vérifiez ce qui a changé. Annulez les choses que vous ne souhaitez pas modifier et exécutez le script xslt en faisant le travail sur tous les fichiers.
Je ne l'ai donc jamais utilisé pour faire des présentations Web ou quelque chose comme ça, mais cela m'aide dans mes problèmes basés sur XML. Et pour résoudre ces problèmes, c'est vraiment très puissant et ça vaut vraiment le coup d'œil.
XSLT n'est pas la clé de voûte de la transformation xml. Cependant, il est très difficile de juger sur la base des informations fournies si cela aurait été la meilleure solution à votre problème ou s'il existe d'autres approches plus efficaces et maintenables. Vous dites que les auteurs pourraient saisir leur contenu dans un format simplifié - quel format? Des zones de texte? À quel type de code HTML convertissiez-vous? Pour juger si XSLT est le bon outil pour le travail, il serait utile de connaître plus en détail les caractéristiques de cette transformation.
Moi aussi, j'ai fait des incursions dans le monde du XSLT et je l'ai trouvé un peu maladroit par endroits. Je pense que mon principal problème était la difficulté de convertir le XML "données pures" en une page HTML complète. Avec le recul, peut-être que l'utilisation de XSLT pour générer un fragment de page qui pourrait être composé avec d'autres fragments à l'aide de scripts côté serveur (par exemple SSI) aurait résolu bon nombre de mes problèmes.
L'une des erreurs possibles a été d'essayer de construire une mise en page commune pour entourer mes données en important du XHTML ou d'autres données XML en utilisant la fonction document ().
L'autre erreur a été d'essayer de faire des choses programmatiques comme créer un modèle général pour générer des tableaux sur des données XML avec une logique qui a fait des choses comme utiliser différentes couleurs de ligne d'arrière-plan pour les lignes avec certaines valeurs et vous permettre de spécifier certaines colonnes à filtrer.
Sans oublier d'essayer de construire une liste de chaînes de valeurs à partir de données XML qui ne semblaient pouvoir être résolues qu'à l'aide d'appels de modèle récursifs.
Qu'est-ce que j'ai gagné? Eh bien, la source de la page est constituée de données XML et disponibles pour le spectateur. Les données et la présentation sont parfaitement séparées.
Le referais-je? Probablement pas, sauf si je voulais vraiment une séparation des données/présentation sur une page statique. Sinon, j'écrirais probablement une application Rails ou Java EE qui pourrait générer une vue XML ou HTML en utilisant le modèle - tous les avantages, mais avec un langage de programmation beaucoup plus naturel (pour moi) à portée de main.
J'aime utiliser XSLT uniquement pour changer la structure arborescente des documents XML. Je trouve difficile de faire quoi que ce soit lié au traitement de texte et de le reléguer à un script personnalisé que je peux exécuter avant ou après l'application d'un XSLT à un document XML.
XSLT 2.0 comprenait beaucoup plus de fonctions de chaîne, mais je pense que ce n'est pas un bon choix pour le langage, et il n'y a pas beaucoup d'implémentations de XSLT 2.0.
En termes de productivité, vous feriez mieux d'utiliser l'une des bibliothèques de style jQuery - pyQuery, phpQuery etc. La plupart des bibliothèques XML sont nulles et XSLT est essentiellement juste une autre bibliothèque XML emballée comme un langage à part entière mais sans un ensemble décent d'outils . jQuery facilite incroyablement la traversée et la manipulation des données de style XML dans la langue de votre choix.
En ce qui concerne l'interoprabilité, XML est une norme pour le stockage d'informations. Un grand nombre d'outils produisent une sortie en XML, et quelle meilleure façon (ou plus simple) de la présenter que d'intégrer un navigateur dans votre application et de formater le XML et de le mettre dans le navigateur.
J'ai besoin de travailler avec XSLT ici parce que quelqu'un a pensé que c'était une bonne idée de résoudre un problème donné: nous devons extraire certaines données de plusieurs fichiers XML et les associer à différents formats de sortie pour différents outils qui effectuent un traitement ultérieur.
Pour commencer, je pensais que XSLT est une très bonne idée, car c'est une norme sur laquelle vous pouvez compter. Cela est vrai pour les tâches de formatage simples où vous n'avez pas besoin de beaucoup de logique de programmation ou d'algorithmes dans votre code.
Mais: C'est une courbe d'apprentissage pas à pas, car elle est pas procédurale. Si vous vous êtes habitué à la programmation procédurale (C, Java, Perl, PHP, etc.), vous allez manquer beaucoup de structures communes ou vous vous demanderez des choses qui ont de la chance et sont parfois peu lisibles par un œil inexpérimenté. Par exemple, écrire du code "réutilisable": si vous avez besoin de faire quelque chose encore et encore à différents endroits, dans la programmation procédurale, vous définiriez une fonction pour le faire. Vous pouvez également réaliser de telles choses dans XSLT, mais son pour plus de code à écrire et n'est pas aussi lisible/compréhensible qu'une fonction normale le serait.
Le principal problème que j'ai, c'est que beaucoup de gens issus d'un milieu procédural ont travaillé sur les fichiers XSLT maintenant, et presque tout le monde a juste "émulé" ce dont il avait besoin.
Donc en conclusion: je ne vois plus XSLT comme la solution "ultime". En fait, il est difficile de lire ou d'écrire certaines constructions en XSLT. Dans la plupart des cas, vous devrez penser à l'application: pour une transformation simple, j'utiliserai probablement à nouveau XSLT. Mais pour des logiciels plus complexes, je ne les utiliserai plus.