XSLT vale a pena?[fechado]

https://stackoverflow.com/questions/78716

xml
xslt

09-06-2019
|

Pergunta

Há algum tempo, comecei um projeto onde projetei um esquema XML no estilo html para que os autores pudessem escrever seu conteúdo (material do curso educacional) em um formato simplificado que seria então transformado em HTML via XSLT.Eu brinquei (lutei) com isso por um tempo e cheguei a um nível muito básico, mas depois fiquei muito irritado com as limitações que estava encontrando (que podem muito bem ter sido limitações do meu conhecimento) e quando li um blog sugerindo abandonar XSLT e apenas escrever seu próprio analisador XML para qualquer coisa na linguagem de sua escolha, eu ansiosamente comecei a trabalhar nisso e funcionou de maneira brilhante.

Ainda estou trabalhando nisso até hoje (Na verdade, eu deveria estar trabalhando nisso agora, em vez de jogar no SO), e estou vendo cada vez mais coisas que me fazem pensar que a decisão de abandonar o XSLT foi boa.

Eu sei que XSLT tem o seu lugar, pois é um padrão aceito, e que se todos escreverem seus próprios intérpretes, 90% deles acabarão em TheDailyWTF.Mas dado que se trata de um linguagem de estilo funcional em vez do estilo processual com o qual a maioria dos programadores está familiarizada, para alguém que embarca em um projeto como o meu, você recomendaria que eles seguissem o caminho que eu fiz ou continuassem com XSLT?

Solução

Vantagens do XSLT:

Específico do domínio para XML, portanto, por exemplo, não há necessidade de citar XML literal na saída.
Suporta XPath/XQuery, que pode ser uma ótima maneira de consultar DOMs, da mesma forma que expressões regulares podem ser uma ótima maneira de consultar strings.
Linguagem funcional.

Desvantagens do XSLT:

Pode ser obscenamente detalhado - você não precisa citar XML literal, o que significa efetivamente que você precisa citar o código.E não de uma forma bonita.Mas, novamente, não é muito pior do que o seu SSI típico.
Não faz certas coisas que a maioria dos programadores considera certas.Por exemplo, a manipulação de strings pode ser uma tarefa árdua.Isso pode levar a "momentos infelizes" quando os novatos projetam código e, em seguida, pesquisam freneticamente na web por dicas de como implementar funções que eles supunham que simplesmente estariam lá e não tiveram tempo para escrever.
Linguagem funcional.

A propósito, uma maneira de obter comportamento processual é encadear múltiplas transformações.Após cada etapa, você terá um novo DOM para trabalhar, que reflete as alterações dessa etapa.Alguns processadores XSL possuem extensões para fazer isso efetivamente em uma transformação, mas esqueço os detalhes.

Portanto, se o seu código é principalmente de saída e não tem muita lógica, o XSLT pode ser uma maneira muito elegante de expressá-lo.Se houver muita lógica, mas principalmente de formulários integrados ao XSLT (selecione todos os elementos que parecem blá e, para cada um deles, a saída é blá), é provável que seja um ambiente bastante amigável.Se você gosta de pensar em XML o tempo todo, experimente o XSLT 2.

Caso contrário, eu diria que se sua linguagem de programação favorita tiver uma boa implementação de DOM que suporte XPath e permita que você crie documentos de maneira útil, então há poucos benefícios em usar XSLT.As ligações para libxml2 e gdome2 devem funcionar bem, e não há vergonha em aderir a linguagens de uso geral que você conhece bem.

Analisadores XML caseiros geralmente são incompletos (nesse caso, você se desfará algum dia) ou não são muito menores do que algo que você poderia ter comprado na prateleira (nesse caso, você provavelmente está perdendo seu tempo), e fornecem você oferece inúmeras oportunidades para introduzir graves problemas de segurança em torno de entradas maliciosas.Não escreva um a menos que saiba exatamente o que você ganha ao fazê-lo.O que não quer dizer que você não possa escrever um analisador para algo mais simples que XML como formato de entrada, se não precisar de tudo o que o XML oferece.

