JASoft.org

El blog de José Manuel Alarcón Aguín. Programación web y mucho más...

MENÚ - JASoft: JM Alarcón

Renderizar HTML compatible con ASP.NET 3.x para los controles Web en ASP.NET 4.0

ASP.NET 4.0 ha cambiado la forma de renderizar los controles Web. Ahora, para representarlos en las páginas resultantes, genera HTML que cumple con los estándares de la W3C. En concreto los controles de ASP.NET 4.0 Web Forms generan XHTML 1.0 Strict.

XHTML_tag
Viñeta por Gabriel Utasi

Esto es fantástico para la mayor parte de los casos, ya que nos ayudará a que nuestras aplicaciones con ASP.NET Web Forms se adapten más fácilmente a los estándares y los requisitos de accesibilidad. Sin embargo puede darnos más de un dolor de cabeza en caso de que estemos reusando código CSS o Javascript que hayamos hecho con una versión anterior. También podría trastocarnos algunos maquetados de páginas hechos con versiones anteriores de la plataforma.

Para poder volver al comportamiento anterior de ASP.NET 3.5 (en realidad 2.0) y poder elegir la forma de renderizar los controles y por tanto el tipo de HTML generado, los controles tienen una nueva propiedad llamada RenderingCompatibility. Sin embargo esta propiedad, aunque es pública y su "setter" es accesible, no se debe usar directamente, ya que la propia documentación MSDN en el enlace anterior te avisa de que "puede tener efectos impredecibles". Además, generalmente no tendrá mucho sentido hacer que un control concreto se renderice de manera diferente al resto de los controles de la página.

Así que existe un nuevo ajuste en web.config que nos permite seleccionar si queremos que los controles se rendericen como ASP.NET 4.0 o ASP.NET 3.5: ControlRenderingCompatibilityVersion. En este atributo ajustamos el modo de renderizado y ASP.NET automáticamente se ocupa de asignar la propiedad anterior en todos los controles.

Existen dos posibles valores: 3.5 y 4.0 (el valor por defecto).

Si en nuestro web.config ponemos esto:

<system.web>
  <pages controlRenderingCompatibilityVersion="3.5"/>
</system.web>

conseguiremos que los controles se rendericen como en la versión anterior de ASP.NET.

Esto significa en realidad que se van a renderizar en función de lo que indiquemos en el atributo xhtmlConformance, del que ya he hablado en otras ocasiones en este blog. Con él podremos decidir si se genera XHTML Strict, XHTML Trqansitional (lo habitual) o código no conformante con XHTML (Legacy).

Si no establecemos la compatibilidad con 3.5, ASP.NET 4.0 hace caso omiso del atributo xhtmlConformance y siempre genera XHTML Strict.

Algunos cambios llamativos en el HTML de controles

Hay un ejemplo muy llamativo del cambio de renderizado de ASP.NET 4.0 y se refiere a los controles que se establecen como deshabilitados.

En ASP.NET 2.0 hasta 3.5, cuando se establece la propiedad Enabled de un control como False para deshabilitarlo, lo que se consigue es que la etiqueta o etiquetas HTML correspondientes se deshabiliten mediante el atributo disabled. Así, por ejemplo, si deshabilitamos un control Label, así:

<asp:Label id="Label1" runat="server" Text="Etiqueta" Enabled="false">

lo que obtenemos en el HTML es esto:

<span id="Label1" disabled="disabled">Etiqueta</span>

El problema es que en XHTML 1.1 define este atributo únicamente para los controles de entrada de datos en formularios, es decir, que el atributo sólo se le aplica a los elementos HTML de tipo INPUT, SELECT, BUTTON, TEXTAREA, OPTION y OPTGROUP, como indica el estándar.

¿Entonces cómo se representan ahora las otras etiquetas que estén deshabilitadas?. Pues en el caso de un Label así:

<span id="Label1" class="aspNetDisabled">Etiqueta</span>

Esa clase CSS, , no está definida en ninguna parte, pero podemos definirla nosotros mismos en nuestra hoja de estilos de la página  para darle el aspecto que deseemos al control. Pero claro, por defecto, no notaremos diferencia en el aspecto del mismo.

Si queremos cambiar el nombre de la clase CSS usando la nueva propiedad de los controles estándar llamada DisabledCssClass, que es una cadena de texto con el nombre del estilo CSS.

¡Espero que te sea útil!

Aprende .NET, Cursos on-line tutelados:
   ·
Desarrollo Web con ASP.NET 4.0 Web Forms (Tutelado por mi)
   · ASP.NET 4.0 Web Forms desde cero (Tutelado por mi)
   · Desarrollo Web con ASP.NET MVC 2
   · Silverlight 4.0 - Aplicaciones Ricas para Internet (RIA)
   · jQuery paso a paso para programadores ASP.NET
   · Visual Studio 2010 desde cero

José Manuel Alarcón
Banner

Comentarios (4) -

Yo pensaba que el 3.5 generaba xhtml validado, segun el libro que lei de Asp.net 3.5 todo el codigo html que genera es xhtml valido.
Con respecto a lo de enabled, creo que si alguien usa esa propiedad para un control diferente a los que nombraste,  no esta bien utilizada, ya que si no queres que genere codigo podes usar la propiedad Visible = false. Un bug que me jodio bastante en asp.net 3.5 es que por ejemplo a todos los controles de imagen les genera el atributo style="border-width:0px" por defecto, y es IMPOSIBLE sacarlo (hasta donde averigue) .. entonces cuando yo queria usar mi clase CSS para modificar el borde de la imagen no podía, por que el atributo style="blabla" tiene mas prioridad que el atributo class parece. Lo tuve que solucionar metiendo las imagenes dentro de un div y aplicarle el CSS al div y no a la imagen directamente. Por suerte ahora eso ya esta solucionado.





Responder

Hola Julián:

ASP.NET 3.5 genera XHTML pero con las restricciones explicadas en el post referenciado desde este.

Lo de enamore es un ejemplo muy típico y se usa para que un control tenga un aspecto de deshabitado, no para ocultarlo.

Saludos

JM

Responder

Hola José Manuel ,
Migre una aplicación de 2.0 a 4.0 y tuvimos este problema, que felizmente fue ultrapasado, ahora tengo otro, la aplicación utiliza el reportview de SSRS y ahora, cuanto intenta abrir la ventana para configurar una subscripción al reporte desde ASP.NET, queremos seleccionar una fecha del SSRS aparece un mensaje:

This content cannot be displayed in a frame

   To help protect the security of information you enter into this website, the publisher of this content does not allow it to be displayed in a frame.

   What you can try:
    Open this content in a new window  

cuando seleccionamos OPEN this content in a new window,, abre un nuevo tab del IE y permite continuar.
Ya intente de varias formas com X-FRAME y no funciona.

SQL 2012, SSRS 2012,  II8.5, WINDOWS SERVER 2012R2

Tienes alguna idea que pueda ayudar?

Saludos y gracias de antemano.



Responder

Spain José Manuel Alarcón

Hola:

No tengo experiencia con Reporting Services, lo siento. De todos modos tiene pinta de ser porque hay una restricción por defecto en SharePoint (que es lo que usa por debajo SSRS) apara evitar que se meta en iframes.

Intenta poner este control:

<WebPartPages:AllowFraming runat="server" />

En la página que se carga en el iframe para ver si funciona, tal y como indica este post:

blogs.msdn.com/.../...nt-hosted-pages-in-apps.aspx

Siento no poder ayudarte más.

Saludos.

Responder

Agregar comentario