Est-ce que XSLT en vaut la peine?

Il y a quelque temps, j’ai commencé un projet où j’ai conçu un schéma XML en HTML pour que les auteurs puissent écrire leur contenu (matériel pédagogique) dans un format simplifié qui serait ensuite transformé en HTML via XSLT. Je me suis amusé avec ça pendant un moment et je l’ai atteint à un niveau très basique, mais alors j’étais trop énervé par les limitations que je rencontrais (ce qui pourrait bien avoir limité mes connaissances) et quand j’ai lu un blog XSLT et écrivez simplement votre propre parsingur XML dans n’importe quel langage de votre choix, j’ai sauté dessus avec impatience et cela a fonctionné avec brio.

Je suis toujours en train d’y travailler jusqu’à 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 de laisser tomber XSLT était un bon.

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 auquel la plupart des programmeurs sont habitués, pour quelqu’un qui se lance dans un projet tel que le mien, recommanderiez-vous de suivre le chemin parcouru ou XSLT? ?

Avantages de XSLT:

  • Spécifique au domaine XML, par exemple, pas besoin de citer le 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ène – vous n’avez pas à citer de code XML, ce qui signifie que vous devez citer le code. Et pas d’une manière jolie. Mais encore une fois, ce n’est pas bien pire que votre SSI typique.
  • Ne fait pas certaines choses que la plupart des programmeurs prennent pour acquis. 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 effectuent des recherches frénétiques sur le Web pour savoir comment implémenter les fonctions qu’ils supposaient être là et ne pas se donner le temps d’écrire.
  • Langage fonctionnel.

Une façon d’obtenir un comportement procédural, en passant, consiste à enchaîner plusieurs transformations. Après chaque étape, vous disposez d’un tout nouveau DOM sur lequel vous pouvez travailler et qui reflète les modifications apscopes à 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 un résultat et pas beaucoup de logique, XSLT peut être un moyen très pratique de l’exprimer. S’il y a beaucoup de logique, mais surtout de formulaires intégrés à XSLT (sélectionnez tous les éléments qui ressemblent à blah, et pour chaque blah de sortie), il est probable que ce soit un environnement plutôt convivial. Si vous avez envie de penser à XML-ishly à tout moment, alors essayez XSLT 2.

Sinon, je dirais que si votre langage de programmation favori 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 vers libxml2 et gdome2 devraient fonctionner correctement, et il n’y a aucune honte à s’en tenir aux langages d’usage général que vous connaissez bien.