Outras dicas

Tanta negatividade!

Eu uso XSLT há alguns anos e realmente adoro isso.A principal coisa que você precisa perceber é que não é uma linguagem de programação, é uma linguagem de templates (e nesse aspecto acho indescritivelmente superior ao asp.net/spit).

XML é o formato de dados de fato do desenvolvimento web hoje, sejam arquivos de configuração, dados brutos ou representação em memória.XSLT e XPath oferecem uma enormemente uma maneira poderosa e muito eficiente de transformar esses dados em qualquer formato de saída que você desejar, proporcionando instantaneamente aquele aspecto MVC de separar a apresentação dos dados.

Depois, há as habilidades utilitárias:eliminando namespaces, reconhecendo definições de esquemas díspares, mesclando documentos.

Isto deve seria melhor lidar com XSLT do que desenvolver seus próprios métodos internos.Pelo menos XSLT é um padrão e algo pelo qual você pode contratar, e se for realmente um problema para sua equipe, sua própria natureza permitiria que você mantivesse a maior parte de sua equipe trabalhando apenas com XML.

Um caso de uso do mundo real:Acabei de escrever um aplicativo que lida com documentos XML na memória em todo o sistema e os transforma em JSON, HTML ou XML conforme solicitado pelo usuário final.Recebi uma solicitação bastante aleatória para fornecer dados do Excel.Um ex-colega havia feito algo semelhante programaticamente, mas exigia um módulo de alguns arquivos de classe e que o servidor tivesse o MS Office instalado!Acontece que o Excel tem um XSD:nova funcionalidade com impacto mínimo no código base em 3 horas.

Pessoalmente, acho que é uma das coisas mais limpas que encontrei em minha carreira e acredito que todos os problemas aparentes (depuração, manipulação de strings, estruturas de programação) se devem a uma compreensão falha da ferramenta.

Obviamente, acredito fortemente que “vale a pena”.

Eu tenho que admitir um preconceito aqui porque eu ensino XSLT para viver.Mas pode valer a pena cobrir as áreas em que vejo meus alunos trabalhando.Eles se dividem em três grupos geralmente:publicação, serviços bancários e web.

Muitas das respostas até agora poderiam ser resumidas como “não é bom para criar sites” ou “não é nada parecido com a linguagem X”.Muitos profissionais de tecnologia passam por suas carreiras sem nenhuma exposição a linguagens funcionais/declarativas.Quando estou ensinando, o pessoal experiente em Java/VB/C/etc é quem tem problemas com a linguagem (variáveis são variáveis no sentido de álgebra e não de programação processual, por exemplo).Muitas pessoas estão respondendo aqui - nunca me dei bem com Java, mas não vou me preocupar em criticar a linguagem por causa disso.

Em muitas circunstâncias, é uma ferramenta inadequada para a criação de websites - uma linguagem de programação de uso geral pode ser melhor.Muitas vezes preciso pegar documentos XML muito grandes e apresentá-los na web;XSLT torna isso trivial.Os alunos que vejo neste espaço tendem a processar conjuntos de dados e apresentá-los na web.XSLT certamente não é a única ferramenta aplicável neste espaço.No entanto, muitos deles estão usando o DOM para fazer isso e o XSLT é certamente menos doloroso.

Os estudantes bancários que atendo usam uma caixa DataPower em geral.Este é um dispositivo XML e é usado para ficar entre serviços que 'falam' diferentes dialetos XML.A transformação de uma linguagem XML para outra é quase trivial em XSLT e o número de alunos que frequentam meus cursos sobre isso está aumentando.

O último conjunto de alunos que vejo vem de uma área editorial (como eu).Essas pessoas tendem a ter imensos documentos em XML (acredite, a publicação como indústria está se interessando muito por XML - a publicação técnica já existe há anos e a publicação comercial está chegando lá agora).Esses documentos precisam ser processados (DocBook to ePub vem à mente aqui).

