Traducción de Artículo de Ajax XIX

Dominar Ajax Parte 4: Explotar DOM para la respuesta Web
Convertir HTML en un Modelo de Objetos para hacer las paginas Web Dinámicas e interactivas

Nivel: Introductorio

Brett McLaughlin (brett@oreilly.com), Autor y Editor, O´Reilly y Asociados.
14 Mar 2006

La gran división entre programadores (que trabajan con aplacaiones Back-end) y Programadores Web (que gastan su tiempo escribiendo HTML, CSS y JavaScript)es de muchos años. Sin embargo, el Modelo de Objetos de Documento (DOM) rompe las distancias, y hace posible trabajar con ambos XML en el Back-end y HTML en el front-end y como un herramienta efectiva. En este artículo, Brett McLaughlin introduce el Modelo de Objetos de Documento, explica su uso en las páginas Web y empieza a explorar su uso desde JavaScript.

Como muchos programadores Web, probablemente hayas trabajado con HTML. HTML es como los programadores empiezan a trabajar en una página Web; HTML es a menudo la última cosa que hacen al terminar una aplicación o sitio, y un poco de colocación, color o estilo. Y tan común como es el uso de HTML, es la idea equivocada de que es exactamente lo que le pasa a ese HTML una vez que va al navegador para generar la pantalla. Antes, profundizo en que podrías pensar que sucede --y por que es probablemente erróneo--quiero que tengas claro el proceso involucrado en el diseño y el servicio de páginas web:

1. Alguien (normalmente vos!) crea HTML en un editor de texto o IDE
2. Luego subes el HTML a un servidor Web, como Apache HTTPD, lo haces publico en Internet o en una intranet.
3. Un usuario solicita tu página Web con un navegador como FireFox o Safari
4. El navegador del usuario hace una petición del HTML a tu servidor Web
5. El navegador muestra la página que recibió del servidor gráficamente y textualmente; el usuario mira y activa la página Web.
   

Mientras que esto se siente muy básico, las cosas se volverán interesante rápidamente. De hecho, la tremenda cantidad de "cosas" que pasan entre los pasos 4 y 5 es lo que enfoca este artículo. El termino "cosas" realmente se aplica también, ya que la mayoría de los programadores nunca consideran lo que pasa exactamente a su especificación de formato(markup) cuando un usuario pide que se lo muestre:

• ¿El navegador solo lee el texto en el HTML y lo muestra?
• ¿Que pasa con CSS, espacialmente si el CSS esta en un archivo externo?
• ¿Y sobre JavaScript -- otra vez a menudo en un archivo externo?
• ¿Como el navegador gestiona esos ítem y como relaciona los gestionadores de eventos, funciones y estilos para esta especificación de formato (markup) textual?
  

Resulta que la respuesta a todas esas preguntas es el Modelo de Objetos de Documento. Entonces, sin más complicaciones, vamos a profundizar en DOM.
Programadores Web y especificación de formato (markup)
Para la mayoría de los programadores, su trabajo termina donde el navegador Web empieza. En otras palabras, una vez que colocaste un archivo HTML en un directorio en tu servidor Web, generalmente la archivas como lista y (esperanzadamente) nunca pensás realmente en ella de nuevo. Esa es una gran meta cuando viene de la escritura limpia, páginas bien-organizadas, también; no hay nada de malo con querer que tu especificación de formato muestre lo que debe, en todos los navegadores, con varias versiones del CSS y del Javascript.
El problema es que esta manera limita la comprensión del programador de que es lo que realmente pasa en el navegador. Mas importante, limita tu habilidad de actualizar, cambiar y reestructurar una página Web dinámicamente usando JavaScript del lado cliente. Sacate de encima esa limitación, y permite una todavía más grande interacción y creatividad en tu páginas Web.
Lo que hacen los programadores
Como típico programador Web, probablemente dispares tu editor de texto y IDE y empezás a ingresar HTML, CSS, o más, JavaScript. Es fácil pensar en esas etiquetas y selectores y atributos solamente como pequeñas tareas para hacer que un sitio de vea bien. Pero necesitas flexibilizar tu mente más allá de ese punto -- en su lugar, darte cuenta de que estas organizando tu contenido. No te preocupes; te prometo esto no se va a transformar en una lectura sobre la belleza del markup lo que tenés que darte cuenta es el verdadero potencial de tu página Web, y todo lo metafísico más. Lo que necesitas entender es exactamente cual es tu rol en el desarrollo Web.
Cuando viene como se ve una página, a lo mejor solamente podes hacer sugerencias. Cuando proporcionas una hoja de estilos CSS, un usuario puede invalidar tus elecciones de estilo. Cuando proporcionas un tamaño de fuente, un navegador de un usuario puede alterar esas medidas para los de visión disminuida o escalarlo en monitores masivos (con resoluciones igualmente masivas). También los colores y los tipos de fuentes que elegiste están sujetas al monitor de los usuarios y a las fuentes que los usuarios instalen en sus sistemas. Si bien es genial que hagas lo mejor que puedas en el estilo de una página, ese no es el más grande impacto que tienes en una página Web.
Lo que vos controlás absolutamente es la estructura de tu página Web. Tu markup no se puede cambiar, es inalterable y los usuarios no puede hacer un lio con el; sus navegadores solo pueden recuperarlo del servidor y mostrarlo (no obstante, con un estilo más conforme al gusto del usuario que al tuyo). Pero la organización de esta página --este esta palabra dentro de ese párrafo en en el otro div-- es únicamente tuya. Cuando realmente hay que cambiar tu página (que es lo que las aplicaciones Ajax más focalisan), es la estructura de tu página la que trabajas. Si bien es lindo cambiar el color de una parte del texto, es mucho mejor agregar texto o una sección entera a una página existente. No importa el estilo que el usuario le de a esa sección vos trabajás con la organización de la página misma.