it-swarm-pt.tech

XSLT vale a pena?

Há um tempo atrás, iniciei um projeto em que projetei um esquema XML em estilo html para que os autores pudessem escrever seu conteúdo (material educacional do curso) em um formato simplificado que seria transformado em HTML via XSLT. Eu brinquei (lutei) com ele por um tempo e cheguei a um nível muito básico, mas depois fiquei muito irritado com as limitações que estava encontrando (o que pode muito bem ter sido uma limitação do meu conhecimento) e quando li um blog sugerindo abandonar XSLT e apenas escreva seu próprio analisador de XML para qualquer que seja o idioma que você escolher, eu pulei avidamente para isso e funcionou brilhantemente.

Eu ainda estou trabalhando nisso até hoje ( na verdade, eu deveria estar trabalhando nisso agora, em vez de jogar no SO), e estou vendo mais e mais coisas que fazem acho que a decisão de abandonar o XSLT foi boa.

Sei que o XSLT tem seu lugar, pois é um padrão aceito e que, se todos estiverem escrevendo seus próprios intérpretes, 90% deles terminarão em TheDailyWTF . Mas, como é uma linguagem do estilo funcional em vez do estilo procedural com o qual a maioria dos programadores está familiarizado, para alguém que está embarcando em um projeto como o meu, recomendo que eles sigam o caminho que eu fiz ou o coloquemos com o XSLT ?

111
nickf

Vantagens do XSLT:

  • Específico do domínio para XML, portanto, por exemplo, não é necessário citar XML literal na saída.
  • Suporta XPath/XQuery, que pode ser uma ótima maneira de consultar DOMs, da mesma maneira que expressões regulares podem ser uma boa maneira de consultar cadeias de caracteres.
  • 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 maneira bonita. Mas, novamente, não é muito pior do que o seu SSI típico.
  • Não faz certas coisas que a maioria dos programadores dá como certa. Por exemplo, a manipulação de strings pode ser uma tarefa árdua. Isso pode levar a "momentos infelizes" quando iniciantes criam códigos e, em seguida, buscam freneticamente na web por dicas de como implementar funções que eles supunham estarem lá e não se deram tempo para escrever.
  • Linguagem funcional.

Uma maneira de obter comportamento processual, a propósito, é encadear várias transformações. Após cada etapa, você tem um novo DOM para trabalhar, que reflete as alterações nessa etapa. Alguns processadores XSL têm extensões para efetivamente fazer isso em uma transformação, mas esqueço os detalhes.

Portanto, se seu código é basicamente produzido e não possui muita lógica, o XSLT pode ser uma maneira muito interessante de expressá-lo. Se houver muita lógica, mas principalmente os formulários incorporados ao XSLT (selecione todos os elementos que se parecem com blá e para cada um com blá), é provável que seja um ambiente bastante amigável. Se você gosta de pensar em XML sempre, experimente o XSLT 2.

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

Os analisadores XML criados em casa geralmente são incompletos (nesse caso, você será destravado algum dia) ou então não são muito menores do que algo que você poderia ter saído da prateleira (nesse caso, você provavelmente está perdendo seu tempo) e você oferece inúmeras oportunidades para introduzir graves problemas de segurança em relação a entradas maliciosas. Não escreva um, a menos que você saiba exatamente o que ganha fazendo isso. O que não significa que você não possa escrever um analisador para algo mais simples que XML como formato de entrada, se você não precisar de tudo o que o XML oferece.

63
Steve Jessop

Tanta negatividade!

Estou usando o XSLT há alguns anos e realmente amo isso. A principal coisa que você precisa entender é que não é uma linguagem de programação, é uma linguagem de modelagem (e, a esse respeito, acho indescritivelmente superior ao asp.net/spit).

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

Depois, há as habilidades do utilitário: lavar espaços de nome, reconhecer definições de esquema díspares, mesclar documentos.

deve ser melhor lidar com o XSLT do que desenvolver seus próprios métodos internos. Pelo menos o XSLT é um padrão e algo para o qual você pode contratar, e se realmente for um problema para sua equipe, é muito natural permitir que você mantenha a maior parte da sua equipe trabalhando apenas com XML.

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

