Sabemos que hacer un control es generalmente más complicado que un módulo que solo implementa la misma función, porque necesitamos considerar más excepciones y adaptabilidad para lograr el efecto de integrar y reutilizar código. Y cuando desarrollamos un control ASP.NET, no importa cuán complejas sean las funciones y el rendimiento de la interfaz de usuario de nuestro control, lo que terminamos obteniendo en el navegador del cliente es solo una combinación de código HTML y scripts.
En cuanto a los códigos HTML generados por estos controles, ¿se pueden procesar sus formatos a voluntad? ¿Qué significa entonces no ser libre? ¿Tenemos que garantizar el formato del código HTML y mantener una buena sangría jerárquica de HTML? Por el contrario, aquí deberíamos intentar eliminar todo lo que no tenga nada que ver con el código HTML del control, incluidos los espacios "inútiles" y los retornos de carro. ¿Por qué enfatizar lo inútil? Sabemos que cuando el navegador procesa el código fuente HTML, los espacios y retornos de carro consecutivos se procesan y muestran como un solo espacio. Por lo tanto, parece que no necesitamos preocuparnos por los espacios adicionales inútiles o los retornos de carro antes, después o en medio del código HTML cuando se representa el control ASP.NET. Entonces, echemos un vistazo al siguiente ejemplo: <img id="analysisChart" src="ChartPic_000007.jpeg?B9FA64E7-2020-4430-AAF4-B20A51794909" usemap="#usemap_analysisChart">
<map id="usemap_analysisChart">
<área>...<área>
</mapa>
'www.downcodes.com
El fragmento de código anterior es el código HTML generado por el control Web Chart en Dundas Web Controls. Parece que no hay ningún problema al usar esta imagen de gráfico con un área activa. Si solo usa este gráfico, de hecho no hay ningún problema. Pero cuando combinamos Dundas Chart en un WebControl personalizado, su código HTML con saltos de línea y sangría causa problemas. Debido a las necesidades de diseño, necesito colocar este gráfico en una tabla y hacer que la tabla muestre un borde de píxeles que rodee estrechamente el gráfico. Originalmente, la apariencia de este gráfico era solo una imagen y no parecía haber ningún problema con esta combinación. Sin embargo, la situación real es que la imagen del gráfico nunca podría llenar la tabla exterior (como se muestra a continuación), y allí. Siempre había espacios en la parte inferior de la imagen y en el borde inferior de la mesa. Hay un espacio de 3 a 4 píxeles. Esta brecha es causada por el espacio y el salto de línea entre <img /> y <map> (aunque IE solo lo trata como un espacio).
|
Dado que Dundas Web Chart es un dll compilado publicado, resulta más problemático eliminar espacios inútiles y retornos de carro en el HTML que genera. Solo podemos sacar el código HTML de su flujo de renderizado, luego eliminar manualmente los espacios y retornos de carro entre etiquetas y luego enviarlo al flujo de salida del nuevo control. Aunque este método puede resolver algunos problemas, si los controles internos son demasiado complejos, supondrá una carga adicional en términos de precisión y eficiencia.
Entonces, de las preguntas anteriores podemos ver que cuando creamos un control ASP.NET, el código HTML que finalmente se representa debe seguir el "principio de compacidad del código" para mejorar la adaptabilidad del control. Según este principio, el ejemplo anterior debería verse así:
<img id="analysisChart" src="ChartPic_000007.jpeg?B9FA64E7-2020-4430-AAF4-B20A51794909" usemap="#usemap_analysisChart"><map id="usemap_analysisChart"><area>...<area></ mapa>
De esta manera, la imagen del gráfico está muy adyacente al borde de la tabla que la rodea.