La fijación de Generación de código HTML

La Gran Limpieza: la fijación de Generación de HTML Código (The Hard Part)

Descripción general

Como una tarea horrible como la actualización de páginas HTML estáticas pueda parecer, los documentos estáticos, al menos, tienen la ventaja de la previsibilidad. Una vez que un documento se convierte en XHTML, XHTML se mantiene a menos que alguien realmente lo modifica. El código que genera el HTML no es tan predecible. Usted puede pensar que usted ha encontrado todos los fallos en el código HTML que genera, y lo convirtió en XHTML, pero las variaciones en la forma en que el código se ejecuta con diferentes datos puede significar que usted tiene que regresar por más. Si realmente queremos generar XHTML conformes, puede que le resulte más conveniente para cambiar algunos aspectos de su estilo de codificación y no sólo arreglar el código existente. XHTML estrictas reglas sintácticas de imponer una disciplina que no ha existido en las aplicaciones Web antes y que hacen "mejores prácticas" considerablemente más importante ahora que en el pasado.

Y2K Revisited?Recientemente ha sobrevivido a los programadores de un ejercicio de arqueología de código y reparación - la limpieza de los errores del año 2000 -, pero los costos de ese proyecto eran enormes. Mientras que el fracaso de convertir a XHTML no es probable que cortar la energía del mundo, interrumpir los servicios de emergencia, o devastar la economía mundial, el proceso de limpieza es casi tan complicado como el trabajo que se hizo en el problema Y2K. A pesar de que las aplicaciones web son más recientes, muchos de ellos han sido escritos en una prisa enorme por los desarrolladores que ya se han trasladado a otros proyectos. Algunos desarrolladores, sobre todo los amantes de la escritura "ofuscado" de código, han creado una gran cantidad de código que hace lo que se supone que aunque es difícil de controlar o modificar. Prácticas de codificación adecuada tal vez haya entendido mejor en el período relativamente corto, la Web ha existido que en el período en que la mayor parte del código que no era compatible con Y2K fue escrito - pero esas prácticas no han sido honrados necesariamente. Hack-and-slash código, Corte y pegado de diversos ejemplos, ha sido muy popular en la web (incluso alentado). (Mea culpa: He hecho un montón de este tipo de código hacking mí mismo.) Dado que los navegadores HTML tienen dispositivos de perdonar sido, no sólo no ha sido una necesidad de asegurarse de que todas las que se reparten y las tes cruzadas. Cuando se ve bien en unos pocos navegadores dominantes y no el servidor de accidente, un proyecto es a menudo dispuesta a ir. La distinción entre el prototipo y para envío ha difuminado considerablemente.

Incluso en situaciones en que la práctica de codificación correcta es seguida y los comportamientos del programa son bien conocidas y manejables, en la esquina de reducción ocurre a menudo que lo hace difícil de mover programas de HTML a XHTML. Los diseñadores que buscan reducir sus tamaños de archivo han comprendido las normas de HTML (y las normas en los navegadores) con respecto a cuándo y dónde se necesitan etiquetas finales y la mejor forma para reducir el tamaño de pequeñas cantidades de espacio en blanco en la búsqueda de los archivos más pequeño posible. Este tipo de accesos directos sentido cuando la generación de páginas en gran escala - y XHTML ligeramente eleva el costo de la generación de documentos, ya que requiere el uso de etiquetas final - pero lo hacen más difícil cambiar de una aplicación de generación de HTML para generar XHTML. Si usted o su organización decide cambiar a XHTML, lo más probable es tener un montón de trabajo por hacer. El nivel de dificultad de ese trabajo depende del tipo de código que tiene que hacer frente - el idioma no es tanto lo que está escrito o lo que se ejecuta en el medio ambiente, sino cómo se ha estructurado y documentado. Es posible que desee examinar el código que tienen antes de decidir si dar el salto para tener una estimación de los costes en comparación con los beneficios. Puede que no tenga una opción, por supuesto, si sus clientes o su organización desea aplicar herramientas basadas en XML de los documentos que cree. Luego sólo tienes que cavar pulg

Preliminares

Errores: mayúsculas y minúsculasUno de los cambios más fáciles y más evidente en XHTML - el cambio de mandato de minúsculas elementos y atributos - puede ser uno de los más frustrantes para los desarrolladores, al menos para los que utilizan el marcado en mayúsculas en su código. Si bien la búsqueda y reemplazo no es tan difícil cuando se trabaja con documentos HTML estáticos, donde está claro lo que representa el margen de beneficio y lo que no lo hace, puede ser una molestia en el interior de un programa. Desarrolladores de convertir código de HTML a XHTML generación necesita mirar hacia fuera para una variedad de detalles que pueden perturbar la transición.

