Existem boas razões para usar, aprender ou recomendar XSLT? [fechadas]

Sou desenvolvedor há 8 anos. Usamos o XSLT principalmente para transformar XML em HTML. Também o usamos para transformação de XML em XML.

Mas temos substituto para tudo agora. O HTML pode ser criado confortavelmente por meio de linguagens de programação como o ASP.Net. XML pode ser lido e manipulado em qualquer linguagem de alto nível padrão. Como a programação no XSLT é um pouco complexa, qualquer um prefere trabalhar nas linguagens de programação mais recentes.

Agora minha pergunta: o XSLT será uma escolha significativa no futuro, sem considerar o fato de manter o XSLT já desenvolvido? Posso recomendar novos programadores para estudar XSLT?

Existem alguns casos importantes em que o XSLT pode ser uma boa escolha:

• O software ETL ( extrair, transformar, carregar ) pode, em alguns casos, usar XSLT. Por exemplo, pode ser uma boa opção quando os dados extraídos e os dados a serem carregados estão em um formato XML e a transformação pode ser alterada sem a necessidade de recompilar o aplicativo.

• Alguns aplicativos que armazenam dados em XML usam o XSLT para apresentar esses dados em um formato legível por humanos¹. Por exemplo, o Windows Live Messenger armazena o rastreamento de mensagens como XML, mas quando você abre o histórico no WLM, ele mostra uma tabela bonita, que na verdade é HTML criada por meio do XSLT.

• Alguns sites orientados a desenvolvedores ou dados podem querer dar acesso ao XML se a intenção for usar as páginas do site programaticamente². De alguma forma, é melhor do que usar os analisadores HTML, especialmente porque o código HTML pode ser alterado a qualquer momento.

• O XSLT, quando usado em sites, permite uma separação estrita entre HTML e code-behind, o que permite contratar um desenvolvedor para code-behind e outro desenvolvedor para coisas em HTML / CSS. Veja o ponto 1 na minha resposta a outra pergunta .

O XSLT será uma escolha significativa no futuro? Bem, hoje não é uma escolha significativa e duvido que o uso do XSLT aumente com o tempo. Ignoro a razão disso, mas muitos desenvolvedores não gostam de XML e odeiam XSLT.

Você pode recomendar novos programadores para estudar XSLT? Certo! Não apenas o XSLT pode ser usado em algumas circunstâncias quando outras abordagens seriam mais difíceis, mas também o XSLT tem uma abordagem muito específica que outras linguagens não possuem.

^{This Com isso, quero dizer que XML não é realmente legível por humanos: se você pedir a uma pessoa que não trabalha com TI que leia XML, ele ficará horrorizado.
² Eu sei que existem serviços da web. Mas, às vezes, é mais fácil e mais simples, em todas as páginas, construir um objeto dinâmico, serializá-lo em XML e transformá-lo em HTML através de XSLT ou permitir que o bot acesse o XML diretamente.}

O XSLT está praticamente morto porque apenas alguns entusiastas ainda o usam. No entanto, não há alternativa real para isso. Se você se concentrar apenas em um único caso de uso, como, por exemplo, renderização de páginas HTML a partir de documentos semânticos, você encontrará ferramentas melhores. Se você procurar mecanismos de modelo de geração de código, novamente existem ferramentas melhores. O mesmo para transformação de documento.

Mas se você procurar uma ferramenta que suporte todos esses casos de uso muito bem em todas as plataformas, as opções ficarão muito limitadas. Se você já possui um documento XML e precisaria transformá-lo em algo para poder usar sua ferramenta, provavelmente é melhor apenas processar seus dados com XSLT (ou XQuery).

De qualquer forma, você pode aprender XSLT em questão de dias, talvez semanas. Não vai doer para você fazer uma experiência em primeira mão. Apenas tente. Vale pelo menos o esforço de armazenar esse tipo de padrão (transformações baseadas em regras) em sua cabeça para uso posterior. Isso por si só justifica o aprendizado de XSLT.

Hmm, gostaria de saber se as APIs de alto nível que criam HTML a partir do código usam qualquer XSLT "por baixo do capô" ...

O XSLT é usado extensivamente onde trabalho para transformar XML de um formato de origem para vários outros. Também pode ser usado para transformar XML em saída não XML. Não fiz muito disso, mas ouvi dizer que está sendo feito para direcionar PDF e PostScript, entre outros.

Sim.

Vamos dar um bom exemplo: relatórios de teste de unidade em integração contínua. A maioria dos programas de teste de unidade e cobertura de código simplesmente gera toneladas de XML ilegível. Mas com alguns XSLTs simples, você pode criar uma dúzia de relatórios úteis a partir dos mesmos dados. E outras pessoas podem reutilizar esses relatórios.

Agora você pode escrevê-las em qualquer idioma que a ferramenta de IC use para plug-ins, mas se você não conhece esse idioma (por exemplo, você é um desenvolvedor .NET, usando Jenkins), não há necessidade de aprendê-lo. Basta usar um plug-in que já aplica um XSLT a um arquivo XML e escrever alguns XSLTs úteis.

Sempre haverá escolha e variedade nas linguagens de programação, e as razões pelas quais uma pessoa é escolhida em preferência à outra têm tanto a ver com familiaridade e moda quanto com critérios objetivos, como funcionalidade, produtividade e desempenho. Ninguém pode prever a moda, portanto, ninguém pode prever tendências futuras em linguagens de programação. Mas há muitas pessoas que ultrapassaram as barreiras iniciais de aprendizado do XSLT e acham que é uma ferramenta extremamente produtiva para uma variedade muito grande de tarefas (possivelmente uma variedade mais ampla do que jamais foi projetada para enfrentar).

