XSLT en vaut-il la peine? [fermé]

StackOverflow https://stackoverflow.com/questions/78716

  •  09-06-2019
  •  | 
  •  

Question

Il y a quelque temps, j'ai commencé un projet dans lequel je concevais 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 (lutté) avec elle pendant un moment et l'ai eu à un niveau très basique mais j'étais trop ennuyé par les limitations que je rencontrais (ce qui pourrait bien avoir été des limitations de ma connaissance) et quand j'ai lu un blog suggérant de laisser tomber XSLT et écrivez simplement votre propre analyseur syntaxique XML dans la langue de votre choix, je me suis empressé de sauter dessus et le résultat a été brillant.

Je travaille toujours dessus à ce jour ( je suis censé le faire maintenant, au lieu de jouer à SO ), et je vois de plus en plus de choses qui faites-moi penser que la décision d'abandonner XSLT était bonne.

Je sais que XSLT a sa place, en ce sens qu’il s’agit d’une norme acceptée et que si chacun é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, Recommanderiez-vous à quelqu'un qui se lance dans un projet comme le mien de suivre le même chemin que moi ou de s'en tenir à XSLT ?

Était-ce utile?

La solution

Avantages de XSLT:

  • Spécifique au domaine en XML, donc, par exemple, inutile de citer le code XML littéral dans la sortie.
  • Prend en charge XPath / XQuery, qui peut être un moyen intéressant d’interroger les DOM, de la même manière que les expressions régulières peut être un moyen intéressant d’interroger des chaînes.
  • Langage fonctionnel.

Inconvénients de XSLT:

  • Peut être obscène - il n'est pas nécessaire de citer du XML littéral, ce qui signifie en fait que vous devez citer du code. Et pas de belle façon. Mais là encore, ce n’est pas 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 entraîner des & "Moments malheureux &"; Lorsque les novices conçoivent du code, recherchez frénétiquement sur le Web des astuces sur la manière de mettre en oeuvre les fonctions qu’ils pensaient être tout simplement là et ne se donnaient pas le temps d’écrire.
  • Langage fonctionnel.

Une des façons d’obtenir un comportement procédural est d’enchaîner plusieurs transformations ensemble. Après chaque étape, vous devez travailler sur un nouveau DOM qui reflète les modifications apportées à cette étape. Certains processeurs XSL ont des extensions pour le faire efficacement en une seule transformation, mais j’oublie les détails.

Ainsi, si votre code est principalement en sortie et peu logique, XSLT peut être un moyen très judicieux de l’exprimer. S'il y a beaucoup de logique, mais surtout des formes intégrées à XSLT (sélectionnez tous les éléments qui ressemblent à blah, et pour chaque sortie blah), il s'agit probablement d'un environnement assez convivial. Si vous avez toujours envie de penser à XML-ishly, essayez XSLT 2.

Sinon, je dirais que si votre langage de programmation préféré dispose d'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 à libxml2 et à gdome2 devraient fonctionner correctement et il n’est pas honteux de s’en tenir aux langages généraux que vous connaissez bien.

Les analyseurs syntaxiques XML d'origine locale sont généralement incomplets (dans ce cas, vous finirez par être bloqués un jour) ou bien plus petits que ce que vous auriez pu trouver (dans ce cas, vous perdez probablement votre temps). , et vous offre un grand nombre de possibilités d’introduire de graves problèmes de sécurité liés aux entrées malveillantes. N'écris pas un mot à moins de savoir exactement ce que tu gagnes à le faire. Cela ne veut pas dire que vous ne pouvez pas écrire un analyseur syntaxique 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.

Autres conseils

Tant de négativité!

J'utilise XSLT depuis quelques années et je l’aime vraiment beaucoup. Vous devez comprendre que ce n’est pas un langage de programmation, c’est un langage de modélisation (et à cet égard, je le trouve indiscutablement supérieur à asp.net / spit).

XML est le format de données de facto du développement Web actuel, 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 énorme un moyen puissant et très efficace de transformer ces données en tout format de sortie que vous souhaitez, en vous donnant instantanément cet aspect MVC qui consiste à séparer la présentation des données.

Viennent ensuite les capacités utilitaires: effacer les espaces de noms, reconnaître des définitions de schéma disparates, fusionner des documents.

Il est préférable de traiter avec XSLT que de développer vos propres méthodes internes. Au moins, XSLT est une norme et vous pouvez en engager, et si cela pose toujours un problème à votre équipe, il vous laissera en principe garder la plupart de vos collaborateurs uniquement en XML.

