Est-ce que XSLT en vaut la peine? [fermé]

Il y a quelque temps, j'ai commencé sur 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é (j'ai eu du mal) avec lui pendant un certain temps et je l'ai atteint à un niveau très basique, mais j'étais trop ennuyé par les limitations 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-to-any dans la langue de votre choix, j'ai sauté dessus avec impatience et cela a fonctionné avec brio.

Je travaille toujours dessus à ce jour ( je suis en fait censé y travailler maintenant, au lieu de jouer sur SO ), et je vois de plus en plus de choses qui me font penser que la décision d'abandonner XSLT était un bon.

Je sais que XSLT a sa place, en ce sens que c'est un standard accepté, et que si chacun écrit ses propres interprètes, 90% d'entre eux finiront sur TheDailyWTF . Mais étant donné qu'il s'agit d'un langage de style fonctionnel au lieu du style procédural avec lequel la plupart des programmeurs sont familiers, pour quelqu'un qui se lance dans un projet comme le mien, recommanderiez-vous qu'il emprunte le chemin que j'ai fait ou s'en tient à XSLT ?

Avantages de XSLT:

• Spécifique au domaine XML, donc par exemple pas besoin de citer du XML littéral 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 obscénément verbeux - vous n'avez pas à citer du XML littéral, ce qui signifie en fait que vous devez citer du 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» où les novices conçoivent du code, puis recherchent frénétiquement sur le Web des indices sur la façon d'implémenter des fonctions qu'ils pensaient être là et ne se donneraient pas le temps d'écrire.
• Langage fonctionnel.

Au fait, une façon d'obtenir un comportement procédural consiste à enchaîner plusieurs transformations. Après chaque étape, vous avez un tout nouveau DOM sur lequel 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 intéressant de l'exprimer. S'il y a beaucoup de logique, mais surtout des formulaires qui sont intégrés à XSLT (sélectionnez tous les éléments qui ressemblent à du bla, et pour chacun une sortie bla), c'est probablement un environnement assez convivial. Si vous avez envie de penser à XML-ishly à tout moment, alors 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, alors il y a peu d'avantages à utiliser XSLT. Les liaisons à libxml2 et gdome2 devraient bien fonctionner, et il n'y a pas de honte à s'en tenir à des langages à usage général que vous connaissez bien.

Les analyseurs XML locaux sont généralement soit incomplets (auquel cas vous vous décrocherez un jour) ou bien pas beaucoup plus petits que ce que vous auriez pu obtenir dans le commerce (auquel cas vous perdez probablement votre temps), et donnez vous un certain nombre de possibilités d'introduire de graves problèmes de sécurité autour des entrées malveillantes. N'écrivez pas un à 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 qu'offre XML.

Tant de négativité!

J'utilise XSLT depuis quelques années maintenant, et je l'adore vraiment. La chose clé que vous devez comprendre est que ce n'est pas un langage de programmation, c'est un langage de modélisation (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 moyen extrêmement puissant et très efficace de transformer ces données dans n'importe quel format de sortie que vous souhaitez, 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: effacer les espaces de noms, reconnaître des définitions de schéma disparates, fusionner des documents.

Il doit être préférable de gérer XSLT que de développer vos propres méthodes en interne. Au moins XSLT est une norme et quelque chose pour lequel vous pouvez embaucher, et si jamais c'est vraiment un problème pour votre équipe, c'est la nature même qui vous permettrait de continuer à travailler avec seulement XML.

Un cas d'utilisation réel: je viens d'écrire une application qui gère des documents XML en mémoire dans tout le système et se transforme en JSON, HTML ou XML à la demande de l'utilisateur final. J'ai eu une demande assez aléatoire à fournir sous forme de 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 installé MS Office! Il s'avère qu'Excel a un XSD: une nouvelle fonctionnalité avec un impact minimum 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.

De toute évidence, je crois fermement que cela "en vaut la peine".

Je dois admettre un parti pris ici parce que j'enseigne XSLT pour gagner ma vie. Mais cela pourrait valoir la peine de couvrir les domaines dans lesquels je vois mes étudiants travailler. Ils se divisent généralement en trois groupes: l'édition, la banque et le Web.

La plupart des réponses à ce jour pourraient être résumées comme suit: "ce n'est pas bon pour créer des sites Web" ou "cela n'a rien à voir avec le langage X". De nombreux techniciens poursuivent leur carrière sans aucune exposition aux langages fonctionnels / déclaratifs. Quand j'enseigne, ce sont les gens expérimentés de Java / VB / C / etc 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 nombreux cas, 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 dans 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 d'édition (comme moi). Ces personnes ont tendance à avoir d'immenses documents en XML (croyez-moi, l'édition en tant qu'industrie devient très proche du XML - l'édition technique existe depuis des années et l'édition commerciale y arrive maintenant). Ces documents doivent être en cours de traitement (DocBook vers ePub vient à l'esprit ici).