Pessoalmente, acho que é uma das coisas mais limpas que encontrei na minha carreira e acredito que todos os seus problemas aparentes (depuração, manipulação de strings, estruturas de programação) se resumem a um entendimento defeituoso da ferramenta.

Obviamente, acredito firmemente que "vale a pena".

88
annakata

Eu tenho que admitir um viés aqui, porque ensino XSLT como meio de vida. Mas, pode valer a pena cobrir as áreas em que vejo meus alunos trabalhando. Eles se dividem em três grupos em geral: publicações, bancos e web.

Muitas das respostas até agora podem ser resumidas como "não é bom para criar sites" ou "não é nada como a linguagem X". Muitos técnicos passam por suas carreiras sem 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 procedural, por exemplo). Muitas pessoas estão respondendo aqui - eu nunca comecei com Java, mas não vou me incomodar em criticar a linguagem por causa disso).

Em muitas circunstâncias, é uma ferramenta inadequada para criar sites - uma linguagem de programação de uso geral pode ser melhor. Geralmente, 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. O XSLT certamente não é a única ferramenta aplicável nesse 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 eu vejo usam uma caixa DataPower em geral. Este é um dispositivo XML e é usado para ficar entre os serviços 'falando' diferentes dialetos XML. A transformação de uma linguagem XML para outra é quase trivial no XSLT e o número de alunos que freqüentam meus cursos sobre isso está aumentando.

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

Alguém acima comentou que os scripts tendem a ficar abaixo de 60 linhas ou se tornam difíceis de manejar. Se ele se tornar pesado, as chances são de que o codificador não tenha realmente a idéia - o XSLT é uma mentalidade muito diferente de muitas outras línguas. Se você não entender, não funcionará.

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

27
Nic Gibson

Usamos o XSLT extensivamente para coisas como documentação e para fazer 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 texto sem formatação. Com o XSLT, podemos criar facilmente nossos próprios formatos de documentação, permitindo gerar automaticamente o conteúdo de maneira genérica e tornar o conteúdo mais legível. Por exemplo, quando publicamos notas de versão, podemos criar 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 DocBook acima), terminamos com notas de versão agradáveis ​​(PDF ou HTML geralmente), onde os IDs de 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 erros sobre o que mudou entre as versões.

O outro local em que consideramos o XSLT útil é realmente o nosso principal produto. Às vezes, ao fazer interface com sistemas de terceiros, precisamos processar os dados em uma página HTML complexa. A análise do HTML é feia; portanto, alimentamos os dados por meio de algo como TagSoup (que gera eventos XML SAX apropriados, essencialmente nos permitindo lidar com o HTML como se fosse XML escrito corretamente) e, em seguida, podemos executar alguns XSLT contra ele, para transformar os dados em um formato "estável conhecido" com o qual possamos trabalhar. Ao separar essa transformação em um arquivo XSLT, isso significa que, se e quando o formato HTML for alterado, o aplicativo em si não precisará ser atualizado. Em vez disso, o usuário final poderá editar o arquivo XSLT ou 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 existem usos para o XSLT. Não é o idioma mais fácil do mundo para usar, mas definitivamente não está morto, e da minha perspectiva ainda tem muitos usos bons.

24
Adam Batkin

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

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 processuais mais comuns OO ou processuais 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 à apresentação, ele falha no departamento de facilidade de uso. Acredito que é por isso que realmente não pegou.

19
Bill Karwin

Lembro-me de todo o hype em torno do XSLT quando o padrão foi lançado recentemente. Toda a emoção de poder criar uma interface de usuário HTML inteira com uma transformação "simples".

Vamos ser sinceros, é difícil de usar, quase impossível de depurar, geralmente insuportavelmente lento. O resultado final é quase sempre peculiar e menos do que o ideal.

Mais cedo eu vou morder minha própria perna do que usar um XSLT enquanto houver melhores maneiras de fazer as coisas. Ainda tem seus lugares, é bom para tarefas simples de transformação.

12
Crusty