Un cas d'utilisation dans le monde réel: je viens juste 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 à la demande de l'utilisateur final. J'ai eu une demande assez aléatoire de 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 MS Office soit installé sur le serveur! Excel a un XSD: nouvelle fonctionnalité avec un impact minimal sur le code de base en 3 heures.

Personnellement, j’estime que c’est l’une des choses les plus propres que j’ai rencontrées au cours de ma carrière, et j’estime que tous les problèmes apparents (débogage, manipulation des chaînes, structures de programmation) sont dus à une compréhension erronée de l’outil.

Évidemment, je crois fermement que cela vaut & "ça vaut le coup &".

.

Je dois admettre un parti pris ici parce que j'enseigne le XSLT pour gagner ma vie. Mais il serait peut-être intéressant de couvrir les domaines dans lesquels je vois mes étudiants travailler. Ils se divisent généralement en trois groupes: édition, banque et Web.

Jusqu'à présent, bon nombre des réponses pourraient être résumées comme suit: & "Ce n'est pas bon pour la création de sites Web &"; ou & "Cela ne ressemble en rien à la langue X &". De nombreux techniciens passent leur carrière sans être exposés aux langages fonctionnels / déclaratifs. Lorsque j'enseigne, les personnes expérimentées en Java / VB / C / etc sont celles 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). Cela fait 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 la création de sites Web - un langage de programmation généraliste 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 pénible.

Les étudiants en banque que je vois utilisent généralement une boîte DataPower. Il s’agit d’une appliance XML utilisée entre deux dialectes XML "parlants" de services. La transformation d'un langage XML en un autre est presque insignifiante avec XSLT et le nombre d'étudiants qui suivent mes cours sur ce sujet augmente.

La dernière série d’étudiants que je vois vient d’un milieu de publication (comme moi). Ces personnes ont tendance à avoir d’immenses documents en XML (croyez-moi, la publication en tant qu’industrie s’intéresse beaucoup à XML - la publication technique existe depuis des années et la publication spécialisée y parvient maintenant). Ces documents doivent être traités (on pense ici à DocBook to ePub).

Une personne ci-dessus a fait remarquer que les scripts ont tendance à être inférieurs à 60 lignes ou deviennent difficiles à manier. Si cela devient difficile à manier, le codeur n'a probablement 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 en voie de disparition (la quantité de travail que je reçois me le dit bien). Pour le moment, il est un peu "bloqué" jusqu'à ce que Microsoft finisse la mise en oeuvre (très tardive) de XSLT 2. Mais c'est toujours là et semble aller fort de mon point de vue.

Nous utilisons beaucoup XSLT pour des tâches telles que la documentation et pour rendre utilisables certains paramètres de configuration complexes.

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, nous permettant à la fois de générer automatiquement le contenu de manière générique et de le rendre plus lisible. Par exemple, lorsque nous publions des notes de publication, nous pouvons créer un XML ressemblant à: 

<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>

Ensuite, en utilisant XSLT (qui transforme ce qui précède en DocBook), nous obtenons de jolies notes de publication (PDF ou HTML en général) dans lesquelles les ID de bogues sont automatiquement liés à notre outil de suivi des bogues, les bogues sont regroupés par composant et le format de chaque élément. est parfaitement conforme. Et le code XML ci-dessus peut être généré automatiquement en interrogeant notre système de suivi des bogues sur ce qui a changé entre les versions.

L’autre endroit où nous avons trouvé le XSLT utile est en fait notre produit principal. Parfois, lors de l’interfaçage avec des systèmes tiers, nous devons d’une manière ou d’une autre traiter les données d’une page HTML complexe. L’analyse HTML est moche, nous avons donc alimenté les données avec quelque chose comme TagSoup (qui génère les événements SAX XML appropriés, nous permettant essentiellement de traiter le code HTML comme s’il s’agissait d’un code XML correctement écrit), puis nous pouvons exécuter du code XSLT contre celui-ci pour transformer les données en un " stable stable " format que nous pouvons réellement travailler avec. 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 éditer le fichier XSLT lui-même, ou nous pouvons envoyer un courrier électronique. mis à jour un fichier XSLT sans que le système ne soit mis à niveau.

Je dirais que pour les projets Web, il existe de meilleurs moyens de gérer le point de 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 de nombreuses utilisations intéressantes.

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 sont extrêmement expressifs et compacts, et généralement très bien conçus et puissants pour la tâche pour laquelle ils ont été 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 traditionnels qu’ils sont difficiles à apprendre et à déboguer. Leur nature compacte facilite généralement 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 il n'a pas vraiment attiré l'attention.