Quelqu'un ci-dessus a commenté que les scripts ont tendance à être inférieurs à 60 lignes ou qu'ils deviennent peu maniables. Si cela devient difficile à manier, il y a de fortes chances que le codeur n'ait pas vraiment l'idée - XSLT est un état d'esprit très différent de celui de nombreux autres langages. 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). À l'heure actuelle, c'est un peu «bloqué» jusqu'à ce que Microsoft termine son implémentation (très tardive) de XSLT 2. Mais il est toujours là et semble aller fort de mon point de vue.

Nous utilisons beaucoup XSLT pour des choses comme la documentation et pour rendre certains paramètres de configuration complexes réparables par l'utilisateur.

Pour la documentation, nous utilisons beaucoup 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 de belles notes de publication (PDF ou HTML généralement) où les ID de bogue sont automatiquement liés à notre traqueur de 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 traqueur de bogues pour ce qui a changé entre les versions.

L'autre endroit où nous avons trouvé que XSLT est utile est en fait 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, nous alimentons donc les données via 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 en XML) et ensuite nous pouvons exécuter du XSLT contre lui, pour transformer les données en un format "connu stable" avec lequel nous pouvons réellement travailler . En séparant cette transformation en un fichier XSLT, cela signifie que si et quand le format HTML change, l'application elle-même n'a pas besoin d'être mise à niveau, à la place, l'utilisateur final peut simplement modifier le fichier XSLT lui-même, ou nous pouvons envoyer un e-mail leur un fichier XSLT mis à jour sans que le système entier ait besoin d'être mis à niveau.

Je dirais que pour les projets Web, il existe aujourd'hui de meilleures façons de gérer le côté vue que XSLT, 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 de programmation déclaratif .

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 OO ou procéduraux plus courants qu'ils sont difficiles à apprendre et à déboguer. Leur nature compacte permet généralement de faire beaucoup de dégâts par inadvertance.

Ainsi, bien que XSLT soit un mécanisme efficace pour fusionner les données dans la présentation, il échoue dans le département de la facilité d'utilisation. Je crois que c'est pour ça que ça n'a pas vraiment pris de l'ampleur.

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 créer une interface utilisateur HTML entière avec une transformation `` simple ''.

Avouons-le, il est difficile à utiliser, presque impossible à déboguer, souvent insupportablement lent. Le résultat final est presque toujours original et loin d'être idéal.

Je vais plus tôt ronger ma jambe que d'utiliser un XSLT alors qu'il existe de meilleures façons de faire les choses. Pourtant, il a sa place, c'est bon pour les tâches de transformation simples.

J'ai largement 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 doc, et dans une application qui devait beaucoup fonctionner avec XML en général et XHTML en particulier . Le générateur de code en particulier contenait plus de 10000 lignes de code XSLT 2.0 réparties autour d'une douzaine de fichiers séparés (il a fait beaucoup de choses - en-têtes pour les clients, proxy / stubs à distance, wrappers COM, wrappers .NET, ORM - pour nommer quelques). J'en ai hérité sur un autre gars qui ne comprenait pas vraiment bien la langue, et les parties plus anciennes étaient par conséquent un gâchis. Cependant, les nouveautés que nous avons écrites étaient pour la plupart saines et lisibles, et je ne me souviens pas de problèmes particuliers pour y parvenir. Ce n'était certainement pas plus difficile que de le faire pour C ++.