Alguém acima comentou que os scripts tendem a ter menos de 60 linhas ou tornam-se difíceis de manejar.Se ficar complicado, é provável que o codificador não tenha realmente entendido a ideia - XSLT tem uma mentalidade muito diferente de muitas outras linguagens.Se você não tiver a mentalidade, não funcionará.

Certamente não é uma língua em extinção (a quantidade de trabalho que recebo me diz isso).No momento, está um pouco 'travado' até que a Microsoft termine a implementação (muito tardia) do XSLT 2.Mas ainda está lá e parece estar forte do meu ponto de vista.

Usamos XSLT extensivamente para coisas como documentação e para tornar algumas configurações complexas que podem ser reparadas pelo usuário.

Para documentação, usamos muito DocBook, que é um formato baseado em XML.Isso nos permite armazenar e gerenciar nossa documentação com todo o nosso código-fonte, já que os arquivos são de texto simples.Com o XSLT, podemos construir facilmente nossos próprios formatos de documentação, permitindo-nos gerar automaticamente o conteúdo de maneira genérica e torná-lo mais legível.Por exemplo, quando publicamos notas de lançamento, podemos criar um XML parecido com:

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

E então, usando XSLT (que transforma o texto acima em DocBook), terminamos com ótimas notas de lançamento (geralmente PDF ou HTML), onde os IDs dos bugs são automaticamente vinculados ao nosso rastreador de bugs, os bugs são agrupados por componente e o formato de tudo é perfeitamente consistente .E o XML acima pode ser gerado automaticamente consultando nosso rastreador de bugs para saber o que mudou entre as versões.

O outro lugar onde descobrimos que o XSLT é útil é, na verdade, em nosso produto principal.Às vezes, ao fazer interface com sistemas de terceiros, precisamos processar dados de alguma forma em uma página HTML complexa.Analisar HTML é feio, então alimentamos os dados através de algo como TagSopa (que gera eventos XML SAX adequados, essencialmente nos permitindo lidar com o HTML como se fosse um XML escrito corretamente) e então podemos executar algum XSLT nele, para transformar os dados em um formato "estável conhecido" com o qual possamos realmente trabalhar .Ao separar essa transformação em um arquivo XSLT, isso significa que se e quando o formato HTML mudar, o aplicativo em si não precisará ser atualizado; em vez disso, o usuário final poderá apenas editar o arquivo XSLT por conta própria ou podemos enviar um e-mail um arquivo XSLT atualizado sem que todo o sistema precise ser atualizado.

Eu diria que, para projetos da Web, existem maneiras melhores de lidar com o lado da visualização do que o XSLT hoje, mas como tecnologia, definitivamente há usos para o XSLT.Não é a linguagem mais fácil de usar do mundo, mas definitivamente não está morta e, na minha perspectiva, ainda tem muitos usos bons.

XSLT é um exemplo de programação declarativa linguagem.

Outros exemplos de linguagens de programação declarativas incluem expressões regulares, Prolog e SQL.Todos eles são altamente expressivos e compactos, e geralmente muito bem projetados e poderosos para a tarefa para a qual foram projetados.

No entanto, os desenvolvedores de software geralmente odeiam essas linguagens, porque são tão diferentes das linguagens OO ou procedurais mais convencionais que são difíceis de aprender e depurar.Sua natureza compacta geralmente torna muito fácil causar muitos danos inadvertidamente.

Portanto, embora o XSLT seja um mecanismo eficiente para mesclar dados na apresentação, ele falha no departamento de facilidade de uso.Acredito que seja por isso que ainda não pegou.

Lembro-me de todo o entusiasmo em torno do XSLT quando o padrão foi lançado recentemente.Toda a emoção de poder construir uma UI HTML inteira com uma transformação 'simples'.

Sejamos realistas, é difícil de usar, quase impossível de depurar e muitas vezes insuportavelmente lento.O resultado final é quase sempre peculiar e nada ideal.