Je me souviens de tout le battage publicitaire autour de XSLT lors de la publication de la norme. Toute l’enthousiasme suscité par le fait de pouvoir construire une interface utilisateur HTML entière avec une transformation «simple».

Laissons & # 8217; le faire face, il est difficile à utiliser, presque impossible à déboguer, souvent trop lent. Le résultat final est presque toujours décalé et moins qu'idéal.

Je préférerais me dégourdir la jambe plutôt que d’utiliser un XSLT alors qu’il existe de meilleures façons de faire les choses. Néanmoins, il a toujours sa place, il convient aux tâches de transformation simples.

J'ai beaucoup utilisé XSLT (et aussi XQuery) - pour générer du code C ++ dans le cadre du processus de construction, pour produire de la documentation à partir de commentaires doc et au sein d'une application devant fonctionner avec XML en général et XHTML en particulier beaucoup. Le générateur de code, en particulier, contenait plus de 10 000 lignes de code XSLT 2.0 réparties dans une douzaine de fichiers distincts (il faisait beaucoup de choses - en-têtes pour les clients, procuration à distance / stubs, wrappers COM, wrappers .NET, ORM - pour nommer quelques). J'en ai hérité par-dessus un autre gars qui ne comprenait pas vraiment la langue et les parties les plus anciennes étaient par conséquent assez désordonnées. Les textes les plus récents que nous avons écrits étaient cependant généralement sains et lisibles, et je ne me souviens d’aucun problème particulier en ce sens. Ce n’était certainement pas plus difficile que de le faire pour C ++.

En parlant de versions, traiter avec XSLT 2.0 aide certainement à rester sain d’esprit, mais la version 1.0 est toujours acceptable 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 à un domaine (le plus important, la répartition dynamique via une correspondance de modèle) est difficile à égaler. Malgré la verbosité perçue de la syntaxe basée sur 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. Très souvent, cependant, cela devient un flack indésirable à cause de l'utilisation inutile de XML dans certains cas.

Pour résumer: c’est un outil incroyablement utile, mais il est très spécialisé, il est donc utile tant que vous l’utilisez correctement et dans le but pour lequel il a été conçu. J'aimerais vraiment qu'il y ait une implémentation .NET native et appropriée de XSLT 2.0.

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

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

  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 travaillé sur certaines limitations de XSLT en l'utilisant pour générer un XSLT afin de réaliser le travail réel. (Avez-vous déjà essayé d'écrire un XSLT produisant une sortie en utilisant des espaces de noms inconnus jusqu'à l'exécution?)

J'y reviens sans cesse 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 ont simplement mal compris le XML. XSLT est désagréable, mais je trouve que Oxygen rend cela supportable.

Cela étant dit, je cherche à utiliser Clojure (un lisp) pour effectuer des transformations de XML, mais je n'ai pas encore assez pour savoir si cette approche me rapportera des avantages.

Personnellement, j’ai utilisé XSLT dans un contexte totalement différent. Le jeu d'ordinateur 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 publication, 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 idéal pour cette traduction d'un ancien format - > Nouveau format. En moins de deux semaines, la conversion d'ancien en nouveau fonctionnait 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 de composants intégrés dans lesquels j'ai utilisé assez facilement 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’il est fantastique de traduire un fichier XML d’un format à un autre. Cependant, ce n'est pas la seule façon de définir un algorithme qui prend XML en entrée et génère Quelque chose . Si votre algorithme est suffisamment complexe, le fait qu’il s’agisse d’une entrée XML devient sans importance pour votre choix d’outil.