Eu usei o XSLT (e também o XQuery) extensivamente para várias coisas - para gerar código C++ como parte do processo de criação, para produzir documentação a partir de comentários de documentos e dentro de um aplicativo que precisava trabalhar com XML em geral e XHTML em particular muito . 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 (fazia muitas coisas - cabeçalhos para clientes, proxies/stubs remotos, wrappers COM, wrappers .NET, ORM - para nomear um pouco). Eu a herdei de outro cara que realmente não entendia bem a língua, e as partes mais antigas eram, consequentemente, uma bagunça. No entanto, as coisas mais recentes que escrevemos foram mantidas sãs e legíveis, e não me lembro de nenhum problema em particular com isso. Certamente não foi tão difícil quanto fazê-lo para C++.

Por falar em versões, lidar com o XSLT 2.0 definitivamente ajuda a mantê-lo saudável, mas a versão 1.0 ainda é boa para transformações mais simples. Em seu nicho, é uma ferramenta extremamente útil, e a produtividade que você obtém de certos recursos específicos do domínio (mais importante, o envio dinâmico via correspondência de modelos) é difícil de igualar. Apesar da percepção da verbosidade da sintaxe baseada em XML do XSLT, a mesma coisa no LINQ to XML (mesmo em VB com literais XML)) costumava ser várias vezes mais longa. Muitas vezes, no entanto, isso não é merecido. por causa do 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, portanto é boa desde que você a use adequadamente e para a finalidade a que se destina. Eu realmente gostaria que houvesse uma implementação .NET nativa adequada do XSLT 2.0.

