it-swarm-es.tech

¿Merece la pena XSLT?

Hace un tiempo, comencé con un proyecto en el que diseñé un esquema html-esque XML para que los autores pudieran escribir su contenido (material del curso educativo) en un formato simplificado que luego se transformaría en HTML a través de XSLT. Jugué (luché) con él durante un tiempo y lo llevé a un nivel muy básico, pero luego me molesté demasiado por las limitaciones que encontré (que bien podrían haber sido limitaciones de mi conocimiento) y cuando leí un blog sugiriendo que abandonara XSLT y simplemente escriba su propio analizador de XML-a-lo que sea en el idioma que elija, salté con entusiasmo a eso y funcionó de manera brillante.

Sigo trabajando en ello hasta el día de hoy (en realidad se supone que debo estar trabajando en este momento, en lugar de jugar en SO), y veo más y más Cosas que me hacen pensar que la decisión de abandonar el XSLT fue buena.

Sé que XSLT tiene su lugar, ya que es un estándar aceptado, y que si todos escriben sus propios intérpretes, el 90% de ellos terminará en TheDailyWTF . Pero dado que es un lenguaje de estilo funcional en lugar del estilo de procedimiento con el que la mayoría de los programadores están familiarizados, para alguien que se embarca en un proyecto como el mío, recomendaría que sigan el camino que yo , o sobresalir con XSLT ?

110
nickf

Ventajas de XSLT:

  • Dominio específico de XML, por lo que, por ejemplo, no es necesario citar XML literal en la salida.
  • Admite XPath/XQuery, que puede ser una buena forma de consultar los DOM, de la misma manera que las expresiones regulares pueden ser una buena forma de consultar cadenas.
  • Idioma funcional.

Desventajas de XSLT:

  • Puede ser obscenamente detallado, no tiene que citar XML literal, lo que efectivamente significa que tiene que citar el código. Y no de una manera bonita. Pero, de nuevo, no es mucho peor que su SSI típico.
  • No hace ciertas cosas que la mayoría de los programadores dan por sentado. Por ejemplo, la manipulación de cadenas puede ser una tarea. Esto puede llevar a "momentos desafortunados" cuando los novatos diseñan un código, luego buscan desesperadamente en la web sugerencias sobre cómo implementar funciones que asumieron que solo estarían allí y no se darían tiempo para escribir.
  • Idioma funcional.

Una forma de obtener un comportamiento de procedimiento, por cierto, es encadenar múltiples transformaciones. Después de cada paso, tiene un nuevo DOM para trabajar que refleja los cambios en ese paso. Algunos procesadores XSL tienen extensiones para hacer esto efectivamente en una transformación, pero olvido los detalles.

Por lo tanto, si su código es principalmente de salida y no tiene mucha lógica, XSLT puede ser una forma muy clara de expresarlo. Si hay mucha lógica, pero la mayoría de las formas están integradas en XSLT (seleccione todos los elementos que parecen blah, y para cada salida de bla), es probable que sea un entorno bastante amigable. Si te gusta pensar XML en todo momento, entonces dale una oportunidad a XSLT 2.

De lo contrario, diría que si su lenguaje de programación favorito tiene una buena implementación de DOM que admita XPath y le permita compilar documentos de una manera útil, entonces hay pocos beneficios al usar XSLT. Los enlaces a libxml2 y gdome2 deberían funcionar bien, y no hay vergüenza en apegarse a los lenguajes de propósito general que conoces bien.

Los analizadores XML de cosecha propia suelen ser incompletos (en cuyo caso usted se despegará algún día) o, si no, mucho más pequeño que algo que podría haber sacado de la plataforma (en cuyo caso probablemente esté perdiendo el tiempo), y Tiene muchas oportunidades para introducir problemas de seguridad graves en torno a la entrada maliciosa. No escriba uno a menos que sepa exactamente lo que gana al hacerlo. Lo cual no quiere decir que no pueda escribir un analizador para algo más simple que XML como su formato de entrada, si no necesita todo lo que XML ofrece.

63
Steve Jessop

¡Tanta negatividad!

He estado usando XSLT durante algunos años, y realmente me encanta. La clave que debes tener en cuenta es que no es un lenguaje de programación, es un lenguaje de plantillas (y en este sentido, me parece indescriptiblemente superior a asp.net/spit).

XML es el formato de datos de facto del desarrollo web actual, ya sean archivos de configuración, datos sin procesar o en la representación de memoria. XSLT y XPath le brindan una enormemente poderosa y muy eficiente manera de transformar esos datos en cualquier formato de salida que le interese, brindándole instantáneamente el aspecto MVC de separar la presentación de los datos.

Luego están las habilidades de utilidad: lavar espacios de nombres, reconocer definiciones de esquemas dispares, fusionar documentos.

Es debe ser mejor tratar con XSLT que desarrollar sus propios métodos internos. Al menos XSLT es un estándar y algo para lo que podría contratar, y si realmente es un problema para su equipo, es muy natural que le permita mantener a la mayoría de su equipo trabajando solo con XML.

