2009-02-16 31 views
7

Al intentar dar salida a un elemento textarea vacío, el procesador .NET XSLT contrae el elemento a su forma abreviada. En lugar de esto:Uso de XSLT para generar un elemento vacío HTML textarea

<textarea id="blah" name="blah"></textarea> 

me sale esto:

<textarea id="blah" name="blah"/> 

¿Qué hace que muchos navegadores web (incluyendo IE y Firefox) para hacer que el resto de la página, como si se tratara de las contenidos de la textarea. Esto apesta.

Puedo forzar al procesador XSLT para que emita las etiquetas de apertura y cierre de textarea si coloco algo intermedio como si fuera un espacio sin interrupciones. Pero eso significa que tengo que hacer más análisis y validación en el lado del cliente para saber cuándo el área de texto está "realmente" vacía. También tengo que usar JavaScript para eliminar el espacio adicional para que los usuarios no comiencen sus comentarios con un espacio en blanco.

¿Alguien sabe de una forma de forzar al procesador XSLT a procesar las etiquetas de apertura y cierre sin teniendo que insertar contenido ficticio?

Respuesta

3

Encuentra su respuesta a través de una pregunta similar sobre derecho here Stackoverflow.com :-)

Here es una explicación más detallada de MSDN.

2

I tiene que usar contenido ficticio, esta era la plantilla xsl: utilicé, solo con el carácter Línea de alimentación dentro del área de texto.

<!-- This prevents empty textarea elements being rendered as singletons in the XHTML output by adding a newline character --> 
<xsl:template name="xhtml-textarea-contents"> 
    <!-- what should be contained in the textarea --> 
    <xsl:param name="contents" /> 

    <xsl:choose> 
     <xsl:when test="$contents = ''"><xsl:text>&#x0A;</xsl:text></xsl:when> 
     <xsl:otherwise><xsl:copy-of select="$contents" /></xsl:otherwise> 
    </xsl:choose> 
</xsl:template> 
+0

esto es lo único que funcionó para mí, gracias! – travis

1

Chris Ballance tenía una respuesta que funcionó para mí. Pero vale la pena señalar que había estado usando una sobrecarga de XslCompiledTransform que la producción de una corriente, así:

XslCompiledTransform transform = new XslCompiledTransform(); 
... 
MemoryStream stream = new MemoryStream(); 
transform.Transform(reader, args, stream); 

Para aprobar los ajustes correctos a lo largo, tuve que usar la sobrecarga que aceptó una XmlWriter lugar.

// using XmlWriter so I can pass the output settings along. 
XmlWriter writer = XmlWriter.Create(stream, transform.OutputSettings); 
transform.Transform(reader, args, writer); 

Microsoft está usando un patrón de diseño realmente extraño allí.

0

Tuve un problema similar y me di cuenta de que si estableces ConformanceLevel de XmlWriterSettings en Fragment, elimina algunas de las peculiaridades de XslCompiledTransform.

FileStream xmlFileStream = File.Create("file.xml"); 
XslCompiledTransform transform = new XslCompiledTransform(); 
transform.Load("transform.xsl"); 
XmlWriterSettings settings = new XmlWriterSettings(); 
settings.ConformanceLevel = ConformanceLevel.Fragment; 
XmlWriter xmlWriter = XmlWriter.Create(xmlFileStream, settings); 
transform.Transform(sourceXml, null, xmlWriter); 
1

Si va a generar un XML o HTML, puede escribir una nueva línea dentro del área de texto y luego quitarlo con jQuery.

Este es un ejemplo con jQuery:

<textarea>&#160;<textarea> 

<script> 
$(document).ready(function(){ 
    $('textarea').each(
     function(index){$(this).text('');} 
    ); 
    }); 
</script> 
1

me he encontrado con este problema fuera de .NET, que es reproducible [para mí] en tanto <xsl:output method="xml"> y <xsl:output method="xhtml"> (estoy haciendo una suposición de que method="html" es inaplicable a nuestro escenario donde la producción tiene que ser XML bien formados)

para evitar la etiqueta de área de texto se colapse tenemos que insertar algunos contenidos en él, pero también tenemos que evitar la manipulación de contenido real.La siguiente:

<xsl:if test="not(normalize-space())"><xsl:comment></xsl:comment></xsl:if> 

produce resultados correctos (es decir, impide vacío textarea de auto-cierre y no introduce contenido artificial). Creo que este comportamiento se menciona en la especificación en node construction from post-schema-validation infoset, donde los valores de cadena de los comentarios vacíos se convertirán en cadenas de longitud cero; sin embargo, el fraseo del documento también está disponible para la lectura ligera de la tarde.

Empujar un poco más allá (por lo que si no se altere el contenido, lo que realmente necesita xsl:if?), esta es la plantilla final que evita que ciertas etiquetas se colapsen (aspiro a seguir el patrón identity transform) :

<xsl:template match="node()|@*"> 
    <xsl:copy> 
     <xsl:apply-templates select="node()|@*"/> 
    </xsl:copy> 
</xsl:template> 

<xsl:template match="textarea"> 
    <xsl:copy> 
     <xsl:apply-templates select="node()|@*"/> 
     <xsl:comment></xsl:comment> 
    </xsl:copy> 
</xsl:template> 

NB: comportamiento navegadores sugeriría esta transformación se debe aplicar a algunos otros elementos, así como los párrafos. Sin embargo, tener un autocierre <p/> no es tan destructivo como tener un cierre automático <textarea/>!

Cuestiones relacionadas