Produciendo una nueva línea en XSLT

Quiero producir una nueva línea para salida de texto en XSLT. ¿Algunas ideas?

El siguiente código XSL producirá un carácter de nueva línea (avance de línea):


 

Para un retorno de carro , use:

 
 

Mi método favorito para hacer esto se parece a algo así como:

      ...  

Luego, cada vez que quiera generar una nueva línea (quizás en csv), puede generar algo como:

  

He utilizado esta técnica al generar SQL desde la entrada xml. De hecho, tiendo a crear variables para comas, comillas y nuevas líneas.

Incluya el atributo Method = “text” en la etiqueta xsl: output e incluya nuevas líneas en su contenido literal en el XSL en los puntos apropiados. Si prefiere mantener el código fuente de su XSL ordenado, use la entidad donde quieres una nueva linea

Puede usar:

mira el ejemplo

   =  
  

si escribe esto en un archivo, por ejemplo

    

esta variable producirá un nuevo infile de línea como:

 commons-dbcp_commons-dbcp = 1.2.2 junit_junit = 4.4 org.easymock_easymock = 2.4 

DOCTYPE directiva DOCTYPE que ves aquí:

 < ?xml version="1.0" encoding="UTF-8"?> < !DOCTYPE xsl:stylesheet [  ]>  

Esto me permite usar &nl; en lugar de para producir una nueva línea en la salida. Al igual que otras soluciones, esto normalmente se ubica dentro de una etiqueta .

En mi humilde opinión, no se necesita más información que la de @Florjon. Quizás algunos pequeños detalles se dejen de entender por qué a veces no nos funciona.

Antes que nada, el (hex) o (dec) dentro de un siempre funcionará, pero es posible que no lo veas.

  1. No hay línea nueva en un marcado HTML. Usar un simple
    te irá bien. De lo contrario, verá un espacio en blanco. Ver la fuente desde el navegador le dirá lo que realmente sucedió. Sin embargo, hay casos en los que espera este comportamiento, especialmente si el consumidor no es directamente un navegador. Por ejemplo, desea crear una página HTML y ver su estructura formateada muy bien con líneas vacías e identificadores antes de servirla en el navegador.
  2. Recuerde dónde necesita usar disable-output-escaping y dónde no. Tome el siguiente ejemplo donde tuve que crear un xml de otro y declarar su DTD desde una hoja de estilo.

La primera versión escapa de los caracteres (por defecto para xsl: texto)

    <!DOCTYPE Subscriptions SYSTEM "Subscriptions.dtd">


           

y aqui esta el resultado:

 < ?xml version="1.0" encoding="utf-8"?> <!DOCTYPE Subscriptions SYSTEM "Subscriptions.dtd"> 
   

Ok, hace lo que esperamos, se hace el escape para que los caracteres que utilizamos se muestren correctamente. El formato de parte XML dentro del nodo raíz es manejado por ident="yes" . Pero con una mirada más cercana , vemos que el carácter de nueva línea no se escapó y se tradujo tal cual, ¡realizando un doble salto de línea! No tengo una explicación sobre esto, será bueno saberlo. ¿Nadie?

La segunda versión no escapa a los personajes, por lo que están produciendo para lo que están destinados. El cambio realizado fue:

 <!DOCTYPE Subscriptions SYSTEM "Subscriptions.dtd">


 

y aqui esta el resultado:

 < ?xml version="1.0" encoding="utf-8"?> < !DOCTYPE Subscriptions SYSTEM "Subscriptions.dtd">    

y eso estará bien. Tanto cr como lf son renderizados apropiadamente.

  1. No olvide que estamos hablando de nl , no crlf ( nl=lf ). Mi primer bash fue usar solo cr: y mientras que el xml de salida fue validado por DOM correctamente.

Estaba viendo un xml corrupto:

 < ?xml version="1.0" encoding="utf-8"?> riptions SYSTEM "Subscriptions.dtd">   

El analizador DOM ignoró los caracteres de control pero el renderizado no lo hizo. ¡Pasé bastante tiempo golpeando mi cabeza antes de darme cuenta de lo tonto que no estaba viendo esto!

Para el registro, utilizo una variable dentro del cuerpo con ambos CRLF solo para estar 100% seguro de que funcionará en todas partes.

He encontrado una diferencia entre nuevas líneas literales en y nuevas líneas literales usando .

Mientras que las nuevas líneas literales funcionaban bien en mi entorno (utilizando tanto Saxon como el procesador Java XSLT predeterminado) mi código falló cuando fue ejecutado por otro grupo que se ejecutaba en un entorno .NET.

Al cambiar a entidades ( ) mi código de generación de archivos se ejecutó consistentemente tanto en Java como en .NET.

Además, las nuevas líneas literales son vulnerables a ser formateadas por los IDEs y pueden perderse inadvertidamente cuando el archivo es mantenido por alguien “no informado”.

Desde mi experiencia, he notado que producir una nueva línea DENTRO de una cláusula no funciona. Intentaba hacer algo como:

    My value:     My other value:      

Todo lo que traté de poner en esa “nueva línea” (el nodo vacío ) simplemente no funcionó (incluyendo la mayoría de las sugerencias más simples en esta página), sin mencionar el hecho de que HTML simplemente no funcionará allí, así que finalmente tuve que dividirlo en 2 variables, llamarlos fuera del scope y poner un simple
entre ellos, es decir:

    My value:         My other value:      

Sí, lo sé, no es la solución más sofisticada, pero funciona, solo compartir mi experiencia de frustración con XSL;)

Seguí el método de Nic Gibson, este siempre fue mi favorito:

   

Sin embargo, he estado usando la tarea Ant para crear hojas de estilo y ejecutarlas contra archivos. La tarea tendrá plantillas de valor de atributo, por ejemplo, $ {DSTAMP}, pero también formateará su xml, por lo que en algunos casos, la referencia de entidad es preferible.

 
 

No podía usar el enfoque porque si formateo el archivo XML con XSLT, la entidad desaparecerá. Entonces tuve que usar un enfoque un poco más redondo usando variables

      

Puedes probar,

 
 

Funcionará.

solo agrega esta etiqueta:

 

esto funciona para mi 😉 .