Un caso de uso en el mundo real: acabo de escribir una aplicación que maneja documentos XML en memoria en todo el sistema y se transforma a JSON, HTML o XML según lo solicite el usuario final. Tuve una solicitud bastante aleatoria para proporcionar como datos de Excel. Un antiguo colega había hecho algo similar programáticamente, pero requería un módulo de algunos archivos de clase y que el servidor tenía instalado MS Office. Resulta que Excel tiene un XSD: nueva funcionalidad con un impacto de código base mínimo en 3 horas.

Personalmente, creo que es una de las cosas más limpias que he encontrado en mi carrera, y creo que todos los problemas aparentes (depuración, manipulación de cadenas, estructuras de programación) se deben a una comprensión errónea de la herramienta.

Obviamente, creo firmemente que "vale la pena".

88
annakata

Tengo que admitir un sesgo aquí porque enseño XSLT para ganarme la vida. Pero, podría valer la pena cubrir las áreas en las que veo a mis alumnos trabajar. En general, se dividen en tres grupos: publicaciones, banca y web.

Muchas de las respuestas hasta ahora pueden resumirse como "no sirve para crear sitios web" o "no es nada como el lenguaje X". Muchas personas de tecnología pasan por sus carreras sin exponerse a lenguajes funcionales/declarativos. Cuando estoy enseñando, las personas experimentadas de Java/VB/C/etc son las que tienen problemas con el lenguaje (las variables son variables en el sentido de álgebra, no en la programación de procedimientos, por ejemplo). Esa es la mayoría de las personas que responden aquí: nunca me he metido con Java, pero no me voy a molestar en criticar el lenguaje por eso.

En muchas circunstancias, es una herramienta inadecuada para crear sitios web; un lenguaje de programación de propósito general puede ser mejor. A menudo necesito tomar documentos XML muy grandes y presentarlos en la web; XSLT hace eso trivial. Los estudiantes que veo en este espacio tienden a procesar conjuntos de datos y presentarlos en la web. XSLT ciertamente no es la única herramienta aplicable en este espacio. Sin embargo, muchos de ellos están usando el DOM para hacer esto y XSLT es ciertamente menos doloroso.

Los estudiantes de banca que veo usan una caja de DataPower en general. Este es un dispositivo XML y se usa para ubicarse entre los diferentes dialectos XML que hablan los servicios. La transformación de un lenguaje XML a otro es casi trivial en XSLT y la cantidad de estudiantes que asisten a mis cursos sobre esto está aumentando.

El conjunto final de estudiantes que veo proviene de un fondo editorial (como yo). Estas personas tienden a tener inmensos documentos en XML (créanme, publicar como una industria se está adentrando mucho en XML, la publicación técnica ha estado allí durante años y la publicación comercial está llegando ahora). Estos documentos deben procesarse (aquí viene a la mente DocBook to ePub).

Alguien de arriba comentó que los scripts tienden a estar por debajo de 60 líneas o se vuelven difíciles de manejar. Si se vuelve difícil de manejar, lo más probable es que el programador no haya tenido realmente la idea: XSLT es una mentalidad muy diferente a la de muchos otros idiomas. Si no tienes la mentalidad no funcionará.

Ciertamente no es un lenguaje moribundo (la cantidad de trabajo que obtengo me dice eso). En este momento, está un poco 'atascado' hasta que Microsoft termine su implementación (muy tardía) de XSLT 2. Pero sigue ahí y parece que va fuerte desde mi punto de vista.

27
Nic Gibson

Utilizamos XSLT ampliamente para cosas como la documentación y para que algunas configuraciones de configuración complejas puedan ser reparadas por el usuario.

Para la documentación, usamos una gran cantidad de DocBook, que es un formato basado en XML. Esto nos permite almacenar y administrar nuestra documentación con todo nuestro código fuente, ya que los archivos son de texto sin formato. Con XSLT, podemos crear fácilmente nuestros propios formatos de documentación, lo que nos permite generar el contenido de forma genérica y hacer que el contenido sea más legible. Por ejemplo, cuando publicamos notas de la versión, podemos crear XML que se parece a algo como:

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

Y luego, al usar XSLT (que transforma lo anterior en DocBook) terminamos con las notas de la versión de Niza (normalmente PDF o HTML) donde las identificaciones de errores se vinculan automáticamente con nuestro rastreador de errores, los errores se agrupan por componente y el formato de todo es perfectamente consistente . Y el XML anterior se puede generar automáticamente consultando nuestro rastreador de errores para ver qué ha cambiado entre las versiones.

El otro lugar donde hemos encontrado que XSLT es útil es en realidad en nuestro producto principal. A veces, al interactuar con sistemas de terceros, necesitamos procesar los datos de alguna manera en una página HTML compleja. El análisis de HTML es feo, por lo que alimentamos los datos a través de algo como TagSoup (que genera eventos SAX XML adecuados, esencialmente nos permite manejar el HTML como si estuviera escrito correctamente XML) y luego podemos ejecutar algunos XSLT en su contra , para convertir los datos en un formato "estable estable" con el que podamos trabajar. Al separar esa transformación en un archivo XSLT, eso significa que si el formato HTML cambia, la aplicación en sí no necesita actualizarse, sino que el usuario final puede editar el archivo XSLT por sí mismo, o podemos enviar un correo electrónico ellos un archivo XSLT actualizado sin necesidad de actualizar todo el sistema.