Les parsingurs XML maison sont généralement incomplets (auquel cas vous vous décrocherez un jour) ou bien moins que ce que vous auriez pu obtenir (vous perdez probablement votre temps) et vous avez de nombreuses possibilités d’introduire de graves problèmes de sécurité concernant les 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 parsingur 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 le XSLT depuis quelques années et je l’aime vraiment. L’important, c’est que ce n’est pas un langage de programmation, mais plutôt un langage de template (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 l’aspect MVC de la séparation de la présentation des données.

Ensuite, il y a les capacités utilitaires: effacer les espaces de noms, reconnaître les définitions de schémas disparates, fusionner les documents.

Il est préférable de traiter avec XSLT plutôt que de développer vos propres méthodes internes. Au moins XSLT est une norme que vous pouvez embaucher, et si cela pose un réel problème pour votre équipe, sa nature vous permettra de faire travailler votre équipe avec 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 qui se transforme en JSON, HTML ou XML à la demande de l’utilisateur final. J’ai eu une demande assez aléatoire de fournir sous forme de données Excel. Un ancien collègue avait fait quelque chose de similaire par programmation, mais il fallait un module de quelques fichiers de classe et MS Office était installé sur le serveur! Il s’avère qu’Excel a un XSD: nouvelle fonctionnalité avec un impact minimum de basecode 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 les problèmes apparents (débogage, manipulation de chaînes, structures de programmation) sont dus à une compréhension erronée de l’outil.

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

Je dois admettre un parti pris parce que j’enseigne le XSLT pour gagner ma vie. Mais il pourrait être utile de couvrir les domaines dans lesquels mes étudiants travaillent. Ils se sont répartis en trois groupes: l’édition, la banque et le Web.

Bon nombre des réponses obtenues jusqu’à présent peuvent être résumées comme suit: “ce n’est pas bon pour créer des sites Web” ou “ce n’est pas comme la langue X”. Beaucoup de techniciens passent leur carrière sans être exposés à des langages fonctionnels / déclaratifs. Lorsque j’enseigne, les utilisateurs expérimentés de 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 la plupart des gens qui répondent ici – je n’ai jamais compris Java, mais je ne vais pas me soucier 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 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 sortingvial. 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 pénible.

Les étudiants en banque que je vois utilisent une boîte DataPower en général. Il s’agit d’un appareil XML utilisé pour faire la liaison entre des services «parlant» différents dialectes XML. La transformation d’un langage XML en un autre est presque sortingviale dans XSLT et le nombre d’étudiants participant à mes cours augmente.

La dernière série d’étudiants que je vois provient d’un milieu de publication (comme moi). Ces personnes ont tendance à disposer d’immenses documents en XML (croyez-moi, la publication en tant qu’indussortinge devient très XML: la publication technique existe depuis des années et l’édition commerciale y parvient maintenant). Ces documents doivent être traités (DocBook to ePub vient à l’esprit ici).

Quelqu’un ci-dessus a déclaré que les scripts ont tendance à être inférieurs à 60 lignes ou qu’ils deviennent trop lourds. Si cela devient trop compliqué, les chances sont que le codeur n’ait pas vraiment l’idée – XSLT est un état d’esprit très différent de beaucoup d’autres langues. Si vous n’obtenez 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 son implémentation (très tardive) de XSLT 2. Mais il est toujours là et semble être solide de mon sharepoint vue.

Nous utilisons largement XSLT pour des choses telles que la documentation, et pour rendre certains parameters de configuration complexes accessibles à 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 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 code XML qui ressemble à:

  Error when clicking the Foo button Crash at startup when configuration is missing Error when clicking the Bar button   

Et puis en utilisant XSLT (qui transforme ce qui précède en DocBook) nous nous retrouvons avec de bonnes notes de sortie (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 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 notre produit de base. Parfois, lors de l’interfaçage avec des systèmes tiers, nous devons traiter d’une manière ou d’une autre les données dans une page HTML complexe. L’parsing HTML est laide, nous transmettons donc 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 s’agissait de XML correctement écrit) et de lancer du XSLT. données dans un format “stable connu” avec lequel nous pouvons réellement travailler. En séparant cette transformation dans 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. Au lieu de cela, l’utilisateur final peut simplement éditer lui-même le fichier XSLT. un fichier XSLT mis à jour sans que le système entier doive être mis à niveau.

Je dirais que pour les projets Web, il existe de meilleurs moyens de gérer le côté vue que XSLT aujourd’hui, mais en tant que technologie, il existe certainement des applications pour XSLT. Ce n’est pas le langage le plus facile au monde à utiliser, mais ce n’est certainement pas mort, et de mon sharepoint vue 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. Toutes ces solutions sont très expressives et compactes, et généralement très bien conçues et puissantes pour la tâche pour laquelle elles ont été conçues.

Cependant, les développeurs de logiciels détestent généralement ces langages, car ils sont très 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.

Donc, même si XSLT est 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 attiré l’attention.

Je me souviens de tout le battage médiatique autour de XSLT lorsque la nouvelle norme a été publiée. Toute l’excitation de pouvoir créer une interface utilisateur HTML complète avec une transformation «simple».

Let’s face it, il est difficile à utiliser, presque impossible à déboguer, souvent insupportablement lent. Le résultat final est presque toujours original et moins qu’idéal.

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

J’ai beaucoup utilisé XSLT (et aussi XQuery) pour diverses choses – générer du code C ++ dans le cadre du processus de construction, produire de la documentation à partir de commentaires doc et au sein d’une application qui devait fonctionner avec XML en général et XHTML en particulier . Le générateur de code en particulier dépassait 10 000 lignes de code XSLT 2.0 réparties sur une douzaine de fichiers distincts (il faisait beaucoup de choses – en-têtes pour les clients, proxy / stubs à distance, wrappers COM, wrappers .NET, ORM – pour nommer quelques). Je l’ai hérité d’un autre type qui ne comprenait pas bien la langue, et les éléments les plus anciens étaient par conséquent un vrai gâchis. Les nouvelles choses que nous avons écrites étaient pour la plupart conservées 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, gérer XSLT 2.0 vous aide assurément à restr sain d’esprit, mais la version 1.0 est toujours acceptable pour des transformations plus simples. Dans son créneau, il s’agit d’un outil extrêmement pratique, et la productivité que vous obtenez de certaines fonctionnalités spécifiques à un domaine (surtout, la répartition dynamic via la correspondance de modèles) est difficile à égaler. Malgré le caractère perçu 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, il est induit en erreur à cause de l’utilisation inutile de XML dans certains cas.

En résumé: c’est un outil incroyablement utile à avoir dans sa boîte à outils, mais c’est un outil très spécialisé, donc bon tant que vous l’utilisez correctement et dans le but prévu. Je souhaite vraiment qu’il y ait une implémentation .NET native 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 de 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 il est finalement devenu trop complexe et nous avons dû le sortir derrière la grange.

  3. J’ai utilisé des transformations pour restructurer les schémas XML.

  4. J’ai contourné certaines limitations dans 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 inconnus avant l’exécution?)