De variables y nombres de objetos que incluyen los nombres de elementos HTML pueden convertirse en víctimas involuntaria de búsqueda rápida y reemplazar ", posiblemente afectando sus interacciones con otros módulos de programas que no generan HTML directamente. Muchos desarrolladores se basan en caso de señales visuales para hacer su código más legible - en minúsculas para los nombres en el programa y en mayúsculas con el marcado generado. Ese enfoque ya no funciona, aunque puede ser revertida. Del mismo modo, los desarrolladores deben asegurarse de que sus cambios son a fondo el caso y que modificar el código de uso de los elementos HTML y los nombres de atributos como argumentos - no sólo el código que crea elementos y atributos. Los programas que han ido a extremos increíbles para el marcado separados del código, tal vez incluso la creación de tablas de vocabularios de formato, será la más fácil de cambiar con el. Los programas que se mezclan libremente el código y el contenido (como la mayoría de Active Server Pages y Java Server Pages) será más difícil. Este cambio de sonido relativamente simple puede imponer algunos costos reales, dependiendo del estilo de codificación utilizado. (Si su código ya utiliza minúsculas, puede contar con usted como mucha suerte!)

Errores: bien formadoDe creación de marcas que pase por el "que se ve bien en un navegador" prueba puede ocultar algunos de los graves problemas estructurales que impiden su uso fácil como XHTML. HTML permite una gran variedad de variantes sintácticas que no se puede analizar como XHTML (por ejemplo, se omite final tags) y los navegadores permiten muchas más posibilidades (como cotizaciones de sentido o etiquetas finales repetidas y omitidas en torno a valores de atributos). Dependiendo de cómo fue escrito el código, resolver esos problemas puede ser muy fácil o difícil y frustrante. "Off-by-one" bugs, donde bucles extremos en su lugar un poco el mal, puede complicar las cosas de manera significativa, sobre todo si esos errores sólo aparecen en determinados contextos. Hay una serie de situaciones comunes en las que se producen estos problemas. El p elemento párrafo se utiliza a menudo como el elemento de salto de línea br. Muchos de los primeros desarrolladores HTML tratados p elementos como el párrafo marcas utilizadas en los procesadores de texto para marcar los extremos de los párrafos, el tratamiento efectivo p como un salto de línea más grande que BR y no un contenedor de párrafos. El fragmento se muestra a continuación muestra este estilo:

Este es el número uno párrafo.  
 Este es el párrafo número dos.  
 Este es el párrafo número tres.  
 Este es el apartado número cuatro.  

Limpieza de este problema de texto de generación de código puede ser tan simple como añadir una barra inclinada (/) a la etiqueta de cierre y una

al comienzo del párrafo en una plantilla. O puede significar el rastreo del código que crea el párrafo y prólogo con una etiqueta adicional. Otra posibilidad es sustituir

con

, A pesar de que puede crear una etiqueta de apertura adicional de párrafo al final y dejar fuera de una

al comienzo de la serie. elementos de la lista tienen un problema similar, aunque por regla general en sentido inverso. Muchos desarrolladores tratar la

 PUNTO UNO 
 Artículo Dos 
 Artículo Tres 

Los desarrolladores Web también utilizan una serie de técnicas que no puedan causar problemas en los entornos en los que originalmente fueron construidos, pero que puede causar problemas si tu XHTML mover documentos XML en un entorno más orientado. Del lado del servidor incluye, Por ejemplo, use los comentarios HTML para almacenar información que los procesos de servidor. Los comentarios son un mecanismo conveniente para hacer esto porque los usuarios no ven el contenido extra que un servidor no incluyen los contenidos, a menos que buscar la fuente de los comentarios. Del lado del servidor incluye - al menos aquellos que no el contenido de referencia que pueden interrumpir la wellformedness mediante la inclusión de contenidos con el marcado desequilibrio, - deben seguir trabajando durante la transición a XHTML. No puede ser portátil sin embargo, si el documento se analizan las plantillas en formato XML antes de llegar a la inclusión del servidor de motor. XML proporciona otros mecanismos para este tipo de referencias de contenidos, llamado entidades, XHTML, pero no admite la creación de entidades externas de forma explícita. Del lado del servidor incluye probablemente aquí para quedarse, pero puede que quieran verlos de cerca - tal vez analizar el contenido antes de su envío a los usuarios - si se realiza una cirugía mayor en su Código de arquitectura de última generación.

Errores: Valid XHTMLAl tiempo que genera HTML bien formado es difícil, por lo que es XHTML válido es aún más difícil. Mientras que algunos desarrolladores pueden comprobar sus resultados respecto a la DTD HTML 4.0 (uso de herramientas tales como HTML del W3C Servicio de Validación), la mayoría no, y la disciplina de ajustarse a una estructura de documento en particular es bastante nueva introducción para la mayoría de los desarrolladores Web. No es difícil generar XHTML válido, pero el código mayores de adaptación puede ser difícil.