Yo diría que para los proyectos web, hay mejores maneras de manejar el lado visual que XSLT hoy, pero como tecnología definitivamente hay usos para XSLT. No es el lenguaje más fácil de usar en el mundo, pero definitivamente no está muerto y, desde mi perspectiva, todavía tiene muchos buenos usos.

24
Adam Batkin

XSLT es un ejemplo de una programación declarativa lenguaje.

Otros ejemplos de lenguajes de programación declarativos incluyen expresiones regulares, Prolog y SQL. Todos estos son altamente expresivos y compactos, y generalmente están muy bien diseñados y son potentes para la tarea para la cual están diseñados.

Sin embargo, los desarrolladores de software generalmente odian tales lenguajes, porque son tan diferentes de los más tradicionales OO o lenguajes de procedimiento que son difíciles de aprender y depurar. Su naturaleza compacta generalmente hace que sea muy fácil hacer mucho daño sin darse cuenta.

Entonces, si bien XSLT es un mecanismo eficiente para combinar datos en presentación, falla en el departamento de facilidad de uso. Creo que es por eso que realmente no se ha puesto de moda.

19
Bill Karwin

Recuerdo todo el bombo alrededor de XSLT cuando el estándar fue lanzado recientemente. Toda la emoción de poder construir una IU HTML completa con una transformación "simple".

Afrontémoslo, es difícil de usar, casi imposible de depurar, a menudo insoportablemente lento. El resultado final es casi siempre peculiar y menos que ideal.

Antes me arrancaré la pierna que usar un XSLT mientras haya mejores maneras de hacer las cosas. Todavía tiene sus lugares, es bueno para tareas simples de transformación.

12
Crusty

He usado XSLT (y también XQuery) ampliamente para varias cosas: para generar código C++ como parte del proceso de compilación, para producir documentación a partir de comentarios de documentos, y dentro de una aplicación que tenía que trabajar con XML en general y XHTML en particular. . El generador de código en particular superaba las 10,000 líneas de código XSLT 2.0 distribuidas en aproximadamente una docena de archivos separados (hizo muchas cosas: encabezados para clientes, proxies/stubs remotos, envoltorios COM, envoltorios .NET, ORM - para nombrar unos pocos). Lo heredé de otro tipo que realmente no entendía bien el idioma y, por lo tanto, los bits más antiguos eran bastante desordenados. Sin embargo, las cosas más nuevas que escribimos se mantuvieron sanas y legibles, y no recuerdo ningún problema en particular para lograrlo. Ciertamente no fue más difícil que hacerlo para C++.

Hablando de versiones, tratar con XSLT 2.0 definitivamente te ayuda a mantenerte sano, pero 1.0 aún está bien para transformaciones más simples. En su lugar, es una herramienta extremadamente útil, y la productividad que obtiene de ciertas características específicas del dominio (lo más importante, el envío dinámico a través de la coincidencia de plantillas) es difícil de igualar. A pesar de la notoriedad percibida de la sintaxis basada en XML de XSLT, lo mismo en LINQ a XML (incluso en VB con literales XML) era generalmente varias veces más largo. Muy a menudo, sin embargo, en primer lugar se vuelve inmutable debido al uso innecesario de XML en algunos casos.

Para resumir: es una herramienta increíblemente útil para tener en la caja de herramientas de uno, pero es una herramienta muy especializada, por lo que es buena siempre que la use correctamente y para el propósito previsto. Realmente desearía que hubiera una implementación .NET nativa adecuada de XSLT 2.0.

10
Pavel Minaev

Utilizo XSLT (por falta de una mejor alternativa), pero no para presentación, solo para transformación:

  1. Escribo breves transformaciones XSLT para realizar ediciones masivas en nuestros archivos maven pom.xml.

  2. He escrito una serie de transformaciones para generar esquemas XML desde XMI (Diagrama UML). Funcionó por un tiempo, pero finalmente se volvió demasiado complejo y tuvimos que sacarlo detrás del establo.

  3. He usado transformaciones para refactorizar esquemas XML.

  4. He trabajado alrededor de algunas limitaciones en XSLT usándolo para generar un XSLT para hacer el trabajo real. (¿Alguna vez intentó escribir un XSLT que produce una salida utilizando espacios de nombres que no se conocen hasta el tiempo de ejecución?)

Sigo volviendo a él porque hace un mejor trabajo al aplicar el XML que está procesando que otros enfoques que he probado, que me han parecido innecesariamente deficientes o simplemente que no entienden el XML. XSLT es desagradable, pero me parece que usar Oxygen lo hace soportable.

Dicho esto, estoy investigando el uso de Clojure (un LISP) para realizar transformaciones de XML, pero aún no he llegado lo suficientemente lejos como para saber si ese enfoque me traerá beneficios.

9
bendin