10
Pavel Minaev

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

  1. Escrevo pequenas transformações XSLT para fazer edições em massa em nossos arquivos maven pom.xml.

  2. Eu 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 atrás do celeiro.

  3. Eu usei transformações para refatorar esquemas XML.

  4. Eu trabalhei em torno de algumas limitações no XSLT usando-o para gerar um XSLT para fazer o trabalho real. (Já tentou escrever um XSLT que produz 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 contornar o XML que está processando do que outras abordagens que tentei, que pareciam desnecessariamente com perdas ou simplesmente entendiam mal o XML. O XSLT é desagradável, mas acho que usar Oxigênio o torna suportável.

Dito isso, estou investigando o uso de Clojure (um LISP) para realizar transformações de XML, mas ainda não cheguei o suficiente para saber se essa abordagem me trará benefícios.

9
bendin

Pessoalmente, usei o XSLT em um contexto totalmente diferente. O jogo de computador em que eu estava trabalhando na época usava toneladas de páginas da interface do usuário definidas usando XML. Durante um grande refatorador logo após o lançamento, queríamos mudar a estrutura desses documentos XML. Fizemos com que o formato de entrada do jogo seguisse uma estrutura muito melhor e com mais consciência do esquema.

O XSLT parecia a escolha perfeita para esta tradução do formato antigo -> Novo formato. Em duas semanas, tive uma conversão funcional de antiga para nova para nossas centenas de páginas. Também pude usá-lo para extrair muitas informações no layout de nossas páginas da interface do usuário. Criei listas de quais componentes estavam embutidos nos quais, relativamente fácil, usei o XSLT para gravar em nossas definições de esquema.

Além disso, proveniente de C++, era uma linguagem muito divertida e interessante de dominar.

Eu acho que, como uma ferramenta para traduzir XML de um formato para outro, é fantástico. No entanto, não é a única maneira de definir um algoritmo que aceita XML como entrada e gera 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 o seu próprio em C++/Python/o que for.

Específico para o seu exemplo, eu imaginaria que a melhor idéia seria criar seu próprio XML-> XML converter que segue sua lógica de negócios. Em seguida, escreva um tradutor XSLT que apenas saiba sobre formatação e não faça nada inteligente. Esse pode ser um meio termo agradável, 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.

7
Tom Leys

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

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

6
Alohci

Eu recomendaria definitivamente para ficar. Especialmente se você estiver usando o visual studio, que possui ferramentas de edição, visualização e depuração para o XSLT.

Sim, é uma dor enquanto você está aprendendo, mas a maior parte da dor está relacionada à familiaridade. A dor diminui à medida que você aprende o idioma.

O W3schools possui dois artigos que são especialmente úteis: http://www.w3schools.com/xpath/xpath_functions.asphttp://www.w3schools.com/xsl/xsl_functions. asp

4
Nat

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

3
David Robbins

Eu achava que o XSLT era uma ótima idéia. Eu quero dizer isso é uma ótima idéia.

Onde falha é a execução.

O problema que descobri com o tempo foi que as linguagens de programação em XML são apenas uma má idéia. Isso torna a coisa toda impenetrável. Especificamente, acho XSLT muito difícil de aprender, codificar e entender. O XML, além dos aspectos funcionais, torna tudo muito confuso. Eu tentei aprendê-lo cerca de 5 vezes na minha carreira, e simplesmente não fica.

Tudo bem, você pode 'utilizá-lo' - acho que esse foi o objetivo do design - mas essa é a segunda falha: todas as ferramentas XSLT do mercado são simplesmente ... porcaria!

3
Schneider

Eu usei XML, XSD e XSLT em um projeto de integração entre sistemas de banco de dados muito semelhantes em algum momento de 2004. Eu tive que aprender XSD e XSLT do zero, mas não foi difícil. O melhor dessas ferramentas foi que ele me permitiu escrever código C++ independente de dados, confiando no XSD e no 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 empregava as bibliotecas Xerces.

Por interesse: o XSD principal era de 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 muitos problemas para aprender a natureza declarativa XSD e XSLT, descobri que outros programadores de C/C++ tinham grandes problemas em se ajustar à maneira declarativa. Quando eles viram que era isso, ah processual eles murmuraram, agora que eu entendo! E eles procederam (trocadilho?) Para escrever XSLT processual! O problema é que você precisa aprender XPath e entender os eixos do XML. Lembra-me dos antigos programadores de C ajustando-se ao emprego de OO ao escrever C++.

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

3
Sam

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

Infelizmente, o idioma contém várias limitações (por exemplo, a capacidade de transformar a saída de outra transformação), o que significa que é ocasionalmente frustrante trabalhar com isso.

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

3
Eamon Nerbonne

Eu achei o XSLT bastante difícil de trabalhar.

Tive experiência trabalhando em um sistema parecido com o 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 também poderiam ser XHTML, além de saberem que XSL era um padrão para a transformação entre XML formatos. Portanto, os "arquitetos" (com os quais quero dizer pessoas que pensam profundamente no design, mas aparentemente nunca codificam) decidiram que nossa camada frontal seria implementada escrevendo scripts XSLT que transformavam os dados no XHTML para exibição.

A escolha acabou sendo desastrosa. XSLT, ao que parece, é uma dor de escrever. E, portanto, todas as nossas páginas eram difíceis de escrever e manter. Teríamos feito muito melhor se usássemos JSP (isso era 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 o XSLT é que ele é escrito em XML e traduz de XML para XML ... é bastante 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 no XSLT como eu fiz, você só precisa escrever UM bit de código no XSLT (o código a ser convertido dos modelos para exibição). Mas parece que você pode ter encontrado o mesmo tipo de dificuldade que eu. Eu diria que tentar interpretar uma DSL (linguagem específica de domínio) baseada em XML como você está fazendo NÃO é um dos pontos fortes do XSLT. (Embora PODE fazer o trabalho ... afinal, ele IS Turing completo!)

No entanto, se o que você tinha era mais simples: você tem dados em um formato XML e queria fazer alterações simples - não uma DSL completa da descrição da página, mas algumas modificações simples e diretas, o XSLT é uma excelente ferramenta para esse fim. Sua natureza declarativa (não processual) é realmente uma vantagem para esse fim.

- Michael Chermside

3
mcherm

Tudo se resume ao que você precisa. Sua principal força é a facilidade de manutenção da transformação, e escrever seu próprio analisador geralmente elimina isso. Com isso dito, à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 precisar alterar outro código, não é grande coisa.

Quanto à feiura do XSL, sim, é feia. Sim, é preciso algum tempo para se acostumar. Mas uma vez que você pega o jeito (não deve demorar muito OMI), na verdade é uma navegação tranquila. As transformações compiladas são executadas rapidamente na minha experiência, e você pode certamente depurar nelas.

2
SpongeJim

O especificação XSLT define XSLT como "uma linguagem para transformar documentos XML em outros documentos XML". Se você está tentando fazer algo além do processamento de dados mais básico no XSLT, provavelmente existem soluções melhores.

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

2
Eric Schoonover

Ainda acredito que o XSLT pode ser útil, mas é uma linguagem feia e pode levar a uma bagunça terrível, ilegível e inatingível. Em parte porque XML não é legível por humanos o suficiente para criar 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 é usada 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 XML (como JiBX em Java) que converterá seu XML diretamente em um objeto.

2
Tom Martin

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

Isso nos permite fazer alterações facilmente no layout da documentação sem fazer nenhuma codificação. É apenas uma questão de mudar 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, usando o XSLT, você está trabalhando mais próximo do domínio do problema (HTML). Eu sempre considero isso uma boa ideia.

Por fim, se seu sistema atual funcionar, deixe-o em paz. Eu nunca sugeriria descartar o código existente. Se eu estivesse começando do zero, usaria o XSLT, mas no seu caso, usaria o que você tem.

2
Mashed Potato

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

Escrevi aplicativos da Web que usam uma linguagem OO (C # no meu caso) para manipular a camada de dados/processamento, mas produzem XML em vez de HTML. Isso pode ser consumido diretamente pelos clientes como uma API de dados ou renderizada como HTML por XSLTs. Como o C # estava produzindo XML estruturalmente compatível com esse uso, tudo era muito suave e a lógica de apresentação mantida declarativa. Era mais fácil seguir e alterar do que enviar as tags de C #.

No entanto, conforme você exige mais lógica de processamento no nível XSLT, ela é complicada e detalhada - mesmo que você "obtenha" o estilo funcional.

É claro que 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 que o XML tradicionalmente foi transformado pelo XSLT. Mas, por enquanto, o XSLT ainda é uma tecnologia importante e útil.

2
philsquared

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

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

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

Qualquer pessoa com conhecimento de XSLT pode alterar a aparência do produto acabado porque não é compilado.

1
Toon Krijthe

Eu usei o XSLT antes. O grupo de 6 arquivos .xslt (refatorado de um grande) tinha cerca de 2750 linhas muito antes de eu reescrevê-lo em C #. O código C # é atualmente 4000 linhas contendo muita lógica; Eu nem quero pensar no que isso levaria para escrever no XSLT.

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

1
Sam Harwell

Para responder às suas três perguntas:

  1. Eu usei o XSLT uma vez há alguns anos.
  2. Eu acredito que o XSLT poderia ser a solução certa em determinadas circunstâncias. (Nunca diga nunca)
  3. Costumo concordar com sua opinião de que ela é útil principalmente para transformações "simples". Mas acho que, desde que você entenda bem o XSLT, há um argumento a ser usado para tarefas maiores, como a publicação de um site como XML transformado em HTML.

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

1
Dawie Strauss

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

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

HTML é uma linguagem de marcação humana?

Eu daria uma olhada no que ele escreveu. Você provavelmente pode encontrar um pacote de software que faça o que deseja "pronto para uso" ou, pelo menos, muito próximo, em vez de escrever suas próprias coisas do zero.

1
Jason Jackson

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 do xml usando xslt. Isso permite relatórios visuais agradáveis, mantendo os dados brutos como um mecanismo de validação, se necessário.

1
Jack Ryan

Eu pessoalmente gosto do XSLT, e você pode dar uma olhada em sintaxe simplificada (sem modelos explícitos, apenas um arquivo HTML antigo e regular com algumas tags XSLT para cuspir valores nele), mas apenas é para todos.

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

1
brianary

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

1
Goran

Eu acho que você fez a coisa certa. Na minha experiência, os desenvolvedores de XSLT estão entre os mais difíceis de contratar, porque é uma linguagem que nunca foi percebida pelos desenvolvedores da Web nem pelos programadores casuais.

Então você acaba tendo que pagar o prêmio "programador avançado que conhece um idioma fora do mainstream", mas por um idioma que provavelmente não é o favorito desse programador.

0
Larry OBrien

Eu tive uma experiência bastante boa com o XSLT, mas não estava me transformando em HTML. Pode ser que o combo XSLT-HTML seja muito difícil para fazer as coisas.

0
Rolf

Na minha opinião sim.

Para um ótimo exemplo de um uso muito legal do XSLT, confira o arsenal de world of warcraft da Blizzard.

http://www.wowarmory.com

0
Vinh

O XSLT 1.0 é um dos códigos mais portáteis, pelo menos em computadores de mesa e servidores. Porque ele tem um (e muitas vezes) tempo de execução na maioria desses sistemas:

  • O Microsoft Windows possui MSXML que está instalado no sistema básico desde pelo menos o Windows 2000. Ele pode ser usado no MSIE, na linha de comando (usando o WSH) ou em aplicativos do Office
  • O Java Runtime Environment (JRE) possui um tempo de execução XSLT e um JRE é instalado na maioria dos desktops
  • Quase todos os principais navegadores da web têm um. Opera é a exceção.
  • Existem implementações gratuitas instaladas por padrão nos principais sistemas operacionais baseados em GNU (libxslt, xsltproc)
  • Não verifiquei o MacOS X, mas ele tem pelo menos uma implementação no Safari

Isso facilita a criação de alguns aplicativos que exigem portabilidade e instalação leve/sem instalação.

Além disso, o XSLT requer apenas um tempo de execução (nenhum compilador é necessário) e você pode criar o código apenas com qualquer editor de texto. Assim, você pode criar programas facilmente (bem, depois de dominar o idioma) em qualquer área de trabalho.

0
dolmen

Eu usei XSLT extensivamente ... por algumas horas. É legal para coisas como alterar nomes de elementos ou filtrar um documento de entrada (removendo coisas que você não precisa).

Qualquer outra coisa fica complexa muito rapidamente. Essa complexidade herdada, mais a falta da maioria das coisas que você usa de outras linguagens de programação (como variáveis) e as maneiras fáceis de tornar as expressões XPath ilegíveis, realmente machucam.

No final, o XSLT sofre de um cisma: os programadores não gostam por causa das limitações e todos os outros não podem usá-lo (por exemplo, web designers ou qualquer outro tipo de não programador).

Se o XSLT tivesse sido promovido como algum tipo de SQL para XML, as coisas seriam um pouco diferentes. Primeiro, as pessoas nem se incomodariam em olhar para ele. E aqueles que o fizeram não teriam se surpreendido com a dor.

0
Aaron Digulla

Eu acho que o conceito é sólido, talvez a execução não seja tão 'limpa' quanto poderia ser.

No entanto, acho que deve ser tratado como uma ferramenta; pode não ser aconselhável usá-lo em todos os casos; no entanto, nunca se deve ignorar uma ferramenta ao resolver soluções.

Eu vi um XSLT muito bom e também um uso muito ruim do XSLT, e concluo que alguns deles podem estar relacionados à habilidade do desenvolvedor. Eu acho que é o que exige que o desenvolvedor pense em vários domínios ao mesmo tempo.

É o futuro? talvez não, talvez haja melhores soluções ..

Não sei que nova tecnologia virá, mas pelo menos é melhor aprendê-la, aumentar o próprio conjunto de ferramentas não pode ser uma coisa ruim, com certeza?

0
Darknight

Eu uso o XSLT para corrigir erros em arquivos xml muito complexos. Então, em vez de manipular os erros no xml, uso o xslt para corrigi-los.

Isso é ótimo. Porque a linguagem é muito poderosa e se encaixa no caso de uso xml. Para fazer as mesmas coisas em uma linguagem de programação usual, levava muito tempo para adaptar meu código sempre que surgia um novo sabor.

Também é útil migrar as soluções do visual studio sem deixar que a Microsoft decida quais coisas mudar. Então converta uma solução. Veja o que mudou. Reverta as coisas que você não deseja alterar e execute o script xslt executando o trabalho em todos os arquivos.

Então, eu nunca o usei para fazer apresentações na Web ou algo assim, mas isso me ajuda nos meus problemas baseados em xml. E para resolver esses problemas, é realmente muito poderoso e vale a pena dar uma olhada.

0
Totonga

XSLT não é a transformação xml final. No entanto, é muito difícil julgar com base nas informações fornecidas se essa seria a melhor solução para o seu problema ou se existem outras abordagens mais eficientes e sustentáveis. Você diz que os autores podem inserir seu conteúdo em um formato simplificado - qual formato? Caixas de texto? Em que tipo de html você o estava convertendo? Para julgar se o XSLT é a ferramenta certa para o trabalho, ajudaria a conhecer os recursos dessa transformação com mais detalhes.

0
Shmoggle

Eu também fiz incursões no mundo do XSLT e achei um pouco estranho em alguns lugares. Acho que meu principal problema foi a dificuldade de converter XML de "dados puros" em uma página HTML completa. Em retrospectiva, talvez o uso do XSLT para gerar um fragmento de página que pudesse ser composto juntamente com outros fragmentos usando o Server Side Scripting (por exemplo, SSI) teria resolvido muitos dos meus problemas.

Um dos possíveis erros foi tentar construir um layout de página comum para cercar meus dados, importando XHTML ou outros dados XML usando a função document ().

O outro erro foi tentar fazer coisas programáticas, como criar um modelo geral para gerar tabelas em dados XML com lógica que usava cores de linhas de segundo plano diferentes para linhas com determinados valores e permitir que você especificasse algumas colunas a serem filtradas.

Sem mencionar a tentativa de construir uma lista de valores de dados XML que parecia apenas ser solucionável usando chamadas de modelo recursivas.

O que eu ganhei? Bem, a fonte da página são dados XML bem ali e disponíveis para o visualizador. Os dados e a apresentação são ordenadamente separados.

Eu faria isso de novo? Provavelmente não, a menos que eu realmente quisesse separação de dados/apresentação em uma página estática. Caso contrário, eu provavelmente escreveria um aplicativo Rails ou Java EE que poderia gerar uma visualização XML ou HTML usando modelagem - todos os benefícios, mas com uma linguagem de programação muito mais natural (para mim) na ponta dos dedos.

0
Mike Tunnicliffe

Gosto de usar o XSLT apenas para alterar a estrutura em árvore dos documentos XML. Acho complicado fazer algo relacionado ao processamento de texto e relegar isso a um script personalizado que eu possa executar antes ou depois de aplicar um XSLT a um documento XML.

O XSLT 2.0 incluiu muito mais funções de string, mas acho que não é um bom ajuste para a linguagem, e não há muitas implementações do XSLT 2.0.

0
Ben

Em termos de produtividade, seria melhor usar uma das bibliotecas no estilo jQuery - pyQuery, phpQuery etc. A maioria das bibliotecas XML é péssima e o XSLT é essencialmente apenas outra biblioteca XML empacotada como uma linguagem completa, mas sem um conjunto decente de ferramentas . O jQuery torna incrivelmente fácil atravessar e manipular dados de estilo XML no idioma de sua escolha.

0
Jimmy

Falando sobre interoprabilidade, XML é um padrão para armazenamento de informações. Muitas ferramentas produzem saída em XML, e qual a melhor (ou mais fácil) maneira de apresentá-la do que incorporar um navegador ao seu aplicativo e formatar o XML e colocá-lo no navegador.

0
Midhat

Preciso trabalhar com o XSLT aqui, porque alguém pensou que seria uma boa idéia resolver um determinado problema: precisamos extrair alguns dados de vários arquivos XML e juntá-los a diferentes formatos de saída para diferentes ferramentas que processam mais.

Fisrt Eu pensei que o XSLT é uma ótima idéia, porque é um padrão em que você pode confiar. Isso vale para tarefas simples de formatação, nas quais você não precisa de muita lógica ou algoritmos de programação em seu código.

Mas: é uma curva de aprendizado bastante gradual, pois é não processual. Se você se acostumou à programação procedural (C, Java, Perl, PHP, etc), perderá muitas estruturas comuns ou se perguntará sobre coisas que apenas dão sorte em cubos e às vezes não são realmente legíveis por um olho destreinado. Por exemplo, escrevendo código "reutilizável": se você precisar fazer algo repetidamente em locais diferentes, na programação de procedimentos, você definiria uma função para fazê-lo. Você também pode obter essas coisas no XSLT, mas é necessário mais código para escrever e não é tão legível/compreensível como seria uma função normal.

O principal problema que tenho é que muitas pessoas vindas de um processo procedente já trabalhavam nos arquivos XSLT e quase todo mundo simplesmente "emulava" o que ele precisava.

Então, como conclusão: não vejo mais o XSLT como a "solução definitiva". De fato, é difícil ler ou escrever algumas construções no XSLT. Na maioria dos casos, você terá que pensar no aplicativo: Para uma transformação simples, provavelmente usarei o XSLT novamente. Mas, para softwares mais complexos, não o utilizarei novamente.

0
Murphy