Selon votre exemple, 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 le formatage et ne fait rien d’intelligent. Cela pourrait être un bon compromis, mais tout dépend 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) HTML (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 du site. .

Ce n'est pas une panacée. Il y a des choses qui fonctionnent bien et qui ne fonctionnent 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 mérite d’être dans votre boîte à outils, mais il ne devrait être utilisé que lorsque cela est approprié.

Je recommanderais certainement de tenir le coup. Particulièrement si vous utilisez Visual Studio, qui possède des outils intégrés d’édition, de visualisation et de débogage pour XSLT.

Oui, c'est une douleur pendant votre apprentissage, mais la douleur est principalement 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.asp http://www.w3schools.com/xsl/xsl_functions.asp

J'ai trouvé qu'il était très difficile de travailler avec XSLT.

J'ai déjà travaillé sur un système similaire à celui que vous décrivez. Mon entreprise a noté que les données que nous renvoyions de & «Niveau intermédiaire &»; était au format XML et que les pages devaient être rendues en HTML, qui pourrait aussi bien être en XHTML. De plus, ils avaient entendu dire que XSL était un standard de transformation entre les formats XML. Ainsi, les & Quot; architectes & Quot; (c’est-à-dire des personnes qui pensent en profondeur mais qui ne codent apparemment jamais) ont décidé que notre premier niveau serait implémenté en écrivant des scripts XSLT qui transformaient les données en XHTML pour les afficher.

Le choix s’est avéré désastreux. Il s'avère que XSLT est pénible à écrire. Toutes nos pages étaient donc difficiles à écrire et à maintenir. Nous aurions beaucoup mieux fait d'utiliser JSP (c'était en Java) ou une approche similaire utilisant un type de balisage (crochets angulaires) pour le format de sortie (le HTML) et un autre type de balisage (comme & Lt; % ...% >) 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 documents XML différents dans l’esprit.

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

Toutefois, si vous aviez une solution plus simple: vous disposez de données dans un seul format XML et souhaitez les modifier - non pas un DSL avec description complète de la page, mais quelques modifications simples, alors XSLT est un excellent outil pour cet objectif. Sa nature déclarative (et non procédurale) constitue en réalité un avantage à cet effet.

- Michael Chermside

Il est difficile de travailler avec XSLT, mais une fois que vous l'avez conquis, vous aurez une compréhension très approfondie du DOM et du schéma. Si vous aussi XPath, alors vous êtes sur votre chemin pour apprendre la programmation fonctionnelle et cela vous exposera à de nouvelles techniques et façons de résoudre des problèmes. Dans certains cas, la transformation successive est plus puissante que les solutions procédurales.

J'utilise beaucoup XSLT, pour une interface frontale de style MVC personnalisée. Le modèle est & Quot; sérialisé & Quot; 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 plus strictes en matière de formage (il est beaucoup plus facile de raisonner sur la structure de documents dans xslt que dans la plupart des autres langages).

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

Néanmoins, la séparation facilement réalisable et fermement appliquée qui est accordée ne constitue pas une autre technologie en ce moment, donc je le recommanderais pour les transformations de documents.

En 2004, j'ai utilisé XML, XSD et XSLT pour un projet d'intégration entre systèmes DB très différents. J'ai dû apprendre XSD et XSLT à partir de rien, mais ce n'était pas difficile. L'avantage de ces outils est qu'ils m'ont permis d'écrire du code C ++ indépendant des données, en m'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.

Il est intéressant de noter que le XSD principal mesurait 150 Ko et que la taille moyenne du XSLT était de < 5KB IIRC.

L’autre avantage non négligeable 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 logiciel de nos jours.

Bien que je n’aie pas eu trop de mal à apprendre la nature déclarative XSD et XSLT, j’ai constaté que d’autres programmeurs C / C ++ avaient de grandes difficultés à s’adapter à la manière déclarative. Quand ils ont vu que c’était ça, ah ils ont murmuré la procédure, maintenant que je comprends! Et ils ont procédé (au jeu de mots?) Pour écrire du XSLT procédural! Le fait est que vous devez apprendre XPath et comprendre les axes de XML. Cela me rappelle que les anciens programmeurs C s’adaptaient à l’utilisation de OO lors de l’écriture en 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, à l'exception de la plus fondamentale. 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 j'estime 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 est une excellente idée.

Là où ça é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 au-dessus des aspects fonctionnels rend le tout 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’est en partie le but de sa conception - mais c’est le deuxième échec: tous les outils XSLT du marché sont, tout simplement ... de la merde!

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

Il convient également de noter que les fonctionnalités de traitement de données de XSLT peuvent être étendues dans .NET à l'aide de fonctions d'extension personnalisées:

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

Cela nous permet d’apporter facilement des modifications à la présentation de la documentation sans codage. C’est juste une question de changement de 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 du domaine qui vous pose problème (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 avez besoin. Sa principale force est la facilité de maintenance de la transformation, et l'écriture de votre propre analyseur supprime généralement cela. Cela dit, parfois, un système est petit et simple et n’a vraiment pas besoin de & "Fantaisie &"; Solution. 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 s’y habituer. Mais une fois que vous avez pris le coup (cela ne devrait pas prendre longtemps IMO), la navigation est en douceur. D'après mon expérience, les transformations compilées fonctionnent 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 désordre terriblement illisible et incontrôlable. En partie parce que XML n'est pas suffisamment lisible par l'homme pour constituer un & Quot; langage & Quot; et en partie parce que XSLT est coincé quelque part entre être déclaratif et procédural. Cela dit, et je pense qu’une comparaison peut être faite avec des expressions régulières, elle a son utilité quand il s’agit de problèmes simples et bien définis.

L'utilisation de l'approche alternative et l'analyse de code XML dans le code peuvent être tout aussi désagréables et vous souhaitez vraiment utiliser une sorte de technologie de marshalling / liaison XML (telle que JiBX en Java) qui convertira votre code XML directement en objet.

Si vous pouvez utiliser XSLT dans un style déclaratif (bien que je ne sois pas tout à fait d'accord pour dire qu'il s'agit d'un langage déclaratif), alors je pense que c'est utile et expressif.

J'ai écrit des applications Web utilisant un langage OO (C # dans mon cas) pour gérer la couche données / traitement, mais générant du XML au lieu de HTML. Cela peut ensuite être consommé directement par les clients en tant qu'API de données ou rendu au format HTML par les XSLT. Parce que le C # produisait du XML structurellement compatible avec cet usage, tout était très fluide et la logique de présentation restait déclarative. Il était plus facile de suivre et de modifier que d'envoyer les balises à partir de C #.

Cependant, comme vous avez besoin de plus de logique de traitement au niveau XSLT, cela devient compliqué et prolixe - 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 données & "; langues &"; tels que JSON gagnent du terrain dans des domaines dans lesquels XML a été traditionnellement transformé par XSLT. Mais pour le moment, XSLT reste une technologie importante et utile.

J’ai passé beaucoup de temps sur XSLT et j’ai constaté que c’est un outil utile dans certaines situations, mais que ce n’est certainement pas une solution à tous. Cela 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 soyez sur la mauvaise voie dans votre déclaration de ses limites. L'une des choses qui m'a le plus frustré était 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 pile.

Le langage HTML est-il un langage de balisage humain?

Je voudrais regarder ce qu'il a écrit. Vous pouvez probablement trouver un logiciel qui fait ce que vous voulez & "; Hors de la boîte &"; Ou au moins très proche au lieu d'écrire vos propres données à partir de la base.

Je suis actuellement chargé de collecter des données d'un site public (oui, je sais). Heureusement, il est conforme au xhtml. Je peux donc utiliser xslt pour rassembler les données dont j'ai besoin. La solution résultante est lisible, propre et facile à modifier en cas de besoin. Parfait!

J'ai déjà utilisé XSLT. Le groupe de 6 fichiers .xslt (refactorisé sur un grand) contenait 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 que cela aurait pris pour écrire en XSLT.

C’est au moment où j’ai abandonné que j’ai réalisé que ne pas utiliser XPATH 2.0 nuisait considérablement à mes progrès.

Pour répondre à vos trois questions:

  1. J'ai déjà utilisé XSLT il y a quelques années.
  2. Je pense que XSLT pourrait être la bonne solution dans certaines circonstances. (Ne dites jamais jamais)
  3. Je suis plutôt d’accord avec votre opinion que cela est surtout utile pour les "transformations" simples. Mais je pense que tant que vous comprenez bien XSLT, il est judicieux de l'utiliser pour des tâches plus importantes, telles que la publication d'un site Web au format XML transformé en HTML.

Je pense que la plupart des développeurs n'apprécient pas XSLT parce qu'ils ne comprennent pas le paradigme fondamentalement différent sur lequel il repose. Mais avec l’intérêt récent pour la programmation fonctionnelle, nous pourrions assister à un retour en force de XSLT ...

Un des endroits où xslt brille vraiment est dans la génération de rapports. J'ai trouvé ce processus en deux étapes, la première étape consistant à exporter les données du rapport sous forme de fichier xml et la deuxième étape à générer le rapport visuel à partir du xml à l'aide de xslt. Cela permet de générer des rapports visuels tout en conservant les données brutes comme mécanisme de validation si nécessaire.

Chez une société précédente, nous avons beaucoup travaillé 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 très grand XML), mais vous pouvez y remédier en utilisant smart XSLT et effectuer un prétraitement avec le XML (généré).

Toute personne ayant une connaissance de XSLT peut modifier l'apparence du produit fini car celui-ci n'est pas compilé.

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

Peut-être souhaitez-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 solution ultime de la transformation XML. Cependant, il est très difficile de juger, à partir 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? Des zones de texte? À quel type de html le convertissiez-vous? Pour déterminer si XSLT est le bon outil pour le poste, 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 qu'il est fastidieux de faire quoi que ce soit en rapport avec le traitement de texte et de le reléguer à un script personnalisé que je pourrais 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 adapté au langage et qu’il n’ya pas beaucoup d’implémentations de XSLT 2.0.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top