En parlant de versions, gérer XSLT 2.0 vous aide certainement à rester sain d'esprit, mais 1.0 est toujours bien pour les 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, l'envoi 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 des littéraux XML) était généralement plusieurs fois plus longue. Assez souvent, cependant, il obtient un flack non mé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 c'est bien tant que vous l'utilisez correctement et pour son usage prévu. Je souhaite vraiment qu'il y ait une implémentation native .NET appropriée de XSLT 2.0.

J'utilise XSLT (faute de meilleure alternative), mais pas pour la présentation, juste pour la transformation:

1. J'écris de courtes transformations XSLT pour effectuer des modifications en masse sur nos fichiers maven pom.xml.

2. 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 sortir derrière la grange.

3. J'ai utilisé des transformations pour refactoriser les schémas XML.

4. 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 en utilisant des espaces de noms qui ne sont pas connus avant l'exécution?)

Je n'arrête pas d'y revenir car il fait un meilleur travail en contournant le XML qu'il traite que d'autres approches que j'ai essayées, qui ont semblé inutilement perdantes ou simplement mal comprendre XML. XSLT est désagréable, mais je trouve que l'utilisation de l' oxygène le rend supportable.

Cela dit, j'étudie en utilisant Clojure (un lisp) pour effectuer des transformations de XML, mais je ne suis pas encore 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 utilisateur définies à l'aide de XML. Lors d'un refactor 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 sensible au schéma.

XSLT semblait le choix parfait pour cette traduction de l'ancien format -> Nouveau format. Dans les deux semaines, j'ai eu une conversion de travail d'ancien en 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 UI. J'ai créé des listes de composants incorporés dans lesquels j'ai utilisé assez facilement XSLT pour écrire dans nos définitions de schéma.

De plus, venant d'un fond 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 produit Something . 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 rouler 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 juste le formatage et ne fait rien d'intelligent. Cela peut être un bon compromis, mais cela dépend totalement de ce que vous faites. Avoir 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 HTML polyglottes (X) (présentant les mêmes données de différentes manières), un flux RSS, un flux Atom, un fichier descripteur RDF et un fragment de plan de 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 vraiment la peine d'avoir dans votre boîte à outils, mais il ne doit être utilisé que lorsque cela est approprié.

Je recommanderais certainement de tenir le coup. 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 propose deux articles particulièrement intéressants: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

J'ai trouvé XSLT assez difficile à utiliser.

J'ai travaillé sur un système un 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 tout aussi bien être XHTML, et ils avaient entendu dire que XSL était un standard pour la transformation entre XML formats. Ainsi, les "architectes" (par lesquels je veux dire les gens qui pensent profondément à la conception mais qui ne codent apparemment jamais) ont décidé que notre front tier serait implémenté en écrivant des scripts XSLT qui transformaient les données en XHTML pour l'affichage.

Le choix s'est avéré désastreux. Il s'avère que XSLT est difficile à écrire. Et donc toutes nos pages étaient difficiles à écrire et à maintenir. Nous aurions fait beaucoup mieux d'utiliser JSP (c'était en Java) ou une approche similaire qui utilisait un type de balisage (crochets angulaires) pour le format de sortie (le HTML) et un autre type de balisage (comme <% ... %>) pour les méta-donné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 différents documents XML à l'esprit.

Votre situation est légèrement différente: au lieu de créer chaque page en XSLT comme je l'ai fait, vous n'avez besoin d'écrire qu'UN bit de code en XSLT (le code à convertir des modèles en affichage). Mais il semble que vous ayez rencontré le même genre de difficultés que moi. Je dirais qu'essayer d'interpréter un DSL simple basé sur XML (langage spécifique au domaine) comme vous le faites n'est PAS l'un des points forts de XSLT. (Bien qu'il puisse faire le travail ... après tout, c'est Turing terminé!)