Prefiro roer minha própria perna do que usar um XSLT, embora existam maneiras melhores de fazer as coisas.Ainda assim tem seus lugares, é bom para tarefas simples de transformação.

Eu usei XSLT (e também XQuery) extensivamente para várias coisas - para gerar código C++ como parte do processo de construção, para produzir documentação a partir de comentários de documentos e dentro de um aplicativo que precisava trabalhar muito com XML em geral e XHTML em particular .O gerador de código em particular tinha mais de 10.000 linhas de código XSLT 2.0 espalhadas por cerca de uma dúzia de arquivos separados (ele fazia muitas coisas - cabeçalhos para clientes, proxies/stubs de comunicação remota, wrappers COM, wrappers .NET, ORM - para citar um pouco).Eu herdei isso de outro cara que não entendia bem o idioma, e as partes mais antigas eram, conseqüentemente, uma bagunça.No entanto, as coisas mais recentes que escrevemos foram mantidas, em sua maioria, sãs e legíveis, e não me lembro de nenhum problema específico em conseguir isso.Certamente não foi mais difícil do que fazer isso em C++.

Falando em versões, lidar com o XSLT 2.0 definitivamente ajuda a mantê-lo são, mas o 1.0 ainda é adequado para transformações mais simples.Em seu nicho, é uma ferramenta extremamente útil, e a produtividade obtida com certos recursos específicos de domínio (mais importante, envio dinâmico por meio de correspondência de modelo) é difícil de igualar.Apesar da percepção da sintaxe baseada em XML do XSLT, a mesma coisa no LINQ to XML (mesmo em VB com literais XML) geralmente era várias vezes mais longa.Muitas vezes, no entanto, ele recebe críticas imerecidas devido ao uso desnecessário de XML, em alguns casos, em primeiro lugar.

Resumindo:é uma ferramenta incrivelmente útil para se ter na caixa de ferramentas, mas é muito especializada, por isso é boa, desde que você a use de maneira adequada e para a finalidade pretendida.Eu realmente gostaria que houvesse uma implementação .NET nativa e adequada do XSLT 2.0.

Eu uso XSLT (por falta de alternativa melhor), mas não para apresentação, apenas para transformação:

Eu escrevo transformações XSLT curtas para fazer edições em massa em nossos arquivos maven pom.xml.
Escrevi um pipeline de transformações para gerar esquemas XML a partir de XMI (diagrama UML).Funcionou por um tempo, mas finalmente ficou muito complexo e tivemos que retirá-lo para trás do celeiro.
Usei transformações para refatorar esquemas XML.
Eu contornei algumas limitações do XSLT usando-o para gerar um XSLT para fazer o trabalho real.(Já tentou escrever um XSLT que produzisse uma saída usando namespaces que não são conhecidos até o tempo de execução?)

Eu continuo voltando a ele porque ele faz um trabalho melhor ao percorrer o XML que está processando do que outras abordagens que tentei, que pareciam desnecessariamente com perdas ou simplesmente interpretavam mal o XML.XSLT é desagradável, mas acho que usar Oxigênio torna suportável.

Dito isto, estou investigando usando Clojure (um lisp) para realizar transformações de XML, mas ainda não fui longe o suficiente para saber se essa abordagem me trará benefícios.

Pessoalmente usei XSLT em um contexto totalmente diferente.O jogo de computador em que eu estava trabalhando na época usava toneladas de páginas de UI definidas em XML.Durante uma grande refatoração logo após o lançamento, queríamos alterar a estrutura desses documentos XML.Fizemos com que o formato de entrada do jogo seguisse uma estrutura muito melhor e com reconhecimento de esquema.

XSLT pareceu a escolha perfeita para esta tradução do formato antigo -> Novo formato.Em duas semanas, tive uma conversão funcional do antigo para o novo para nossas centenas de páginas.Também consegui usá-lo para extrair muitas informações sobre o layout de nossas páginas de IU.Criei listas de quais componentes foram incorporados com relativa facilidade e usei XSLT para escrever em nossas definições de esquema.