Personalmente utilicé XSLT en un contexto totalmente diferente. El juego de computadora en el que estaba trabajando en ese momento utilizaba toneladas de páginas de interfaz de usuario definidas utilizando XML. Durante un refactor importante poco después de un lanzamiento, queríamos cambiar la estructura de estos documentos XML. Hicimos que el formato de entrada del juego siguiera una estructura mucho mejor y que tenga en cuenta el esquema.

XSLT parecía la elección perfecta para esta traducción del formato antiguo -> Nuevo formato. Dentro de dos semanas tuve una conversión de antigua a nueva para nuestras cientos de páginas. También pude usarlo para extraer mucha información sobre el diseño de nuestras páginas de UI. Creé listas de los componentes en los que estaba incrustado, de forma relativamente fácil, que luego usé XSLT para escribir en nuestras definiciones de esquema.

Además, proveniente de un fondo en C++, fue un lenguaje muy divertido e interesante de dominar.

Creo que como herramienta para traducir XML de un formato a otro es fantástico. Sin embargo, no es la única forma de definir un algoritmo que toma XML como entrada y genera Something . Si su algoritmo es lo suficientemente complejo, el hecho de que la entrada sea XML se vuelve irrelevante para su herramienta de elección, es decir, suya en C++/Python/lo que sea.

Específico a su ejemplo, me imagino que la mejor idea sería crear su propio XML-> XML convert que siga su lógica empresarial. A continuación, escriba un traductor XSLT que solo sepa sobre el formato y no haga nada inteligente. Eso podría ser un punto medio agradable, pero depende totalmente de lo que estés haciendo. Tener un traductor XSLT en la salida facilita la creación de formatos de salida alternativos: imprimible, para móviles, etc.

7
Tom Leys

Sí, lo uso mucho. Al usar diferentes archivos xslt, puedo usar la misma fuente XML para crear múltiples archivos HTML políglotas (X) (que presentan los mismos datos de diferentes maneras), una fuente RSS, una fuente Atom, un archivo descriptor RDFy fragmento de un mapa del sitio.

No es una panacea. Hay cosas que hace bien, y cosas que no hace bien, y como todos los demás aspectos de la programación, se trata de usar la herramienta adecuada para el trabajo correcto. Es una herramienta que vale la pena tener en su caja de herramientas, pero debería usarse solo cuando sea apropiado hacerlo.

6
Alohci

Definitivamente, recomendaría que se quede fuera. Especialmente si está utilizando Visual Studio que tiene herramientas integradas de edición, visualización y depuración para XSLT.

Sí, es un dolor mientras estás aprendiendo, pero la mayor parte del dolor tiene que ver con la familiaridad. El dolor disminuye a medida que aprendes el idioma.

W3schools tiene dos artículos que tienen un valor particular: http://www.w3schools.com/xpath/xpath_functions.asphttp://www.w3schools.com/xsl/xsl_functions.asp

4
Nat

Es difícil trabajar con XSLT, pero una vez que lo conquistes tendrás una comprensión muy completa del DOM y el esquema. Si también tiene XPath, entonces estará aprendiendo programación funcional y esto lo expondrá a nuevas técnicas y formas de resolver problemas. En algunos casos, la transformación sucesiva es más poderosa que las soluciones de procedimiento.

3
David Robbins

Solía ​​pensar que XSLT era una gran idea. Quiero decir que es una gran idea.

Donde falla es la ejecución.

El problema que descubrí con el tiempo fue que los lenguajes de programación en XML son solo una mala idea. Lo hace todo impenetrable. Específicamente creo que XSLT es muy difícil de aprender, codificar y entender. El XML en la parte superior de los aspectos funcionales hace que todo sea demasiado confuso. He tratado de aprenderlo aproximadamente 5 veces en mi carrera, y simplemente no se mantiene.

De acuerdo, podría "implementarlo". Creo que ese fue en parte el objetivo de su diseño, pero ese es el segundo fallo: todas las herramientas XSLT en el mercado son, simplemente ... ¡mierda!

3
Schneider

Utilicé XML, XSD y XSLT en un proyecto de integración entre sistemas de bases de datos muy similares en 2004. En algún momento tuve que aprender XSD y XSLT desde cero, pero no fue difícil. Lo bueno de estas herramientas fue que me permitió escribir código de C++ independiente de datos, confiando en XSD y XSLT para validar/verificar y luego transformar los documentos XML. Cambie el formato de los datos, cambie los documentos XSD y XSLT, no el código C++ que empleó las bibliotecas de Xerces.

Para el interés: el XSD principal era 150KB y el tamaño promedio del XSLT era <5KB IIRC.

El otro gran beneficio es que el XSD es un documento de especificación en el que se basa el XSLT. Los dos trabajan en armonía. Y las especificaciones son raras en el desarrollo de software en estos días.

Aunque no tuve demasiados problemas para aprender la naturaleza declarativa XSD y XSLT encontré que otros programadores de C/C++ tuvieron grandes problemas para ajustarse a la forma declarativa. Cuando vieron que era eso, ¡ah procesales murmuraron, ahora que lo entiendo! ¡Y procedieron a escribir el XSLT procesal! La cosa es que tienes que aprender XPath y entender los ejes de XML. Me recuerda a los antiguos programadores de C que se adaptan a emplear OO al escribir C++.