Para muitas das tarefas em que vejo o XSLT sendo usado (e para as que eu o uso sozinho), escrever código Java ou ASP para fazer o trabalho seria um desperdício terrível do orçamento do seu empregador. Mas talvez não, se você é bom em escrever Java e ruim em escrever XSLT.

XSLT não é legível por humanos. As meta-informações (as tags) ocupam muito espaço sobre as informações reais (texto, solicitações xpath). Um bom código deve parecer uma documentação e esse não é o caso do XSLT. É um bom formato de persistência para ferramentas de mapeamento.

Uma boa linguagem de transformação deve permitir visualizar o resultado da transformação e visualizar o fluxo de transformação (IF, ELSE, FOR, WHILE) simultaneamente. isso é importante para a manutenção. Em relação a esse aspecto, o Velocity ou o GenearateXY são melhores que o XSLT. O GenerateXY é um pouco melhor, pois separa a visualização e o fluxo. Enquanto o Velocity, infelizmente, você precisa interromper o recuo da visualização para fornecer um fluxo legível.

O único ponto positivo no XSLT é que ele se preocupa com a modularidade usando e até abusando dos elementos "xsl: template". O problema disso é que ele é bom para uma linguagem de processamento de dados (Java, C, ...), mas muito secundário para uma linguagem de apresentação.

De fato

Algo provavelmente substituirá o XSLT um dia, pois é um pouco complicado de aprender e usar. No entanto, atualmente não há uma linguagem de modelo / transformação disponível tão flexível e "pura" em sua implementação.

O XSL-T pode ser usado para alguns propósitos diferentes:

• Você pode "criar" conteúdo no formato digamos HTML a partir de dados usando um modelo
• Você pode converter de um formato xml para outro
• Você pode manipular xml em outro formato, talvez mostrar um subconjunto

Basicamente, tudo isso é o mesmo, no entanto, a transformação de um arquivo de dados XML em outro. Agora, vamos ver algumas ferramentas diferentes que poderíamos usar em vez do XSLT.

Se quiséssemos manipular o conteúdo de uma página XHTML, por exemplo, poderíamos usar o regexp, mas o regexp é complicado para coisas estruturais. Ele brilha para manipular seqüências de caracteres, mas eu não o usaria para criar um índice para algo ou apresentá-lo em um layout diferente.

O próximo é o ASP.Net. Colocamos nosso layout em nossa página asp e inserimos algum código para as partes dinâmicas. Outra alternativa é abrir mão da parte do layout e gerar tudo, como um banco de dados e o uso de C #, criando a saída desejada.

O problema com a primeira abordagem é que é desajeitado passar de dados descritivos para conteúdo real. Se você tiver algum arquivo de dados contendo números de telefone que deseja apresentar com cabeçalhos para cada letra, mostre um número total de entradas, etc., você precisará ter parte do layout no arquivo de layout e parte no código que está gerando . Outra opção é usar alguma forma de grade da Web, acho que elas são bem bagunçadas e, de repente, você precisa aprender como a grade funciona quando tudo que você queria era produzir algum html específico, considerando os dados.

Tornar-se totalmente dinâmico é certamente uma opção, mas também é bastante desajeitado. Mesmo no melhor caso em que você estiver usando algo como LINQ, terá que misturar código de programação com saída de uma maneira bastante feia. Além disso, não há uma boa maneira de lidar adequadamente com o conteúdo não estruturado e recursivo no estilo de documento que normalmente é o html.

Com o XSLT, você pode criar um modelo para uma determinada tag, exatamente como está ou no contexto de seu pai, para que seja renderizado de maneira diferente se, por exemplo, for pai de outra pessoa.

Uma resposta bastante longa, mas sim, acho que há um grande valor em uma linguagem descritiva de modelos e o XSLT é o melhor e mais padronizado que temos até agora.

A maior falha do XSLT é a incapacidade (em qualquer implementação real) de minimizar a quantidade de documento que precisa ser mantida na memória por vez para um processamento eficiente. Em vez disso, todo o documento é lido em alguma forma de representação DOM e o processamento é feito com relação a isso. Se o documento for muito grande, também serão os requisitos de memória. No entanto, muitas folhas de estilo claramente precisam apenas da tag atual e de algumas outras, por exemplo, os ancestrais da tag, a qualquer momento e, portanto, podem ser processadas com memória mínima e fluxo eficiente.

Sim, em termos de um idioma é estranho, mas isso é apenas uma barreira à entrada. Se você conhece o XSLT, geralmente é mais fácil do que as alternativas - mas se você tiver documentos grandes (ou muitos documentos sendo processados ​​ao mesmo tempo), o impacto na memória do XSLT geralmente força outras alternativas mais demoradas.

De fato, acho que é mais eficiente usar XSL do que outra linguagem para apresentar dados. Por exemplo, você pode apresentar um XML como PDF usando XSL-FO e pode controlar cada centímetro, mas se você trabalha com RDLC (.NET) por exemplo, verá que é muito difícil apresentar exatamente o que deseja.

Até a evolução / correção é bastante fácil, pois no XSL cada elemento tem seu próprio modelo. Eu acho que a extensão do XSL é mais importante como o XSLT e o XSL-FO. É por isso que essa linguagem ainda será usada no futuro (mas eu realmente espero que seja mais estável e menos complexo).

Trabalho para uma empresa de integração de dados e usamos o XSLT com nossas ferramentas proprietárias como uma ótima solução envolvendo XML para HTML / XML / Ascii.