Cependant, si ce que vous aviez était plus simple: vous avez des données dans un format XML et que vous vouliez y apporter des modifications simples - pas un DSL de description de page complète, mais quelques modifications simples et directes, alors XSLT est un excellent outil à cette fin. Sa nature déclarative (et non procédurale) est en fait un avantage à cette fin.

- Michael Chermside

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 avez également XPath, alors vous êtes sur la bonne voie pour 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.

J'utilise beaucoup XSLT pour un frontal de style MVC personnalisé. Le modèle est "sérialisé" en xml (pas via xml serializaiton), 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 bonne formation plus rigoureuses (il est beaucoup plus facile de raisonner sur la structure du document dans xslt que dans la plupart des autres langages).

Malheureusement, le langage contient plusieurs limitations (par exemple, la possibilité de transformer la sortie d'une autre transformation) qui signifient qu'il est parfois frustrant de travailler avec.

Néanmoins, la séparation facilement réalisable et fortement imposé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 transformations de documents, c'est toujours quelque chose que je recommanderais.

J'ai utilisé XML, XSD et XSLT sur un projet d'intégration entre des systèmes de base de données très dissemblables en 2004. J'ai dû apprendre XSD et XSLT à partir de zéro, mais ce n'était pas difficile. L'avantage de ces outils était 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. Changez le format des données, changez les documents XSD et XSLT pas le code C ++ qui utilisait les bibliothèques Xerces.

Pour information: 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 fonctionnent 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édural ils ont murmuré, maintenant que je comprends! Et ils ont procédé (jeu de mots?) À écrire du XSLT procédural! Le fait est que vous devez apprendre XPath et comprendre les axes de XML. Cela me rappelle les anciens programmeurs C s'adaptant à l'utilisation d'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 les plus fondamentales, et ces dernières étaient des changements 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 utile pour bénéficier de la viabilité à long terme d'un projet logiciel.

J'avais l'habitude de penser que XSLT était une excellente idée. Je veux dire qu'il est une excellente idée.

Là où elle é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 déroutant. J'ai essayé de l'apprendre environ 5 fois dans ma carrière, et ça ne colle pas.

OK, vous pourriez 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 ... de la merde!

La 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 existe 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:

• Documentation MSDN
• CSharpFriends: Tutoriel

Je maintiens un système de documentation en ligne pour mon entreprise. Les rédacteurs créent la documentation en SGML (un langage de type xml). Le SGML est ensuite combiné avec XSLT et transformé en HTML.

Cela nous permet de modifier facilement la présentation 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 supprimer votre code existant. Si je partais de zéro, j'utiliserais XSLT, mais dans votre cas, j'utiliserais ce que vous avez.

Cela dépend de ce dont vous en avez besoin. Sa principale force est la facilité de maintenance de la transformation, et l'écriture de votre propre analyseur annule généralement cela. Cela dit, parfois un système est petit et simple et n'a pas vraiment besoin d'une solution «sophistiquée». Tant que votre générateur basé sur du code est remplaçable sans avoir à changer d'autre code, pas de problème.

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 à l'OMI), la navigation est en fait fluide. D'après mon expérience, les transformations compilées s'exécutent assez rapidement et vous pouvez certainement les déboguer.

Je crois toujours que XSLT peut être utile, mais c'est un langage laid et peut conduire à un terrible désordre illisible et impossible à maintenir. 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é quelque part entre le caractère déclaratif et procédural. Cela dit, et je pense qu'une comparaison peut être établie avec des expressions régulières, elle a son utilité lorsqu'il s'agit de problèmes simples et bien définis.

Utiliser l'approche alternative et analyser le 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 votre XML directement en objet.

Si vous pouvez utiliser XSLT dans un style déclaratif (bien que je ne sois pas entièrement d'accord pour dire qu'il s'agit d'un langage déclaratif), je pense que c'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 qui produisent du XML plutôt que du HTML. Cela peut ensuite être utilisé directement par les clients en tant qu'API de données ou rendu au format HTML par les XSLT. Comme le C # produisait du XML structurellement compatible avec cette utilisation, tout était très fluide et la logique de présentation était maintenue déclarative. C'était plus facile à suivre et à modifier que d'envoyer les balises depuis C #.

Cependant, comme vous avez besoin de plus de logique de traitement au niveau XSLT, cela devient alambiqué et détaillé - même si vous «obtenez» le style fonctionnel.

Bien sûr, ces jours-ci, j'aurais probablement écrit ces applications Web en utilisant une interface RESTful - et je pense que les «langages» de données tels que JSON gagnent du terrain dans des domaines où XML a traditionnellement été transformé par XSLT. Mais pour l'instant, XSLT est toujours une technologie importante et utile.

J'ai passé beaucoup de temps dans XSLT et j'ai trouvé que même s'il s'agit d'un outil utile dans certaines situations, ce n'est certainement pas une solution. 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 déclaration de ses limites. L'une des choses qui m'ont le plus frustré étaient les nuances dans les implémentations de XSLT.

Peut-être devriez-vous regarder certains des autres langages de balisage disponibles. Je crois que Jeff a fait un article sur ce sujet même concernant Stack Overflow.

Le HTML est-il un langage de balisage humain?

Je jetterais un œil à ce qu'il a écrit. Vous pouvez probablement trouver un progiciel qui fait ce que vous voulez "hors de la boîte", ou du moins très proche au lieu d'écrire vos propres trucs à partir de zéro.

Je suis actuellement chargé de récupérer les données d'un site public (oui, 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!

J'ai déjà utilisé XSLT. Le groupe de 6 fichiers .xslt (refactorisé à partir d'un gros fichier) comptait environ 2750 lignes bien avant que je ne le réécrive en C #. Le code C # est actuellement de 4000 lignes contenant beaucoup de logique; Je ne veux même pas penser à ce qu'il aurait fallu pour écrire en XSLT.