Los problemas involucrados en la generación de XHTML válido no difieren mucho de los problemas involucrados en la conversión de documentos HTML estático legado a XHTML. Al igual que sus homólogos de documento estático creación, muchos de los desarrolladores Web dejado fuera las características tales como el HTML, la cabeza, y los elementos del cuerpo a menos que tuvieran un uso determinado para ellos en su código. Título y apoyar el uso de elementos de metadatos para identificar las páginas a los motores de búsqueda no significa que el elemento de la cabeza aparece comúnmente. Agregar la estructura básica de un documento XHTML en el código que lo dejó fuera por lo general no es tan difícil - la mayoría de los desarrolladores no intente para especificar el elemento de título en el cuerpo de su documento de todos modos. A partir de un documento con una declaración DOCTYPE y el elemento de HTML correctamente XHTMLized es razonablemente fácil, como es asegurarse de que el documento termina con .

Por otro lado, no hay forma sencilla de asegurarse de que sus documentos generados por cumplir con las DTD XHTML. Incluso código que genera las estructuras de documento, como se describe en el artículo 13, pueden tener dificultades para pruebas de las consecuencias para la validez de documentos de la adición de un elemento particular o atributos. Además, generadores de textos no se puede hacer en todos hasta que el documento está completo. Generación XHTML válido (en realidad, cualquier tipo de XML válido) requiere de la construcción del código que escribe los documentos en torno a la DTD de alguna forma. Esto no significa que usted puede utilizar una descripción de DTD de una estructura de documento para generar el código - lo más probable es que significa que los desarrolladores la creación de un sistema concreto de la generación de documentos deben ser conscientes de la DTD y entender cómo los documentos que crean que se refieren a DTD.

Trabajo dentro de los límites previstos por el DTD no es tan difícil para los nuevos proyectos, aunque se requiere que los programadores tienen un mucho mayor nivel de comprensión del vocabulario de marcado con los que están trabajando. Para los proyectos de legado, sin embargo, los desarrolladores necesitan tanto que la comprensión y un conocimiento profundo de cómo el viejo código de trabajo. Limpieza de cosméticos pueden detectar errores graves, e incluso superar la bien formadas problemas asociados con el código viejo, pero las cuestiones de estructura del documento puede requerir más de limpieza. Asegurarse de que los elementos de bloque y elementos en línea se mezclan bien - ¡o que se cumplan todas las restricciones sobre las estructuras de forma - puede requerir un montón de pruebas y un ojo para el detalle.

NotaTrue demandas XHTML conformidad documentos válidos. Sin embargo, analizadores HTML y la no validación de entornos XML puede resultar aceptable para los documentos que estar bien formado XHTML que no se ajusta a un DTD particular. No va a pasar una prueba de validación de la W3C Servicio o de cualquier otro analizador de XML de validación, sin embargo.

Probando, probando, PruebasCualquiera que sea la estrategia que utiliza para la limpieza de su código de legado, la mejor manera de asegurarse de que funciona es probarlo en contra de una amplia gama de situaciones posibles. Esto no difiere mucho de las pruebas tradicionales de código HTML en contra de tantos exploradores como sea posible para determinar si el código parece correcto, pero es un proceso algo más formal que probablemente se logra mejor con los analizadores XML que con los ejércitos de las máquinas que funcionan los navegadores. (Con suerte, XHTML y más normas de navegadores compatibles con reducirá la necesidad de que las pruebas de estilo antiguo en el largo plazo.)

La mayoría de las herramientas para comprobar lo bien formado o validez examinar un documento único a la vez - excelente para el trabajo en pequeña escala, pero no especialmente útil si usted necesita verificar 4.000 páginas, o incluso 4.000 variaciones de una generación de código único. Afortunadamente, las opciones para las pruebas varios documentos están empezando a aparecer. El Grupo de Diseño Web WDG HTML Validator, Disponible en http://www.htmlhelp.com/tools/validator/, es una herramienta basada en Web para la validación de documentos HTML y XHTML y sitios. Incluye un modo de proceso por lotes (http://www.htmlhelp.com/tools/validator/batch.html) que acepta una lista de URLs y los informes sobre la conformidad de todos los documentos. (Parece que hay un límite de 60 años, pero es un comienzo.) También puede crear sus propias herramientas en la parte superior de los analizadores XML existentes, aunque esperemos que más herramientas de este tipo estarán ampliamente disponibles a medida que más desarrolladores de transición a XHTML.

Consejo Liam Quinn, el responsable de la Validación de código HTML WDG, también mantiene una lista de herramientas de validación de otros en http://www.htmlhelp.com/links/validators.htm. Herramientas por sí solas no pueden resolver todos sus problemas de prueba. Pruebas de conformidad de XHTML es un proceso que normalmente es necesario para llevar a cabo en varias etapas de desarrollo. Además, podrá exigir que los marcadores de posición en diversos puntos en el proceso de trabajo incompleto. Debido a que el proceso de validación no proporciona ningún método sencillo de "validación sólo esta medida en el documento, pero no te preocupes por las piezas que faltan", puede ser difícil de utilizar los procesos de pruebas automatizadas en las fases intermedias de trabajo. En estos casos, al menos hasta que alguien desarrolla un conjunto más controlable de los instrumentos de evaluación, un ser humano que lee el marcado y la compara con un profundo conocimiento de XHTML 1.0 's estructuras probablemente presenta un mejor enfoque de la prueba.