J’y reviens sans cesse, car il fait un meilleur travail de sorting sur le XML que son traitement par rapport à d’autres approches que j’ai essayées, qui ont semblé inutilement entrainées ou simplement mal compris. XSLT est désagréable, mais je trouve que l’utilisation d’ Oxygen le rend supportable.

Cela dit, j’étudie l’ utilisation de 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 sur lequel je travaillais à l’époque utilisait des tonnes de pages d’interface définies par XML. Au cours d’un refactor majeur peu après une publication, nous avons voulu modifier 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 plus sensible au schéma.

XSLT semblait le choix parfait pour cette traduction de l’ancien format -> Nouveau format. En l’espace de deux semaines, nous avons effectué une conversion fonctionnelle de l’ancien au nouveau pour nos centaines de pages. J’ai également pu l’utiliser pour extraire beaucoup d’informations sur la mise en page de nos pages d’interface utilisateur. J’ai créé des listes des composants intégrés dans lesquels, relativement facilement, j’ai ensuite utilisé XSLT pour écrire dans nos définitions de schéma.

En outre, venant d’un contexte C ++, c’était un langage très amusant et intéressant à maîsortingser.

Je pense qu’en tant qu’outil de traduction de XML d’un format à un autre, c’est fantastique. Cependant, ce n’est pas la seule façon de définir un algorithme qui prend XML en tant qu’entrée et génère quelque chose . Si votre algorithme est suffisamment complexe, le fait que l’entrée soit XML devient sans object pour votre choix d’outil – c’est-à-dire que vous devez déployer votre propre fichier en C ++ / Python / peu importe.

Spécifiquement à 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 ne connaît que le formatage et ne fait rien d’intelligent. Cela pourrait être un beau terrain d’entente, mais cela dépend totalement de ce que vous faites. Avoir un traducteur XSLT en 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 stream RSS, un stream Atom, un fichier descripteur RDF et un fragment de carte de site .

Ce n’est pas une panacée. Il y a des choses qu’il fait bien, 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 la peine d’être intégré à votre boîte à outils, mais il ne devrait être utilisé que lorsque cela est approprié.

Je recommanderais certainement de le faire. 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 pénible pendant que vous apprenez, mais la plus grande partie de la douleur est liée à la familiarité. La douleur diminue lorsque vous apprenez la langue.

W3schools a deux articles qui ont une valeur particulière: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

J’ai trouvé XSLT assez difficile à travailler.

J’ai déjà travaillé sur un système quelque peu similaire à celui que vous décrivez. Mon entreprise a noté que les données que nous revenions du «niveau intermédiaire» étaient en XML et que les pages devaient être rendues en HTML, ce qui pourrait aussi bien être XHTML, qu’ils avaient entendu dire que XSL était une norme de transformation entre XML. formats. Donc, les “architectes” (par lesquels je veux dire des gens qui pensent à des pensées de conception profondes mais apparemment ne codent jamais) ont décidé que notre premier niveau serait implémenté en écrivant des scripts XSLT transformant les données en XHTML.

Le choix s’est avéré désastreux. Il s’avère que XSLT est une douleur à écrire. Toutes nos pages étaient donc difficiles à écrire et à maintenir. Nous aurions mieux fait d’utiliser JSP (c’était en Java) ou une approche similaire utilisant un type de balisage (crochets) pour le format de sortie (le HTML) et un autre type de balisage (comme <% ... %>) pour les métadonnées. L’aspect le plus déroutant à 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 en tête tous les 3 documents XML.