Le moment où j'ai abandonné, c'est quand j'ai réalisé que le fait de ne pas avoir XPATH 2.0 a considérablement nui à mes progrès.

Pour répondre à vos trois questions:

1. J'ai utilisé XSLT il y a quelques années.
2. Je pense que XSLT pourrait être la bonne solution dans certaines circonstances. (Ne jamais dire jamais)
3. J'ai tendance à être d'accord avec votre évaluation selon laquelle il est surtout utile pour des transformations «simples». Mais je pense que tant que vous comprenez bien XSLT, il y a lieu de l'utiliser pour des tâches plus importantes comme la publication d'un site Web au format XML transformé en HTML.

Je pense 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 ...

Un endroit où xslt brille vraiment est dans la génération de rapports. J'ai trouvé qu'un processus en 2 étapes, 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 à l'aide de xslt. Cela permet de beaux rapports visuels tout en conservant les données brutes comme mécanisme de validation si besoin est.

Dans une entreprise précédente, nous avons beaucoup fait avec XML et XSLT. XML et XSLT gros.

Oui, il y a 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 Smart XSLT et effectuer 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é.

Personnellement, j'aime XSLT, et vous voudrez peut-être donner un coup d'œil à la syntaxe simplifiée (pas de modèles explicites, juste un ancien fichier HTML ordinaire avec quelques balises XSLT pour y cracher des valeurs), mais ce n'est tout simplement pas pour tout le monde.

Peut-être voulez-vous simplement offrir à vos auteurs une interface simple Wiki ou Markdown. Il existe également des bibliothèques pour cela, et si XSLT ne fonctionne pas pour vous, peut-être que XML ne fonctionne pas pour elles non plus.

XSLT n'est pas la fin 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? Dans quel type de code HTML le 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.

J'apprécie d'utiliser XSLT uniquement pour changer l'arborescence des documents XML. Je trouve difficile de faire quoi que ce soit lié au traitement de texte et de reléguer cela à un script personnalisé que je peux exécuter avant ou après l'application d'un XSLT à un document XML.

XSLT 2.0 incluait 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.