Além disso, tendo experiência em C++, era uma linguagem muito divertida e interessante de dominar.

Acho que como ferramenta para traduzir XML de um formato para outro é fantástico.No entanto, não é a única maneira de definir um algoritmo que toma XML como entrada e produz Algo.Se o seu algoritmo for suficientemente complexo, o fato de a entrada ser XML torna-se irrelevante para a sua escolha de ferramenta - ou seja, crie a sua própria em C++/Python/qualquer coisa.

Específico para o seu exemplo, imagino que a melhor ideia seria criar seu próprio conversor XML->XML que siga sua lógica de negócios.Em seguida, escreva um tradutor XSLT que saiba apenas sobre formatação e não faça nada inteligente.Esse pode ser um bom meio-termo, mas depende totalmente do que você está fazendo.Ter um tradutor XSLT na saída facilita a criação de formatos de saída alternativos - imprimíveis, para celulares, etc.

Sim, eu uso muito.Ao usar diferentes arquivos xslt, posso usar a mesma fonte XML para criar vários arquivos poliglotas (X)HTML (apresentando os mesmos dados de maneiras diferentes), um feed RSS, um feed Atom, um arquivo descritor RDF e um fragmento de um mapa do site .

Não é uma panacéia.Há coisas que ele faz bem e coisas que não faz bem e, como todos os outros aspectos da programação, trata-se de usar a ferramenta certa para o trabalho certo.É uma ferramenta que vale a pena ter em sua caixa de ferramentas, mas que deve ser usada apenas quando for apropriado.

Eu definitivamente recomendo aguentar.Principalmente se você estiver usando o Visual Studio, que possui ferramentas integradas de edição, visualização e depuração para XSLT.

Sim, é uma dor enquanto você aprende, mas a maior parte da dor tem a ver com a familiaridade.A dor diminui à medida que você aprende o idioma.

W3schools tem dois artigos de particular valor:http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Achei o XSLT bastante difícil de trabalhar.

Tive experiência trabalhando em um sistema um tanto semelhante ao que você descreve.Minha empresa observou que os dados que estávamos retornando da "camada intermediária" estavam em XML e que as páginas deveriam ser renderizadas em HTML, que poderia muito bem ser XHTML, além de terem ouvido falar que XSL era um padrão para transformação entre XML formatos.Portanto, os "arquitetos" (quero dizer pessoas que pensam profundamente em design, mas aparentemente nunca codificam) decidiram que nossa camada frontal seria implementada escrevendo scripts XSLT que transformassem os dados em XHTML para exibição.

A escolha acabou sendo desastrosa.Acontece que XSLT é difícil de escrever.E assim todas as nossas páginas eram difíceis de escrever e manter.Teríamos feito muito melhor se tivéssemos usado JSP (isso foi em Java) ou alguma abordagem semelhante que usasse um tipo de marcação (colchetes angulares) para o formato de saída (o HTML) e outro tipo de marcação (como <%... %>) para os metadados.A coisa mais confusa sobre XSLT é que ele é escrito em XML e traduz de XML para XML...é muito difícil manter todos os três documentos XML diferentes em mente.

Sua situação é um pouco diferente:em vez de criar cada página em XSLT como fiz, você só precisa escrever UM bit de código em XSLT (o código a ser convertido de modelos para exibição).Mas parece que você pode ter enfrentado o mesmo tipo de dificuldade que eu.Eu diria que tentar interpretar uma DSL simples baseada em XML (linguagem específica de domínio) como você está fazendo NÃO é um dos pontos fortes do XSLT.(Embora possa fazer o trabalho ...afinal, é Turing completo!)

No entanto, se o que você tinha fosse mais simples:você tem dados em um formato XML e deseja fazer alterações simples neles - não uma DSL de descrição completa da página, mas algumas modificações simples e diretas, então o XSLT é uma excelente ferramenta para esse propósito.A sua natureza declarativa (não processual) é na verdade uma vantagem para esse efeito.