Votre situation est légèrement différente: au lieu de créer chaque page dans XSLT comme je l’ai fait, il vous suffit d’écrire UN bit de code dans XSLT (le code à convertir à partir 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 langage DSL basé sur XML (langage spécifique à un domaine) comme vous le faites n’est PAS l’un des points forts de XSLT. (Bien que ça puisse faire le boulot … après tout, c’est Turing complet!)

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

– Michael Chermside

Il est difficile de travailler avec XSLT, mais une fois que vous l’aurez conquis, vous aurez une compréhension approfondie du DOM et du schéma. Si vous aussi XPath, alors vous êtes sur le chemin de l’apprentissage de la functional programming et cela exposera à de nouvelles techniques et façons de résoudre les problèmes. Dans certains cas, les transformations successives sont plus puissantes que les solutions procédurales.

J’utilise largement XSLT, pour un front-end 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 formage les plus rigoureuses (il est beaucoup plus facile de raisonner sur la structure des documents 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), ce qui signifie qu’il est parfois frustrant de travailler avec.

Néanmoins, la séparation des problèmes, facilement réalisable et fortement imposée, qu’elle accorde, n’est pas quelque chose que j’offre une autre technologie à l’heure actuelle.

J’ai utilisé XML, XSD et XSLT sur un projet d’intégration entre des systèmes de firebase database très différents en 2004. Je devais apprendre XSD et XSLT à partir de rien, mais ce n’était pas difficile. La grande chose à propos de ces outils était qu’ils me permettaient 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 de données, changez les documents XSD et XSLT, pas le code C ++ qui employait les bibliothèques Xerces.

Pour 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’aie pas eu trop de mal à apprendre la nature déclarative de XSD et XSLT, j’ai trouvé que d’autres programmeurs C / C ++ avaient beaucoup de mal à s’adapter à la méthode 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é au jeu de mots pour écrire le XSLT procédural! Le fait est que vous devez apprendre XPath et comprendre les axes de XML. Cela me rappelle les programmeurs C d’ancien qui s’adaptent à 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 ++ isolée de toutes les modifications les plus fondamentales de la structure de données et ces dernières étaient des modifications de structure de firebase database. Même si je préfère le C ++ à tout autre langage, j’utiliserai ce que je considère utile pour améliorer la viabilité à long terme d’un projet logiciel.

Je pensais que XSLT était une excellente idée. Je veux dire que c’est une excellente idée.

Où il échoue est l’exécution.

Le problème que j’ai découvert au fil du temps est que les langages de programmation 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 au-dessus des aspects fonctionnels ne fait que compliquer le tout. J’ai essayé de l’apprendre environ 5 fois dans ma carrière, et ça ne colle tout simplement pas.

OK, vous pouvez le “faire” – 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 … des conneries!

La spécification XSLT définit XSLT comme “un langage permettant de transformer des documents XML en d’autres documents XML”. Si vous essayez de faire autre chose que le traitement de données le plus élémentaire dans XSLT, il existe probablement de meilleures solutions.

Il convient également de noter que les capacités de traitement de données de XSLT peuvent être étendues dans .NET en utilisant des 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 XML comme). 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 effectuer 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 de problème (HTML). Je considère toujours que c’est une bonne idée.

Enfin, si votre système actuel FONCTIONNE, laissez-le seul. Je ne suggérerais jamais de détruire 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. Son principal atout est la facilité de maintenance de la transformation, et l’écriture de votre propre parsingur anéantit cela. Cela dit, parfois, un système est petit et simple et n’a pas vraiment besoin de 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 du XSL, oui c’est moche. Oui, il faut du temps pour s’y habituer. Mais une fois que vous en aurez pris le coup (cela ne devrait pas prendre longtemps), la navigation sera fluide. Les transformations compilées fonctionnent assez rapidement dans mon expérience, et vous pouvez certainement les déboguer.

Je crois toujours que XSLT peut être utile, mais c’est un langage laid et peut mener à un 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é 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 son utilité quand il s’agit de problèmes simples et bien définis.