Utilicé estas herramientas porque me permitieron escribir una pequeña base de código C++ que estaba aislada de todas las modificaciones de la estructura de datos, excepto la más fundamental, y estas últimas fueron cambios en la estructura de la base de datos. Aunque prefiero C++ a cualquier otro idioma, usaré lo que considero útil para beneficiar la viabilidad a largo plazo de un proyecto de software.

3
Sam

Uso XSLT ampliamente, para un front-end estilo MVC personalizado. El modelo está "serializado" a xml (no a través de serialización xml), y luego se convierte a html a través de xslt. La ventaja sobre ASP.NET radica en la integración natural con XPath, y en los requisitos más rigurosos de buena formación (es mucho más fácil razonar acerca de la estructura del documento en xslt que en la mayoría de los otros idiomas).

Desafortunadamente, el lenguaje contiene varias limitaciones (por ejemplo, la capacidad de transformar la salida de otra transformación) lo que significa que ocasionalmente es frustrante trabajar con él.

Sin embargo, la separación de inquietudes fácilmente alcanzable y fuertemente impuesta que otorga no es algo que veo ahora como otra tecnología, por lo que para las transformaciones de documentos todavía es algo que recomiendo.

3
Eamon Nerbonne

He encontrado que es muy difícil trabajar con XSLT.

He tenido experiencia trabajando en un sistema similar al que usted describe. Mi compañía notó que los datos que regresábamos del "nivel medio" estaban en XML, y que las páginas se iban a representar en HTML que también podría ser XHTML, además de que habían oído que XSL era un estándar para transformar entre XML formatos Así que los "arquitectos" (con lo que me refiero a personas que piensan en pensamientos de diseño profundos pero aparentemente nunca codifican) decidieron que nuestra capa frontal se implementaría al escribir scripts XSLT que transformaron los datos en XHTML para su visualización.

La elección resultó ser desastrosa. Resulta que XSLT es un dolor para escribir. Y así, todas nuestras páginas fueron difíciles de escribir y mantener. Habría sido mucho mejor haber usado JSP (esto fue en Java) o algún enfoque similar que usara un tipo de marcado (ángulo entre paréntesis) para el formato de salida (el HTML) y otro tipo de marcado (como <% ... %>) para los metadatos. Lo más confuso de XSLT es que está escrito en XML, y se traduce de XML a XML ... es bastante difícil mantener los 3 documentos XML diferentes directamente en la mente.

Su situación es ligeramente diferente: en lugar de crear cada página en XSLT como lo hice yo, solo necesita escribir UN bit de código en XSLT (el código a convertir de plantillas a mostrar). Pero suena como si hubieras encontrado el mismo tipo de dificultad que yo. Diría que tratar de interpretar un simple DSL basado en XML (lenguaje específico del dominio) como lo está haciendo NO es uno de los puntos fuertes de XSLT. (Aunque PUEDE hacer el trabajo ... después de todo, ¡IS Turing se ha completado!)

Sin embargo, si lo que tenía era más simple: tiene datos en un formato XML y desea hacer modificaciones simples, no un DSL completo de descripción de página, sino algunas modificaciones simples y sencillas, entonces XSLT es una herramienta excelente para ese propósito. Su naturaleza declarativa (no procesal) es en realidad una ventaja para ese propósito.

- Michael Chermside

3
mcherm

Todo se reduce a lo que necesitas. Su principal fortaleza es la facilidad de mantenimiento de la transformada, y escribir su propio analizador generalmente lo borra. Dicho esto, a veces un sistema es pequeño y simple y realmente no necesita una solución "elegante". Siempre y cuando su constructor basado en código sea reemplazable sin tener que cambiar otro código, no es gran cosa.

En cuanto a la fealdad de XSL, sí, es fea. Sí, lleva un tiempo acostumbrarse. Pero una vez que lo dominas (no debería tomar mucho tiempo en la OMI), en realidad es una navegación suave. Las transformaciones compiladas se ejecutan con bastante rapidez en mi experiencia, y ciertamente puedes depurarlas.

2
SpongeJim

La especificación XSLT define XSLT como "un lenguaje para transformar documentos XML en otros documentos XML". Si está intentando hacer algo, pero el procesamiento de datos más básico dentro de XSLT probablemente haya mejores soluciones.

También vale la pena señalar que las capacidades de procesamiento de datos de XSLT se pueden ampliar en .NET utilizando funciones de extensión personalizadas:

2
Eric Schoonover

Sigo creyendo que XSLT puede ser útil, pero es un lenguaje feo y puede llevar a un desorden terrible e ilegible. En parte porque XML no es lo suficientemente legible para crear un "lenguaje" y en parte porque XSLT se encuentra en algún lugar entre ser declarativo y procesal. Dicho esto, y creo que se puede hacer una comparación con expresiones regulares, tiene sus usos cuando se trata de problemas simples bien definidos.

El uso del enfoque alternativo y el análisis de XML en el código puede ser igualmente desagradable y realmente desea emplear algún tipo de tecnología de enlace/clasificación XML (como JiBX en Java) que convertirá su XML directamente en un objeto.

2
Tom Martin

Mantengo un sistema de documentación online para mi empresa. Los escritores crean la documentación en SGML (un lenguaje similar a XML). El SGML luego se combina con XSLT y se transforma en HTML.

Esto nos permite realizar cambios fácilmente en el diseño de la documentación sin realizar ninguna codificación. Es solo una cuestión de cambiar el XSLT.

Esto funciona bien para nosotros. En nuestro caso, es un documento de solo lectura. El usuario no está interactuando con la documentación.

Además, al utilizar XSLT, está trabajando más cerca de su dominio de problema (HTML). Siempre lo considero una buena idea.

Por último, si su sistema actual FUNCIONA, déjelo solo. Nunca sugeriría destrozar su código existente. Si estuviera empezando desde cero, usaría XSLT, pero en su caso, usaría lo que tiene.

2
Mashed Potato

Si puede usar XSLT en un estilo declarativo (aunque no estoy totalmente de acuerdo en que sea un lenguaje declarativo), entonces creo que es útil y expresivo.

He escrito aplicaciones web que usan un OO lenguaje (C # en mi caso) para manejar la capa de procesamiento/datos, pero genera XML en lugar de HTML. Esto puede ser consumido directamente por los clientes como una API de datos, o renderizado como HTML por XSLTs. Debido a que C # generaba XML que era estructuralmente compatible con este uso, todo era muy suave y la lógica de presentación se mantuvo declarativa. Era más fácil de seguir y cambiar que enviar las etiquetas desde C #.

Sin embargo, a medida que necesita más lógica de procesamiento en el nivel XSLT, se vuelve complicada y detallada, incluso si "obtiene" el estilo funcional.

Por supuesto, estos días probablemente habría escrito esas aplicaciones web utilizando una interfaz REST, y creo que los "lenguajes" de datos como JSON están ganando terreno en áreas en las que XML tradicionalmente ha sido transformado por XSLT. Pero por ahora XSLT sigue siendo una tecnología importante y útil.

2
philsquared

En una empresa anterior hicimos mucho con XML y XSLT. Tanto XML como XSLT grandes.

Sí, hay una curva de aprendizaje, pero luego tienes una herramienta poderosa para manejar XML. E incluso puedes usar XSLT en XSLT (que a veces puede ser útil).

El rendimiento también es un problema (con un XML muy grande), pero puede abordarlo utilizando el XSLT inteligente y hacer un preprocesamiento con el XML (generado).

Cualquier persona con conocimiento de XSLT puede cambiar la apariencia del producto terminado porque no está compilado.

1
Toon Krijthe

He usado XSLT antes. El grupo de 6 archivos .xslt (refactorizados de uno grande) tenía aproximadamente 2750 líneas antes de que lo reescribiera en C #. El código C # es actualmente 4000 líneas que contienen mucha lógica; Ni siquiera quiero pensar en lo que habría tomado eso para escribir en XSLT.

El punto en el que me rendí es cuando me di cuenta de que no tener XPATH 2.0 estaba perjudicando significativamente mi progreso.

1
Sam Harwell

Para responder a sus tres preguntas:

  1. He usado XSLT una vez hace algunos años.
  2. Creo que XSLT podría ser la solución correcta en ciertas circunstancias. (Nunca digas nunca)
  3. Tiendo a estar de acuerdo con tu evaluación de que es principalmente útil para transformaciones "simples". Pero creo que mientras entiendas bien XSLT, hay un caso para usarlo para tareas más grandes, como publicar un sitio web como XML transformado en HTML.

Creo que la razón por la que a muchos desarrolladores no les gusta XSLT es porque no entienden el paradigma fundamentalmente diferente en el que se basa. Pero con el reciente interés en la programación funcional, podríamos ver a XSLT haciendo una reaparición ...

1
Dawie Strauss

He pasado mucho tiempo en XSLT y descubrí que si bien es una herramienta útil en algunas situaciones, definitivamente no es una solución para todos. Funciona muy bien para fines B2B cuando se utiliza para la conversión de datos para entrada/salida XML legible por máquina. No creo que estés en el camino equivocado en tu declaración de sus limitaciones. Una de las cosas que más me frustró fueron los matices en las implementaciones de XSLT.

Tal vez debería mirar algunos de los otros lenguajes de marcado disponibles. Creo que Jeff hizo un artículo sobre este mismo tema relacionado con el desbordamiento de pila.

¿Es HTML un lenguaje de marcado humano?

Echaría un vistazo a lo que escribió. Probablemente puedas encontrar un paquete de software que haga lo que quieres "fuera de la caja", o al menos muy cerca en lugar de escribir tus propias cosas desde cero.

1
Jason Jackson

Un lugar donde xslt realmente brilla es en la generación de informes. He encontrado que un proceso de 2 pasos, con el primer paso exportando los datos del informe como un archivo xml, y el segundo paso generando el informe visual del xml usando xslt. Esto permite los informes visuales de Niza mientras se mantienen los datos sin procesar como un mecanismo de validación, si es necesario.

1
Jack Ryan

Personalmente, me gusta XSLT, y es posible que desee darle a la sintaxis simplificada un aspecto (no hay plantillas explícitas, solo un archivo HTML antiguo normal con algunas etiquetas XSLT para escupir valores), pero simplemente no es t para todos.

Tal vez solo quieras ofrecer a tus autores una interfaz simple de Wiki o Markdown. También hay bibliotecas para eso, y si XSLT no está funcionando para ti, quizás XML tampoco esté funcionando para ellas.

1
brianary

Actualmente tengo la tarea de raspar los datos de un sitio público (sí, lo sé). Afortunadamente, se ajusta a xhtml, por lo que puedo usar xslt para recopilar los datos que necesito. La solución resultante es legible, limpia y fácil de cambiar si se presenta la necesidad. ¡Perfecto!

1
Goran

Creo que hiciste lo correcto. En mi experiencia, los desarrolladores de XSLT se encuentran entre los más difíciles de contratar, porque es un lenguaje que nunca se engancha ni con los desarrolladores web ni con los programadores informales.

Entonces, tiene que pagar al premium de "programador avanzado que conoce un idioma que está fuera de la corriente principal", pero por un lenguaje que probablemente no sea el favorito de ese programador.

0
Larry OBrien

He tenido una experiencia bastante buena con XSLT, pero no me estaba transformando en HTML. Puede ser que el combo XSLT-HTML sea muy difícil para hacer las cosas.

0
Rolf

En mi opinión sí.

Para un gran ejemplo de un uso realmente genial de XSLT, echa un vistazo a la armería de warcraft de Blizzard.

http://www.wowarmory.com

0
Vinh

XSLT 1.0 es uno de los códigos más portátiles, al menos en computadoras de escritorio y servidores. Porque tiene un tiempo de ejecución (ya menudo muchos) en la mayoría de esos sistemas:

  • Microsoft Windows tiene MSXML que se instala en el sistema base desde al menos Windows 2000. Se puede usar desde MSIE, desde la línea de comandos (usando WSH) o desde aplicaciones de Office
  • El Java Runtime Environment (JRE) tiene un tiempo de ejecución XSLT, y se instala un JRE en la mayoría de los escritorios
  • Casi todos los principales navegadores web tienen uno. La ópera es la excepción.
  • Existen implementaciones gratuitas que se instalan de forma predeterminada en los principales sistemas operativos basados ​​en GNU (libxslt, xsltproc)
  • No he comprobado MacOS X, pero tiene al menos una implementación en Safari

Esto hace que sea una buena opción para compilar algunas aplicaciones que requieren tanto portabilidad como poco peso/ninguna instalación.

Además, XSLT solo requiere un tiempo de ejecución (no se necesita compilador) y puede crear el código con cualquier editor de texto. Así que puedes crear programas fácilmente (bueno, una vez que domines el idioma) desde cualquier escritorio.

0
dolmen

Usé XSLT extensivamente ... durante un par de horas. Es genial para cosas como cambiar nombres de elementos o filtrar un documento de entrada (eliminando cosas que no necesitas).

Cualquier otra cosa se complica muy rápidamente. Esta complejidad heredada más la falta de la mayoría de las cosas que usa de cualquier otro lenguaje de programación (como las variables) y las formas fáciles de hacer ilegibles las expresiones XPath, realmente duelen.

Al final, XSLT tiene un esquema: a los programadores no les gusta por las limitaciones y todos los demás no pueden usarlo (por ejemplo, diseñadores web o cualquier otro tipo que no sea programador).

Si XSLT hubiera sido promovido como algún tipo de SQL para XML, las cosas serían un poco diferentes. Primero, la gente ni siquiera se hubiera molestado en mirarlo. Y a los que lo hicieron no les habría sorprendido el dolor.

0
Aaron Digulla

Creo que el concepto es sólido, tal vez la ejecución no sea tan "limpia" como podría ser.

Sin embargo, creo que debería tratarse como una herramienta, puede que no sea prudente utilizarla en todos los casos, sin embargo, nunca se debe ignorar una herramienta al resolver soluciones.

He visto XSLT muy bueno, y también muy mal uso de XSLT, y concluyo que parte de esto puede depender de la habilidad del desarrollador. Creo que es uno que requiere que el desarrollador piense en varios dominios al mismo tiempo.

¿Es el futuro? Tal vez no, tal vez hay mejores soluciones ..

No sé qué nueva tecnología va a aparecer, pero al menos es mejor aprenderla, aumentar el conjunto de herramientas de uno no puede ser malo, ¿no?

0
Darknight

Uso XSLT para corregir errores en archivos xml muy complejos. Entonces, en lugar de manejar los errores en el xml, uso xslt para corregirlos.

Esto es genial. Porque el lenguaje es muy poderoso y se ajusta al caso de uso xml. Para hacer las mismas cosas en un lenguaje de programación habitual, me llevaría mucho tiempo adaptar mi código cada vez que surgiera un nuevo sabor.

También es útil migrar las soluciones de Visual Studio sin dejar que Microsoft decida qué cosas cambiar. Así que convierta una solución. Compruebe lo que cambió. Revertir las cosas que no desea cambiar y ejecutar el script xslt haciendo el trabajo en todos los archivos.

Así que nunca lo usé para hacer presentaciones web o algo así, pero me ayuda en mis problemas basados ​​en XML. Y para resolver estos problemas es realmente muy poderoso y realmente vale la pena echarle un vistazo.

0
Totonga

XSLT no es la transformación final de todo el todo de XML. Sin embargo, es muy difícil juzgar de acuerdo con la información proporcionada si hubiera sido la mejor solución para su problema o si existen otros enfoques más eficientes y sostenibles. Usted dice que los autores podrían ingresar su contenido en un formato simplificado, ¿qué formato? ¿Cajas de texto? ¿A qué tipo de html lo convertiste? Para juzgar si XSLT es la herramienta adecuada para el trabajo, sería útil conocer las características de esta transformación con más detalle.

0
Shmoggle

Yo también he hecho incursiones en el mundo de XSLT y me pareció un poco incómodo en algunos lugares. Creo que mi principal problema fue la dificultad de convertir XML de "datos puros" en una página HTML completa. En retrospectiva, quizás usar XSLT para generar un fragmento de página que podría componerse junto con otros fragmentos usando Server Side Scripting (por ejemplo, SSI) habría resuelto muchos de mis problemas.

Uno de los posibles errores fue tratar de construir un diseño de página común para rodear mis datos mediante la importación de XHTML u otros datos XML utilizando la función document ().

El otro error fue tratar de hacer cosas programáticas como crear una plantilla general para generar tablas en datos XML con lógica que hizo cosas como usar diferentes colores de fila de fondo para filas con ciertos valores y permitirle especificar algunas columnas para filtrar.

Por no hablar de intentar construir una lista de valores de cadena a partir de datos XML que solo parecían solucionarse mediante llamadas de plantilla recursivas.

¿Qué gané? Bueno, la fuente de la página es datos XML justo allí y disponibles para el espectador. Los datos y la presentación están perfectamente separados.

¿Lo haría de nuevo? Probablemente no, a menos que realmente quisiera una separación de datos/presentación en una página static . De lo contrario, probablemente escribiría una aplicación Rails o Java EE que podría generar una vista XML o una vista HTML utilizando plantillas: todos los beneficios, pero con un lenguaje de programación mucho más natural (para mí) a mi alcance.

0
Mike Tunnicliffe

Disfruto usando XSLT solo para cambiar la estructura de árbol de los documentos XML. Me resulta incómodo hacer cualquier cosa relacionada con el procesamiento de texto y relegarlo a un script personalizado que puedo ejecutar antes o después de aplicar un XSLT a un documento XML.

XSLT 2.0 incluía muchas más funciones de cadena, pero creo que no es una buena opción para el lenguaje, y no hay muchas implementaciones de XSLT 2.0.

0
Ben

En términos de productividad total, sería mejor utilizar una de las bibliotecas de estilo jQuery: pyQuery, phpQuery, etc. La mayoría de las bibliotecas XML apestan y XSLT es esencialmente solo otra biblioteca XML empaquetada como un lenguaje completo pero sin un conjunto decente de herramientas . jQuery hace que sea increíblemente fácil recorrer y manipular los datos de estilo XML en el idioma de su elección.

0
Jimmy

Hablando de interoperabilidad, XML es un estándar para el almacenamiento de información. Una gran cantidad de herramientas producen resultados en XML, y qué mejor (o más fácil) manera de presentarlos que incrustar un navegador en su aplicación, formatear el XML y colocarlo en el navegador.

0
Midhat

Necesito trabajar con XSLT aquí porque alguien pensó que es una buena idea resolver un problema dado: Necesitamos extraer algunos datos de múltiples archivos XML y unirlos a diferentes formatos de salida para diferentes herramientas que hacen un mayor procesamiento.

Creo que XSLT es una idea muy agradable porque es un estándar en el que puedes confiar. Esto es cierto para tareas de formateo simples en las que no necesita mucha lógica de programación o algoritmos en su código.

Pero: Es una curva de aprendizaje bastante importante, ya que no es no procedural. Si te acostumbras a la programación de procedimientos (C, Java, Perl, PHP, etc.), te perderás muchas estructuras comunes o te preguntarás por cosas que solo tienen suerte y, en ocasiones, no son fáciles de leer para un ojo inexperto. Por ejemplo, escribir código "resuseable": Si necesita hacer algo una y otra vez en diferentes lugares, en la programación de procedimientos, definiría una función para hacerlo. También puede lograr esas cosas en XSLT, pero es necesario escribir más código y no es tan legible/comprensible como lo sería una función normal.

El principal problema que tengo es que muchas personas que proceden de un fondo de procedimientos trabajaron en los archivos XSLT en este momento, y casi todos simplemente "emularon" lo que necesitaba.

Entonces, como conclusión, ya no veo a XSLT como la solución "definitiva". De hecho, es difícil leer o escribir algunas construcciones en XSLT. En la mayoría de los casos, tendrá que pensar en la aplicación: para una transformación simple probablemente volveré a usar XSLT. Pero para software más complejo no lo volveré a usar.

0
Murphy