-Michael Chermside

É difícil trabalhar com XSLT, mas depois de conquistá-lo, você terá um conhecimento completo do DOM e do esquema.Se você também XPath, então você está no caminho certo para aprender programação funcional e isso irá expor novas técnicas e maneiras de resolver problemas.Em alguns casos, a transformação sucessiva é mais poderosa do que as soluções procedimentais.

Eu uso XSLT extensivamente, para um front-end personalizado no estilo MVC.O modelo é "serializado" para xml (não via serialização xml) e depois convertido para html via xslt.A vantagem sobre o ASP.NET reside na integração natural com XPath e nos requisitos de boa formação mais rigorosos (é muito mais fácil raciocinar sobre a estrutura do documento em xslt do que na maioria das outras linguagens).

Infelizmente, a linguagem contém diversas limitações (por exemplo, a capacidade de transformar a saída de outra transformação), o que significa que às vezes é frustrante trabalhar com ela.

No entanto, a separação de interesses facilmente alcançável e fortemente aplicada que ela concede não é algo que vejo outra tecnologia fornecendo no momento - portanto, para transformações de documentos, ainda é algo que eu recomendaria.

Usei XML, XSD e XSLT em um projeto de integração entre sistemas de banco de dados muito diferentes em algum momento de 2004.Tive que aprender XSD e XSLT do zero, mas não foi difícil.A grande vantagem dessas ferramentas é que elas me permitiram escrever código C++ independente de dados, contando com XSD e XSLT para validar/verificar e depois transformar os documentos XML.Altere o formato dos dados, altere os documentos XSD e XSLT e não o código C++ que empregou as bibliotecas Xerces.

Por interesse:o XSD principal tinha 150 KB e o tamanho médio do XSLT era <5 KB IIRC.

O outro grande benefício é que o XSD é um documento de especificação no qual o XSLT se baseia.Os dois trabalham em harmonia.E as especificações são raras no desenvolvimento de software atualmente.

Embora eu não tenha tido muita dificuldade em aprender a natureza declarativa do XSD e do XSLT, descobri que outros programadores de C/C++ tiveram grande dificuldade em se ajustar à forma declarativa.Quando viram que era isso, ah processual murmuraram, agora que entendi!E eles começaram (trocadilho?) a escrever XSLT processual!O problema é que você precisa aprender XPath e entender os eixos do XML.Isso me lembra os antigos programadores C que se adaptavam ao emprego de OO ao escrever C++.

Usei essas ferramentas porque elas me permitiram escrever uma pequena base de código C++ que foi isolada de todas as modificações da estrutura de dados, exceto as mais fundamentais, e estas últimas foram alterações na estrutura do banco de dados.Embora eu prefira C++ a qualquer outra linguagem, usarei o que considero útil para beneficiar a viabilidade de um projeto de software a longo prazo.

Eu costumava pensar que XSLT era uma ótima ideia.quero dizer é uma ótima ideia.

Onde falha é na execução.

O problema que descobri com o tempo foi que as linguagens de programação em XML são apenas uma má ideia.Isso torna tudo impenetrável.Especificamente, acho que XSLT é muito difícil de aprender, codificar e entender.O XML além dos aspectos funcionais torna tudo muito confuso.Tentei aprender isso cerca de 5 vezes em minha carreira e simplesmente não funcionou.

OK, você poderia 'ferramenta' - acho que esse foi parcialmente o objetivo do design - mas essa é a segunda falha:todas as ferramentas XSLT do mercado são, simplesmente...besteira!

O Especificação XSLT define XSLT como "uma linguagem para transformar documentos XML em outros documentos XML".Se você está tentando fazer qualquer coisa que não seja o processamento de dados mais básico no XSLT, provavelmente existem soluções melhores.

Também vale a pena notar que os recursos de processamento de dados do XSLT podem ser estendidos no .NET usando funções de extensão personalizadas:

Eu mantenho um sistema de documentação online para minha empresa.Os escritores criam a documentação em SGML (uma linguagem semelhante a xml).O SGML é então combinado com XSLT e transformado em HTML.

Isso nos permite fazer alterações facilmente no layout da documentação sem fazer qualquer codificação.É apenas uma questão de alterar o XSLT.

Isso funciona bem para nós.No nosso caso, é um documento somente leitura.O usuário não está interagindo com a documentação.

Além disso, ao usar XSLT, você está trabalhando mais próximo do domínio do problema (HTML).Sempre considerei isso uma boa ideia.

Por último, se o seu sistema atual FUNCIONA, deixe-o como está.Eu nunca sugeriria destruir seu código existente.Se eu estivesse começando do zero, usaria XSLT, mas no seu caso, usaria o que você tem.

Tudo se resume ao que você precisa.Seu principal ponto forte é a facilidade de manutenção da transformação, e escrever seu próprio analisador geralmente elimina isso.Dito isto, às vezes um sistema é pequeno e simples e realmente não precisa de uma solução “sofisticada”.Contanto que seu construtor baseado em código seja substituível sem a necessidade de alterar outro código, não é grande coisa.

Quanto à feiura do XSL, sim, é feio.Sim, leva algum tempo para se acostumar.Mas uma vez que você pega o jeito (não deve demorar muito, IMO), é realmente uma navegação tranquila.Na minha experiência, as transformações compiladas são executadas muito rapidamente e você certamente pode depurá-las.

Ainda acredito que o XSLT pode ser útil, mas é uma linguagem feia e pode levar a uma bagunça terrível, ilegível e impossível de manter.Em parte porque o XML não é legível o suficiente para constituir uma "linguagem" e em parte porque o XSLT está preso em algum lugar entre ser declarativo e processual.Dito isto, e acho que uma comparação pode ser feita com expressões regulares, ela tem sua utilidade quando se trata de problemas simples e bem definidos.

Usar a abordagem alternativa e analisar XML no código pode ser igualmente desagradável e você realmente deseja empregar algum tipo de tecnologia de empacotamento/ligação de XML (como JiBX em Java) que converterá seu XML diretamente em um objeto.

Se você pode usar XSLT em um estilo declarativo (embora eu não concorde inteiramente que seja uma linguagem declarativa), então acho que é útil e expressivo.

