xml - example - xslt tutorial
¿Por qué XSLT nunca ha visto la popularidad de muchos otros idiomas que surgieron durante el auge de internet? (15)
El uso de XSLT (XML Stylesheet Language Transform) nunca ha tenido la misma popularidad que muchos de los otros idiomas que surgieron durante el auge de internet. Mientras está en uso, y en algunos casos por grandes empresas exitosas (es decir, Blizzard Entertainment), nunca pareció llegar a la corriente principal. ¿Por qué crees que es esto?
Bueno ... Tal vez porque es un dolor escribir xslts ... Tuve que escribir algunos xslts hace unos meses y soñaba con soportes puntiagudos ...
<Really>
<No>
<fun/>
</No>
</Really>
(Lo sé, que esto no es xslt)
Creo que todo se reduce a la sintaxis XML que es posiblemente buena para describir datos, pero no es una gran sintaxis para lo que esencialmente es un lenguaje de programación (XSLT).
Creo que trató de cubrir demasiados casos de uso convirtiéndose así en un lenguaje completo de Turing (o al menos eso escuché). Si intenta realizar una transformación no trivial, termina escribiendo bucles complejos, condiciones ... en un lenguaje feo y detallado, que se realiza mejor con una GPL.
En mi opinión, esta complejidad dificulta la escritura de una implementación correcta de XSLT y limita las opciones disponibles, por lo tanto, el uso generalizado entre los hackers vocales que a menudo les gusta jugar con código pequeño y eficiente, no con código empresarial.
En general, los tiempos en los que se requerirá que los datos XML se transformen en una forma diferente de datos XML, pero que no le hagan ningún otro procesamiento, serán muy limitados. Por lo general, XML se utiliza como un intermediario entre dos sistemas separados, uno de los cuales generalmente está hecho a medida para procesar el resultado del otro. Como tal, es más simple escribir uno de los sistemas para procesar la salida XML del otro sin el paso adicional de tener que realizar algún tipo de transformación.
Porque es más fácil escribir y mantener código que usa Java, C #, JavaScript, etc. para deserializar una secuencia XML, transformarla y exportar la salida deseada, y XSLT no ofrece una ventaja de rendimiento sustancial.
XSLT hace que las cosas sean fáciles, pero hace que otras cosas sean muy, muy difíciles.
Porque la mayoría de las implementaciones XSLT tienen una gran huella de memoria (supongo que eso se debe al diseño del lenguaje), porque las personas tienden a abusar de XSLT para todo tipo de cosas para las que no era especialmente adecuado y la naturaleza puramente declarativa de XSL lo que hace que ciertos tipos de transformaciones sean bastante difíciles.
XSL es convencional y ampliamente adoptado. ¿A qué otros idiomas se refiere? XSL no es un lenguaje de programación, solo un lenguaje de transformación , por lo que tiene un alcance bastante limitado.
XSLT es muy poderoso, pero requiere una forma diferente de pensar sobre el problema. También hizo la vida difícil para sí misma al no proporcionar una funcionalidad de datos útil en las primeras versiones. Tomemos por ejemplo un método de estilo ToUpper (), por lo general lo implementamos con algo como:
<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>
<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>
¡No es la forma más fácil de codificación!
XSLT usa programación funcional, algo a lo que la mayoría de los programadores no están acostumbrados (de ahí que algunas personas lo consideren no intuitivo, supongo).
xslt es ideal para xml a xml, cuando tiene datos que ya se han escapado y una definición clara de entradas y salidas. Usarlo para cosas como xml2html me parece un dolor de cabeza, y con casi cualquier lenguaje dinámico y CSS, la salida es mucho más fácil de implementar con estilo.
Es genial para xml, pero no es genial para la codificación típica. Carece de conceptos básicos típicos (es decir, variables mutables) y hace que lo que debería ser simple sea bastante complejo (o imposible). La mayoría de sus problemas provienen del hecho de que xml es un excelente lenguaje de representación de datos pero no un gran lenguaje de programación. Una vez dicho esto, lo uso a diario y lo recomendaría donde tenga sentido. En conjunción con espacios de nombres externos, puede hacerse más útil (llamadas a Java, etc.). Al final, es otro idioma para aprender, y muchos codificadores prefieren quedarse con algo a lo que están acostumbrados o se parece a algo a lo que están acostumbrados.
Como se dijo anteriormente XSLT (como "las partes buenas" de JavaScript) es un lenguaje de programación funcional. La mayoría de los programadores tradicionales odian esta apatridia. También muchos programadores tradicionales odian los corchetes angulares.
Pero, lo más importante, el uso correcto de XSLT resuelve tanto la generación de GUI declarativa como el problema de vinculación de datos para el servidor web de una manera independiente de la plataforma. Vendedores como Microsoft no están motivados para celebrar este poder "inconveniente".
Sin embargo, argumentaré que Microsoft tiene el mejor soporte XSLT para el IDE (Visual Studio) en el mundo.
En mi opinión, una de las cosas más molestas en el estándar XSLT (estoy hablando de XSLT 1.0 porque esa es la única versión que he usado) es que carecía de soporte para las transformaciones de cadena y algunas manipulaciones básicas de las funciones de fecha y hora.
Una cosa que nunca podría entender es por qué una función como translate () se diseñó e implementó en xpath cuando otras funciones más útiles como replace , to_lower , to_upper, o - let s crazy - las expresiones regulares no lo eran.
Algunos de estos problemas fueron abordados, supongo, con eXSLT (xslt extendido?) Para analizadores que no sean MSXML de Microsoft. Digo, supongo, porque en realidad nunca lo utilicé, ya que se declaró incompatible con MSXML.
No entiendo por qué XSLT 1.0 se diseñó con este principio de que la manipulación de ''texto'' no estaba dentro del alcance del lenguaje cuando es obvio que siempre que está convirtiendo archivos no puede evitar esos problemas de conversión de cadenas (por ejemplo: transformar una fecha rellena de forma irregular en formato francés a formato americano, 31/1/2008 a 2008-01-31) huh ...
Estos problemas de manipulación de texto generalmente eran muy básicos y se aplicaban fácilmente en MSXML al permitir que XSL se extendiera con funciones de JScript: se podía llamar a una función de JScript para realizar algún procesamiento como llamaría cualquier plantilla XSL, pero siempre encontré esa solución poco elegante y terminé creando mis propias bibliotecas de plantillas XSL. Primero porque el modo JScript rompió su portabilidad XSL, y porque lo obligó a mezclar su lógica de programación: algunos bits en expresión XPath / XSLT pura y otros bits en DOM / notación de objetos con JScript.
No tener variables actualizables es otra limitación que es muy confusa para los recién llegados, algunas personas simplemente no superan esto y siguen luchando con eso. En algunos casos simples, puede tener soluciones alternativas con una combinación de plantillas paremétricas y llamadas recursivas (por ejemplo, para implementar un contador creciente o de declasing) pero seamos sinceros, la recursión no es tan natural.
Creo que escuché todas esas limitaciones en la especificación XSLT 2.0, lamentablemente MS decidió no implementarlo y promocionar XQuery. Eso es triste, ¿por qué no implementar ambos? Creo que XSLT todavía tendría una buena oportunidad de volverse tan popular como se convirtió CSS para HTML. Cuando lo piensas, la parte más difícil de aprender XSLT es XPath, el resto no es tan difícil como entender el comportamiento en cascada en CSS, y CSS se ha vuelto tan popular ...
Entonces, en mi opinión, es la falta de todas esas pequeñas cosas mencionadas aquí y el tiempo que tomó abordarlas en XSLT 2.0 (sin que ni siquiera MS lo apoye de todos modos) que ha llevado a esta situación de impopularidad. Cómo me gustaría que MS decidiera implementarlo después de todo ...
Un problema es que XSLT parece complicado. Cualquier desarrollador debería ser capaz de recoger los constructos del lenguaje ya que hay análogos en la mayoría de los otros idiomas. El problema es que las construcciones y los datos se ven exactamente iguales, lo que hace que sea difícil distinguir entre los dos, lo que hace que XSLT sea más difícil de leer que otros languges.
Un segundo problema es que los usos son más limitados que otros idiomas. XSLT es excelente en lo que hace; haciendo transformaciones complicadas o radicales en XML. Pero no se aplica a una amplia gama de problemas como otros lenguajes, por lo que no se usa tanto.
En tercer lugar, muchos lenguajes de programación tienen sus propias bibliotecas para transformar XML. Gran parte del tiempo cuando se trabaja con XML, solo se necesitan pequeños cambios o búsquedas. El XML probablemente también esté siendo generado o consumido por un programa que el desarrollador ya está escribiendo en otro idioma. Estos factores significan que usar las utilidades integradas de un idioma es simplemente más conveniente.
Otro problema al que contribuyen todos estos problemas es la inercia. Es decir, las personas no lo saben, no ven que tienen mucha necesidad de él, por lo que lo evitan como una solución si hay otra opción.
Con lo que terminas es un lenguaje que es la última opción de muchos desarrolladores al crear soluciones. Es probable que incluso se evite XSLT cuando, como resultado, sería la mejor herramienta para el trabajo.
Me pareció genial para la ''arquitectura de servicios web compuestos''. Algunas veces, el número de servicios web funciona en conjunto para obtener el resultado final. Cuando esos servicios web necesitan comunicarse entre ellos a través de XML, XSLT puede transformar el mensaje xml de una forma a otra.