Utiliser une autre approche et parsingr XML dans du code peut être tout aussi désagréable et vous voulez vraiment utiliser une sorte de technologie de marshalling / binding XML (telle que JiBX en Java) qui convertira votre XML directement en object.

Si vous pouvez utiliser XSLT dans un style déclaratif (même si je ne suis pas entièrement d’accord avec le fait 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 produisent du XML plutôt que du HTML. Cela peut ensuite être consommé directement par les clients en tant qu’API de données ou rendu en HTML par les XSLT. Comme le C # produisait du XML 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 changer que d’envoyer les tags de C #.

Cependant, comme vous avez besoin de plus de logique de traitement au niveau XSLT, cela devient compliqué et compliqué, 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 en popularité dans les domaines où XML est traditionnellement transformé par XSLT. Mais pour l’instant, XSLT rest une technologie importante et utile.

J’ai passé beaucoup de temps dans XSLT et j’ai constaté 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 des entrées / sorties XML lisibles par machine. Je ne pense pas que vous êtes sur la mauvaise voie dans votre déclaration de ses limites. L’une des choses qui m’a le plus frustré, ce sont 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 écrit un article sur ce sujet concernant le débordement de la stack.

HTML est-il un langage de balisage humain?

Je regarderais ce qu’il a écrit. Vous pouvez probablement trouver un logiciel qui fait ce que vous voulez “prêt à l’emploi”, ou du moins très proche, au lieu d’écrire vos propres contenus à 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, donc je peux utiliser xslt pour rassembler les données dont j’ai besoin. La solution qui en résulte est lisible, propre et facile à modifier en cas de besoin. Parfait!

J’ai déjà utilisé XSLT. Le groupe de 6 fichiers .xslt (refactorisés sur un grand) était environ 2750 lignes avant de le réécrire en C #. Le code C # contient actuellement 4000 lignes contenant beaucoup de logique; Je ne veux même pas penser à ce que cela aurait pris pour écrire dans XSLT.

Le point où j’ai abandonné est quand j’ai réalisé que le fait de ne pas avoir XPATH 2.0 nuisait considérablement à mes progrès.

Pour répondre à vos trois questions:

  1. J’ai utilisé XSLT il y a quelques années.
  2. Je crois 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 les transformations «simples». Mais je pense que tant que vous comprenez bien XSLT, il y a des raisons de l’utiliser pour des tâches plus importantes telles que la publication d’un site Web en 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 ils sont basés. Mais avec l’intérêt récent pour la functional programming, nous pourrions voir le retour de XSLT …

Un endroit où xslt brille vraiment est la génération de rapports. J’ai trouvé qu’un processus en deux étapes, la première étape exportant les données du rapport sous la forme d’un fichier XML, et la deuxième étape générant le rapport visuel à partir du fichier XML à l’aide de xslt. Cela permet des rapports visuels agréables tout en conservant les données brutes comme mécanisme de validation, le cas échéant.

Dans une entreprise précédente, nous avons beaucoup travaillé avec XML et XSLT. Les deux XML et XSLT grand.

Oui, il y a une courbe d’apprentissage, mais vous disposez alors d’un outil puissant pour gérer le 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 très grand XML), mais vous pouvez vous y attaquer en utilisant smart XSLT et en effectuant un prétraitement avec le XML (généré).

Toute personne ayant des connaissances sur XSLT peut modifier l’apparence du produit fini car il n’est pas compilé.

Personnellement, j’aime XSLT, et vous voudrez peut-être examiner la syntaxe simplifiée (pas de modèles explicites, juste un vieux fichier HTML standard avec quelques balises XSLT pour y incorporer des valeurs), mais ce n’est tout simplement pas pour tout le monde.

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

XSLT n’est pas la finalité de la transformation XML. Cependant, il est très difficile de juger en fonction des informations fournies si cela aurait été la meilleure solution à votre problème ou s’il existe d’autres approches plus efficaces et plus faciles à gérer. Vous dites que les auteurs pourraient entrer leur contenu dans un format simplifié – quel format? Zones de texte? À quel type de 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’aime utiliser XSLT uniquement pour modifier l’arborescence des documents XML. Je trouve difficile de faire quelque chose en rapport avec le 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 incluait beaucoup plus de fonctions de chaîne, mais je pense que cela ne convient pas au langage, et il n’y a pas beaucoup d’implémentations de XSLT 2.0.