¿Por qué elegir una transformación XSL?

Question

Para un proyecto actual, se debe tomar la decisión de usar XML y una transformación XSL para producir HTML o usar directamente plantillas HTML.

Me interesarían los argumentos a favor o en contra del enfoque XSL. Entiendo que en los casos en que debe admitir muchos diseños diferentes, una solución XSL tiene muchas ventajas, pero ¿por qué elegirla en aquellos casos en los que solo debe admitir un diseño objetivo?

Edit: Estamos hablando de Java aquí.

Answer 1

Seguir el camino de XSL protegerá su aplicación en el futuro. Es decir, si en el futuro decide agregar más plantillas con diferentes diseños, podrá capitalizar esas ventajas. En mi proyecto actual ahorramos el XML utilizado (en un XMLType o CLOB) y permitimos que otras aplicaciones accedan a los datos y plantillas XSL para generar documentos a través de un servicio web. Esto fue una reflexión sobre el diseño original que fue súper fácil de implementar debido a nuestra decisión de usar XML/XSL.

Answer 2

En contraste con HTML, hay muchas herramientas XML disponibles si necesita analizar y procesar las plantillas de cualquier manera. Por lo tanto, debe elegir XML para obtener los beneficios de usar herramientas y bibliotecas para XML.

Sin embargo, dicho esto, puede ser que XHTML se adapte a sus necesidades, ya que esto le da soporte completo de las herramientas y bibliotecas XML mientras sigue siendo HTML normal que es procesado correctamente por los navegadores web modernos. Si necesita hacer un post-procesamiento de los mismos más adelante, aún puede aplicar XSLT a los datos XHTML.

Answer 3

No utilice XML/XSLT para front-ends web. Estuve en proyectos como este y es horrible. A menudo, primero debe producir el XML a partir de objetos o algo similar, lo que no tiene sentido. Un segundo punto es que hay tantos buenos editores de HTML por ahí gratis, pero no he encontrado ninguno para XSLT. Entonces, editar XSLT complejo no es divertido. Recomendaría ir con plantillas HTML y un motor de plantillas común.

Answer 4

XSLT tiene la ventaja de poder producir también en otros tipos de documento (es decir, pdf) y la salida en pdf es muy probable hoy en día. XML/XSLT también separa los datos de la vista.

Answer 5

Veo cómo el enfoque XSL puede ser útil si sus datos ya son XML.
Pero generalmente no lo es. Está en algún lugar de una base de datos, necesita generarse in situ o proviene de algún servicio.
Crear XML desde esta fuente para luego poder crear HTML a partir de ese XML es inútil en mi opinión. Me quedaría con las plantillas de (X) Html.

Answer 6

Dependiendo de la aplicación, que tiene una capa XML que se transforma entonces a XHTML a través de XSLT también meens, que se puede escribir servicios web fácil de la capa XML - permitiendo a sus clientes consumen sus sitios de datos ...

Tener el XML enviado al navegador con un enlace de transformación (se olvidó la sintaxis exacta ...) también reduce el ancho de banda necesario, ya que el archivo XSLT se mantendrá igual y solo tendrá que pasar el XML sin procesar desde el que se creó. como usar una hoja de estilo CSS externa en lugar de agregar los atributos de estilo a su marcado;)

Answer 7

XSLT es un lenguaje de programación funcional y puede usarlo para crear interfaces tan ricas como cualquier sistema de plantillas . Sin embargo, no deberías hacerlo; tú y tu equipo se volverán locos.

Ambas opciones presentan la oportunidad de transformar objetos en un formulario de presentación de una manera lógica.XSLT es más adecuado para crear más XML, lo que podría llevarlo a creer que es un candidato perfecto para crear XHTML. Sin embargo, la creación de XHTML no debe ser el objetivo principal. La creación de una experiencia de usuario es. No se preocupe por el medio .

Dos inconvenientes importantes para XSLT se refieren a la sintaxis: sus plantillas, las plantillas que incluyen y las plantillas que incluyen esas plantillas serán gigantescas y detalladas. En segundo lugar, tendrá que realizar una gran cantidad de programación funcional, y los ingenieros menos experimentados pueden sentirse confundidos y aterrados cuando se encuentran con una plantilla recursiva con un parámetro de función acumulada en lugar de un bucle simple.

Si le atrae la belleza de la transformación de las entidades XML válidas y construidas lógicamente, considere en su lugar un sistema de plantillas tipo seguro que transforma los beans en su lugar. Consulte Google XML Pages, y cree plantillas organizadas lógicamente y seguras para los tipos, que los futuros ingenieros podrán recoger y ampliar fácilmente.

Answer 8

Cuando hicimos XSLT en el pasado, fue para permitir la capacidad de extender nuestro producto. La salida permaneció igual, solo la capa de presentación tuvo que cambiar. Esto nos permitió mucha flexibilidad cuando teníamos clientes que querían "personalizar" su UI, ya que todo lo que teníamos que hacer era reemplazar el archivo XSLT. Si prevé tener que hacer muchos de esos tipos de cambios, XSLT podría ser su respuesta.

Sin embargo, como se indicó anteriormente, la sintaxis XSLT y la mentalidad de programación funcional pueden dificultar la producción efectiva de plantillas. Descubrimos que nos gustaba seguir los trucos que aprendimos y que cuando teníamos solicitudes de clientes que quedaban fuera de lo que ya sabíamos, nadie quería ofrecerse voluntario para el boleto. Por lo general, alguien eventualmente descubría cómo hacer la tarea y nuestra "bolsa de trucos" se hacía más grande, pero a menudo era muy engorroso descubrir cosas nuevas.

Si no prevé cambiar la interfaz de usuario nunca, o al menos no mucho, XSLT puede no valer la pena el esfuerzo extra.

Answer 9

Usamos XSLT para generar html en nuestro sistema de gestión de contenido y funciona muy bien.

Algunos consejos: no intente generar toda la página a la vez a partir de un gran XML peludo, se volverá loco. Utilice la plantilla HTML (texto sin formato/archivo HTML con estilos, decoraciones y marcado básico) con marcadores incrustados (como, <! - MENÚ-- >, <! - CONTENIDO-- >), y reemplace los marcadores con xslt-transformation de datos apropiados.

Habiendo dicho eso, dudo que realmente necesite xslt si solo va a tener un diseño, para siempre.

Answer 10

Creo que necesita examinar cuál será la fuente de sus datos. Como lo menciona boris anteriormente, si estás sacando de una base de datos, primero tendrás que transformarte en XML y luego aplicar tus transformaciones. Si la fuente de datos es RSS o similar, entonces XSLT es una elección natural.

XPATH y XSLT tienen una gran curva de aprendizaje y la programación funcional puede ser desalentadora para abrazar. En tiempo crunch esto puede no ser la elección correcta.

Para el trabajo de front-end JSON tiene una carga útil más ligera, y es fácilmente compatible con jQuery y otras bibliotecas de Javascript. Es posible que desee considerar JSON como el protocolo de datos, ya que la biblioteca jQuery es mucho más accesible para los desarrolladores y el tiempo de productividad con el marco es mucho menor que con XSLT, JavaScript incrustado en las etiquetas, sintaxis horrible y todos los demás detalles que vienen con XML/XPATH/XSLT en la parte delantera.

Answer 11

he utilizado XML & XSLT en un proyecto anterior, los sitios web financieros, y ha funcionado bien para nosotros, pero:

1. Tuvimos varios clientes, que variaban el número de salidas que teníamos. Podríamos reemplazar la hoja de estilo XSLT y esto hizo cambios en el sitio más fácil de administrar para los desarrolladores
2. Teníamos un editor web especializado en el equipo. Les dimos el ejemplo XML & Podrían editar las hojas de estilo directamente
3. Si alguna vez hubo cambios en la redacción que tenían que ir al sitio web ayer (era un banco, esto sucedió sorprendentemente a menudo), podríamos simplemente implementar el nuevo XSLT sin volver a implementar todo el sitio.
4. Se necesitan múltiples formatos de salida diferentes. Utilizamos FOP para la transformación a PDF, que se basa en el mismo tipo de tecnología, por lo que no era demasiado difícil para nosotros entender :-)

La principal razón que veo para el uso de XSLT es si usted tiene múltiples todos los sitios están basados ​​en el mismo XML, pero requieren una salida de HTML diferente.

Answer 12

Hazlo simple. Ese es un principio que uno puede apreciar cada vez más.

Velocity o Freemarker son increíblemente flexibles y versátiles. Su base de código será clara, fácilmente comprensible, y se ejecutará mucho (mucho) más rápido que las monstruosidades X.

Answer 13

Creé una interfaz de usuario basada en XML/XSLT para un producto empresarial hace unos 5 años. Todavía estamos a usarlo, y ahora podemos mirar hacia atrás en mi experiencia y ver muchos pros y contras:

Pros:

• XSL es un lenguaje declarativo potente, útil & divertido para los desarrolladores experimentados, y las transformaciones pueden hacer cosas bastante sorprendentes en unas pocas líneas de código
• XSL está diseñado para usar con XML, por lo tanto, si sus datos ya son XML, tiene mucho sentido
• Separación de preocupaciones (representación frente a datos) mejor que muchos lenguajes de plantilla
• La representación basada en XSL se puede "subclasificar" fácilmente. Con esto quiero decir: supongamos que tiene la clase de datos A con la plantilla asociada A.xslt. Para la clase B derivada de A, puede crear fácilmente B.xslt con solo pequeñas diferencias e incluir A.xslt para comportamientos heredados. Esto hace que sea menos susceptible de romperse debido a cambios en A.xslt.
• El punto anterior también le da la posibilidad de hacer anulaciones. Para la clase A con el A.xslt asociado, podemos cambiar fácilmente la plantilla asociada a A-custom.xslt, que es unos pocos cambios pequeños más la herencia de A.xslt. Podemos hacerlo sobre la marcha en el campo y una vez más, el beneficio es que A-custom.xslt es solo unas pocas líneas, no una copia modificada del original A.xslt. La huella pequeña significa que es más probable que funcione con múltiples versiones de A.xslt.
• En .NET 2.0, XSLT se compila y se vuelve muy rápido. Puede haber tecnología similar para Java. (La mayoría de los lenguajes de plantilla también lo hacen ahora).
• En .NET, es posible crear un "Object XPath Navigator", que le permite transformar sus objetos de datos sin tener que convertirlos a un objeto XML.Una vez más puede haber tecnología similar en Java
• XSLT es inteligente acerca de HTML & asas escapan, problemas de espacio en blanco, etc., así

Contras:

• XSL es un lenguaje declarativo de gran alcance, confundiendo a programadores más nuevos, y pocas personas conocen bien XSLT
• XSL es detallado. XML también es a menudo detallado.
• Las transformaciones XSL son probablemente más lentas que las plantillas "nativas". Incluso cuando se compila todavía hay más sobrecarga de estado para XSL que la mayoría de los lenguajes de plantilla
• Es difícil pasar parámetros a XSL, debe enviarlos en línea con sus datos (lo que le obliga a crear XML adicional) o mediante métodos específicos del sistema (que también puede implicar la construcción de datos XML)
• Si no tiene un ObjectXPathNavigator o equivalente, incurrirá en una sobrecarga significativa al convertir sus objetos de datos en XML para la transformación
• Dependiendo de las capacidades de su transformador, también puede incurrir en gastos generales de almacenamiento en búfer a medida que se transforma en un búfer de cadena y luego enviar esa cadena al dispositivo de salida
• Cuanto más avanzado sea el uso de XSLT, menor será la probabilidad y es que sus herramientas lo apoyarán (específicamente cuando empiece a usar incluye o maneras más rápidas de pasar datos XML)

Intentaré actualizar cuando haya más problemas. Creo que mirando hacia atrás ahora, mi veredicto sería seguir con un lenguaje de plantilla común. Lo que alguna vez fueron grandes problemas cuando seleccioné XML/XSLT ahora se han abordado mediante revisiones más recientes y más maduras de los principales motores de plantillas. Todavía nos beneficiamos enormemente de la capacidad de heredar archivos .xslt, que es algo que la mayoría de los motores de plantillas no hacen bien. Pero al final, el valor de tener muchos desarrolladores proporcionando ejemplos es mucho mayor (compare las respuestas de ASP.NET frente a las respuestas de XSLT en StackOverflow, por ejemplo).

Espero que ayude!

Answer 14

XML + XSLT son geniales. Tiene la capacidad de generar muchos tipos de formatos de destino en el futuro. Pero no estoy al tanto de HTML incorporado en el XML. Firefox XSLT no es compatible con "disable-output-escaping". Ver Bugzilla.

Answer 15

He hecho un desarrollo significativo usando XSLT y ha sido tremendamente exitoso y una falla completa en dos sitios diferentes.

Algunas reflexiones antes de una conclusión:

• No creo que nadie discuta que XSLT es mucho más poderoso que un motor de plantillas de análisis, es un lenguaje funcional.

• Aunque no es tan ampliamente adoptado como la mayoría de los lenguajes de procedimiento, todavía es un lenguaje real que se utiliza para proyectos reales, las personas pueden ser contratadas con conocimiento de XSLT y es una habilidad transferible para su personal actual.

• XSLT también ha existido desde hace un tiempo, las implementaciones son maduras, estoy seguro de que este es el caso de los motores de plantillas de larga ejecución (como Velocity) pero los motores más nuevos pueden ser menos robustos.

• Cualquiera que sea el lenguaje de plantilla que elija, es poco probable que esté tan bien documentado como XSLT. Consulte cualquiera de las series de referencia del programador Michael Kay para ver un ejemplo sobre cómo hacer un gran libro de referencia.

• El soporte de herramientas es generalmente muy bueno ... si tiene un presupuesto. XMLSpy y Stylus Studio me han sido muy útiles en el pasado.

• XSLT no solo es difícil sino, lo que es más importante, diferente. La mayoría de las personas no son graduados en Informática formados formalmente en programación funcional. La mayoría de los programadores escribirán XSLT en un estilo de procedimiento que no aprovechará ningún poder del lenguaje y le dará un dolor de cabeza de mantenimiento.

• Las transformaciones XSLT pueden ser lentas y pueden requerir mucha memoria. Puede tener problemas si tiene una hoja de estilo con una gran entrada de XML.

Me encanta XSLT, pero si debe utilizar o no se reduce a unos pocos puntos:

¿Estás comprometido a XSLT? ¿Tienes una gran experiencia interna en XSLT? ¿Estás preparado para obtener algo?

¿Están sus datos en XML? ¿Tiene sentido en XML? ¿Tiene alguien interno que ama sus datos lo suficiente como para asegurarse de que esté bien estructurado y siempre haya un esquema apropiado?

A menos que la respuesta a esas preguntas sea afirmativa y tenga datos complejos que requieran un proceso de representación complejo, no consideraría usar XSLT ... especialmente si no hay experiencia en el equipo. Bad XSLT es mucho, mucho, mucho peor que una mala plantilla.

Sin embargo, puede procesar datos complejos de forma sostenible, lo que sería imposible con muchos de los motores de plantillas actuales.

Answer 16

http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of_satan/