Eu escrevi aplicativos da web que usam uma linguagem OO (C# no meu caso) para lidar com a camada de dados/processamento, mas geram XML em vez de HTML.Isso pode então ser consumido diretamente pelos clientes como uma API de dados ou renderizado como HTML por XSLTs.Como o C# produzia XML estruturalmente compatível com esse uso, tudo foi muito tranquilo e a lógica de apresentação foi mantida declarativa.Foi mais fácil acompanhar e alterar do que enviar as tags do C#.

No entanto, à medida que você precisa de mais lógica de processamento no nível XSLT, ela fica complicada e detalhada - mesmo se você "obter" o estilo funcional.

Claro, hoje em dia eu provavelmente teria escrito esses aplicativos da web usando uma interface RESTful - e acho que "linguagens" de dados como JSON estão ganhando força em áreas onde o XML tem sido tradicionalmente transformado pelo XSLT.Mas, por enquanto, o XSLT ainda é uma tecnologia importante e útil.

Passei muito tempo no XSLT e descobri que, embora seja uma ferramenta útil em algumas situações, definitivamente não é uma solução para tudo.Funciona muito bem para fins B2B quando é usado para tradução de dados para entrada/saída XML legível por máquina.Não creio que você esteja no caminho errado ao declarar suas limitações.Uma das coisas que mais me frustrou foram as nuances nas implementações do XSLT.

Talvez você deva dar uma olhada em algumas das outras linguagens de marcação disponíveis.Acredito que Jeff fez um artigo sobre esse mesmo tópico relacionado ao Stack Overflow.

HTML é uma linguagem de marcação humana?

Eu daria uma olhada no que ele escreveu.Você provavelmente encontrará um pacote de software que faça o que deseja "pronto para uso", ou pelo menos muito próximo, em vez de escrever seu próprio material desde o início.

Atualmente estou encarregado de extrair dados de um site público (sim, eu sei).Felizmente, ele está em conformidade com xhtml, então posso usar o xslt para coletar os dados necessários.A solução resultante é legível, limpa e fácil de alterar se necessário.Perfeito!

Eu usei XSLT antes.O grupo de 6 arquivos .xslt (refatorados a partir de um grande) tinha cerca de 2.750 linhas muito antes de eu reescrevê-lo em C#.O código C# tem atualmente 4.000 linhas contendo muita lógica;Eu nem quero pensar sobre o que seria necessário para escrever em XSLT.

O ponto em que desisti foi quando percebi que não ter o XPATH 2.0 estava prejudicando significativamente meu progresso.

Para responder às suas três perguntas:

Eu usei XSLT uma vez há alguns anos.
Acredito que o XSLT pode ser a solução certa em determinadas circunstâncias.(Nunca diga nunca)
Tenho tendência a concordar com a sua avaliação de que é útil principalmente para transformações "simples".Mas acho que, desde que você entenda bem o XSLT, há motivos para usá-lo para tarefas maiores, como publicar um site como XML transformado em HTML.

Acredito que a razão pela qual muitos desenvolvedores não gostam do XSLT é porque eles não entendem o paradigma fundamentalmente diferente no qual ele se baseia.Mas com o recente interesse em programação funcional, poderemos ver o XSLT retornando...

Um lugar onde o xslt realmente brilha é na geração de relatórios.Descobri que é um processo de duas etapas, com a primeira etapa exportando os dados do relatório como um arquivo xml e a segunda etapa gerando o relatório visual a partir do xml usando xslt.Isso permite bons relatórios visuais e, ao mesmo tempo, mantém os dados brutos como um mecanismo de validação, se necessário.

Em uma empresa anterior, fizemos muito com XML e XSLT.XML e XSLT grandes.

Sim, há uma curva de aprendizado, mas você tem uma ferramenta poderosa para lidar com XML.E você pode até usar XSLT em XSLT (o que às vezes pode ser útil).

O desempenho também é um problema (com XML muito grande), mas você pode resolver isso usando XSLT inteligente e fazer algum pré-processamento com o XML (gerado).

Qualquer pessoa com conhecimento de XSLT pode alterar a aparência do produto final porque ele não está compilado.

Eu pessoalmente gosto de XSLT, e você pode querer dar a sintaxe simplificada uma olhada (sem modelos explícitos, apenas um arquivo HTML antigo normal com algumas tags XSLT para inserir valores nele), mas simplesmente não é para todos.

Talvez você queira apenas oferecer aos seus autores uma interface simples de Wiki ou Markdown.Existem bibliotecas para isso também, e se o XSLT não estiver funcionando para você, talvez o XML também não esteja funcionando para eles.

XSLT não é o fim de tudo da transformação xml.No entanto, é muito difícil julgar com base nas informações fornecidas se esta teria sido a melhor solução para o seu problema ou se existem outras abordagens mais eficientes e sustentáveis.Você diz que os autores poderiam inserir seu conteúdo em um formato simplificado – que formato?Caixas de texto?Para que tipo de HTML você estava convertendo?Para avaliar se o XSLT é a ferramenta certa para o trabalho, seria útil conhecer mais detalhadamente os recursos dessa transformação.

Gosto de usar XSLT apenas para alterar a estrutura em árvore de documentos XML.Acho complicado fazer qualquer coisa relacionada ao processamento de texto e relegar isso a um script personalizado que posso executar antes ou depois de aplicar um XSLT a um documento XML.

O XSLT 2.0 incluía muito mais funções de string, mas acho que não é uma boa opção para a linguagem e não há muitas implementações do XSLT 2.0.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow