Traducción de Artículo de Ajax XXI

El valor de los objetos
Ahora que tenés alguna terminología básica en tu haber, es hora de enfocar mas en esos pequeños rectángulos con nombres de elementos y texto adentro. (figura 1). Cada rectángulo es un objeto; ahí es donde el navegador resuelve algunos de esos problemas con el texto. Usando objetos para representar cada parte del documento HTML, se vuelve muy fácil cambiar la organización, aplicar estilos, permitir a JavaScript acceder al documento y mucho mas.
Tipos de Objetos y Propiedades
Cada tipo posible de markup tiene su propio tipo de objeto. Por ejemplo, los elementos en u HTML son representados por un objeto tipo element. El texto en tu documento es representado por un tipo Text, los atributos son representados por tipos Attribute y así con todos.
Entonces el navegador Web no solo tiene la posibilidad de usar un modelo de objetos para representar tu documento --dejando de lado el hecho de que tiene que tratar con texto estático--sino que también puede decir inmediatamente que es algo por su tipo de objeto. El documento HTML es analizado y convertido en un grupo de objetos como el que viste en la figura 1 y luego cosas como paréntesis angulares y secuencia de escape no son mas un problema. Esto hace que el trabajo de navegador, al menos después de que analiza el HTML de la entrada, mucho más simple. La operación para descubrir si algo es un elemento o un atributo y luego determinar que hacer con ese tipo de objeto es simple.
Usando objetos, el navegador Web puede entonces cambiar las propiedades de esos objetos. Por ejemplo, cada elemento tiene un padre y una lista de hijos. Por eso agregar un nuevo elemento o texto hijo es simplemente un asunto de agregar un nuevo hijo a una lista de hijos de un elemento. Esos objetos tiene también una propiedad style, por esto se vuelve fácil cambiar el estilo de un elemento o parte de texto al vuelo. Por ejemplo, podrías cambiar la altura de un div usando JavaScript como este:

someDiv.style.height = "300px";

En otras palabras, los navegadores Web pueden cambiar fácilmente la apariencia y estructura del árbol usando propiedades de objetos como esta. Comparando esto con la calse de cosas complicadas que el navegador tiene que hacer si representa la página como texto internamente; cada cambio de propiedades o estructuras que el navegador reescriba el archivo estático, lo re-analice y lo vuelva a mostrar en la pantalla. Todo esto se vuelve posiblo con objetos.
En este punto, tomate el tiempo de abrir algunos de tus documentos HTML y esquematizarlos como árbol. Así como este parece ser un pedido bastante inusual --especialmente de un artículo que contiene tan poco código -- vas a necesitar familiarizarte con la estructura de esos arboles si querés poder manipularlos.
En el proceso, probablemente te encuentres con otras rarezas. Por ejemplo, consideremos las siguientes situaciones:

• ¿Qué pasa con los atributos?
• ¿Qué pasa con el texto que es interrumpido por elementos, como em y b?
• ¿Y qué pasa con el HTML que no esté estructura do correctamente (como cuando falta la etiqueta de cierre p)

Una vez familiarizado con estos temas, vas a entender algunas de las próximas mucho mejor.
Estricto es algo bueno
Si intentaste el ejercicio que acábo de mencionarte, probablemente encontraste algunos de los problemas potenciales de una vista de árbol en tu markup (si no hiciste el ejercicio, solo toma mi palabra). De hecho, vas a encontrar muchos de ellos en el listing 1 y en la figura 1, empezando por la manera en que el elemento p se interrumpe. Si le preguntás al típico desarrollador Web cual es el contenido del elemento p, la respuesta más común sería, "Bienvenido a una página realmente aburrida" y si comparás esto con la figura 1, vas a ver que esa respuesta --aunque lógica-- no es totalmente correcta.
Resulta que el elemento p tiene tres objetos hijo diferentes y ninguno contiene todo el texto "Bienvenidos a una página realmente aburrida". Vas a encontrar partes de ese texto, como "Bienvenido a una Pagina Web" y "aburrida", pero todo completo. Para entender esto, recuerda que todo en tu markup tiene que ser convertido en un objeto de algún tipo.
Es más, el orden importa! ¿Podes imaginarte como los usuarios responderían a un navegador Web si este muestra el markup correcto, pero en un orden diferente que el que vos le diste en tu HTML? ¿Los párrafos se intercalan entre títulos y cabeceras, aún cuando así no es como vos organizaste tu propio documento? Obviamente, el navegador debe preservar el orden de los elementos y el texto.
En este caso, el elemento p tiene tres partes distintas:

• El texto que va antes del elemento em
• El elemento em mismo
• El texto que va después del elemento em

Si mezclas este orden, podrías aplicar el énfasis en una porción errónea del texto. Para mantener todo esto en orden, el elemento p tiene tres objetos hijos en el orden que esas cosas aparecieron en el HTML del Listing 1. Además, el texto enfatizado "realmente" no es un hijo del elemento p, es un hijo del em que es un hijo de p.
Es muy importante para vos entender este concepto. Aun cuando el texto "realmente" se va a ver probablemente junto con el resto del texto del elemento p, igual es un hijo directo del elemento em. Puede tener formato diferente del resto del p y puede ser movido independientemente del resto del texto.
Para ayudar a consolidar esto en tu mente, trata de diagramar el HTML de los listings 2 y 3, asegurándote de mantener el texto con su padre correcto (a pesar de como el texto se termine viendo en la pantalla).

Listing 2. markup con anidación de elementos levemente difícil.

<html>

<head>

<title> Este es un poquito difícil</title>

</head>
<body>

<h1>Poné<u>mucha</u> atención, OK?

</h1>
<div>
<p>
Este p no es realmente <em>necesario</em>, pero hace la <span id="bold-text">estructura <i> y </i>la organización</span> de la página fácil de mantener
</p>
</div>

</body>
</html>

Listing 3. Anidación de elementos un poco más difícil.

<html><head><title> Este es un poquito difícil</title> </head>
<body>
<div id="main-body">
<div id="contents">
<table>
<tr> <th>Pasos </th> <th>Proceso </th> </th>
<tr> <td>1 </td><td>Descubre el <em>elemento raiz</em>. </td> </tr>
<tr> <td>2 </td><td>Trabajar con la <span id="code">cabecera</span> primero, es normalmente fácil. </td> </tr>
<tr> <td>3 </td><td>Trabajar en el <span id="code">cuerpo</span>. Solo <em>tomate tu tiempo </em>.</td> </tr>
</table>
</div>
<div id="closing">
Este link <em>no</em> está activado, pero si lo estuviera, las respuestas a esto <a href=" answers.html"><img="exercise.gif" /></a>estarían ahí. Pero <em>hacé el ejercicio igual </em>
</div>
</div>
</body>
</html>

Vas a encontrar las respuestas de estos ejercicios en los archivos GIF tricky-solution.gif en figura 2 y trickier-solution.gif en figura 3 al final de este artículo. No las mires hasta que hayas tenido el tiempo de resolverlos vos mismo. Te ayudara a entender como aplicar las reglas estrictamente para organizar el árbol y realmente ayudarte en tu búsqueda de dominar HTML y su estructura de árbol.
¿Qué pasa con los atributos?
¿Te encontraste con algún problema cuando trataste de descubrir que hacer con los atributos? Como mencioné, los atributos tienen su propio tipo de objeto, pero un atributo nos es realmente un hijo del elemento en donde aparece --elementos anidados y texto no están al mismo nivel de un atributo y vas a notar que las respuestas de los ejercicios en los listings 2 y 3 no tiene atributos mostrados.
Los atributos de hecho son almacenados en el modelo de objeto que usan los navegadores, pero son un caso especial. Cada elemento tiene una lista de atributos disponibles, separado de la lista de objetos hijos. Entonces un elemento div podría tener una lista que contenga un atributo llamado "id" y otro llamado "class".
Ten en mente que los atributos de un elemento deben tener nombres únicos; en otras palabras, un elemento no puede tener dos atributos "id" u dos "class". Esto hace que la lista sea muy fácil de mantener y acceder. Como vas a ver en el próximo artículo, podes simplemente llamar a un método como getAttribute("id") para obtener el valor de un atributo por su nombre. Podes también agregar atributos y establecer ( o poner a cero) el valor de un atributo existente con un llamado a método similar.
También vale la pena precisar que el hecho de que los nombres de los atributos sean únicos hace es ta lista diferente de la lista de objetos hijo. Un elemento p puede tener múltiples elementos em dentro de el. entonces la lista de objetos hijo puede contener ítem duplicados. Si bien la lista de hijos y la lista de atributos operan de manera similar, una puede contener duplicados (los hijos de un objeto)y la otra no (los atributos de un elemento objeto). Finalmente, solo los elementos pueden tener atributos, entonces los objetos de texto no tienen listas asociadas a ellos para almacenar atributos.
HTML descuidado
Antes de continuar, un tema nuevo vale la pena un tiempo cuando viene de cómo un navegador convierte el markup en una representación de árbol -- cómo un navegador se encarga del markup que no esta bien armado. Bien armado es en realidad un termino muy usado en XML y significa dos cosas básicas:

• Toda etiqueta de apertura tiene una etiqueta de cierre coincidente. Entonces todo <p> se relaciona en el documento con un </p>, todo <div> con un </div>, y así sucesivamente.
• La etiqueta de apertura más interior hace juego con la etiqueta de cierre mas interior, luego la siguiente etiqueta de apertura más interior con la siguiente etiqueta de cierre mas interior y así sucesivamente. Por eso <b><i>negritas e itálicas </b></i> sería ilegal porque la etiqueta de apertura <i> esta incorrectamente relacionada con la etiqueta de cierra más interior <b>. Para armar bien esto, necesitarías cambiar el orden de las etiquetas de apertura u el orden de las etiquetas de cierre. (si se cambian ambas, mantendrías el problema)

Estudia estas dos reglas atentamente. Ambas son reglas que no solo aumentan la sencilla organización de un documento, sino que también eliminan la ambigüedad. ¿Debería aplicarse negritas primero y luego itálicas? ¿o al revés? Si parece que este orden y ambigüedad no es un gran problema, recuerda que CSS permite a las reglas que sobrescriban otras reglas para, por ejemplo, la fuente del texto entre elementos b sea distinta de la fuente entre elementos i, el orden en el cual el formato sea aplicado se vuelve muy importante. Por lo tanto, el buen formato de una página HTML entra en juego.
En los casos donde un navegador recibe un documento que no esté bien armado, hace simplemente lo mejor que puede. La estructura de árbol resultante es en el mejor de los casos, una aproximación de lo que el autor original de la pagina previó o peor algo completamente diferente. Si cargaste tu pagina en un navegador y viste algo completamente inesperado, puede ser que hayas visto el resultado de un navegador tratando de adivinar que debería ser tu estructura y haciendo el trabajo mal. Por supuesto, la solución a esto es bastante simple: ¡asegurate de que tus documentos estén bien armados! Si no tenés claro como escribir HTML estandarizado como este, consultá los recursos por ayuda.

Traducción de Artículo de Ajax XX

Que hace el markup
Una vez que te des cuenta de que tu markup es realmente sobre organización, podes verlo diferente. Mas que pensar que un H1 hace que el texto se vea mas grande, en color Negro, estilo Negritas, pensá el H1 como un heading. Como ve el usuario eso -- y si el usuario usa tu CSS, la suya, o alguna combinación de las dos--es una consideración secundaria. En su lugar, date cuenta de que el markup es realmente sobre proveer este nivel de organización; un p indica que ese texto está en un párrafo, img denota una imagen, div divide un página en secciones y así sucesivamente.
Deberías tener claro también que estilo y comportamiento (gestionadores de eventos y JavaScript) son aplicados a esta organización, después de todo. El markup tiene que estar en su lugar para operar sobre el o aplicarle estilo. Entonces, como probablemente tengas CSS en un archivo externo a tu HTML, la organización de tu markup está separada de su estilo, formato y comportamiento. Así como ciertamente podés cambiar el estilo de un elemento o pieza de texto desde JavaScript, es más interesante cambiar la organización que tu markup presenta.
Mientras que mantengas en la mente que tu markup solo provee organización, o marco, a tu página, estás adelante en el juego. Y un poco mas todavía, vas a ver como el navegador toma esta organización textual y la transforma en algo mucho más interesante --un grupo de objetos, cada uno de los cuales pueden ser cambiados, agregados o borrados.
Las ventajas del markup de texto
Antes de referirme al navegador Web, vale la pena considerar porqué el texto plano es absolutamente la mejor opción para almacenar tu HTML (para mas de esto, ver algunos pensamientos adicionales sobre markup ). Sin entrar en pro y contra, simplemente resalto que tu HTML es enviado a través de la red a una navegador Web toda vez que la página es vista (poniendo el cache y demás a un lado por motivos de simplicidad). Simplemente no hay abordaje más eficiente que pasar por texto. Objetos binarios, representaciones gráficas de la página, y partes reorganizadas del markup... todas ellas son mas difícil de enviar a través de la red que archivos de texto plano.
Adicionar a eso el valor que un navegador agregar a la ecuación. Los navegadores de hoy permiten a los usuarios cambiar el tamaño del texto, escalar imágenes, descargar el CSS o JavaScript de una página (en la mayoría de los casos) y mucho más --todo esto imposibilita todo tipo de representación gráfica de la página al navegador. En cambio, el navegador necesita el HTML crudo para poder aplicar cualquier proceso a la página en el navegador más que confiar en al servidor que se encargue de esa tarea. En la misma linea, separar CSS del JavaScript y separar estos del markup HTML requiere un formato que se fácil de, bueno, separar. Archivos de texto otra vez son una manera genial de hacer esto.
Por ultimo, pero no menos importante, recuerda que la promesa de los nuevos estándares como HTML 4.01 y XHTML 1.0 y 1.1 separan contenido (la información en tu página) de presentación y estilo (normalmente aplicado con CSS). Para los programadores separar si HTML de sus CSS, luego forzar a un navegador a devolver alguna representación de una página que una todo eso junto, frustra muchas de las ventajas de esos estándares. Mantener esas partes dispares separadas hasta el navegador le permite mayor flexibilidad al obtener el HTML del servidor.

Algunos pensamientos adicionales sobre markup
Editar texto plano:¿bien o mal?
Los archivos de texto plano son ideales para guardar markup, pero eso no es así para editar el markup. Es perfectamente aceptable el uso de un IDE como Macromedia DreamWeaver --o el un tanto mas intrusivo Microsoft Front Page-- para trabajar en el markup de la página. Esos ambientes a menudo ofrecen atajos y ayuda al crear páginas Web, especialmente cuando estas usando CSS y JavaScript, cada uno de un archivo externo a un markup de pagina real. Muchos todavía prefieren el viejo y querido Notepad o Vi (lo confieso yo soy uno de ellos) y es una gran opción también. En todo caso, el resultado final es un archivo de texto lleno de markup.
Texto sobre la red: algo bueno.
Como ya se mencionó, el texto es un gran medio para un documento --como HTML o CSS-- que es transferido por la red cientos y miles de veces. Cuando digo que el navegador tiene un tiempo difícil representando el texto, significa específicamente transformar el texto en un página gráfica que los usuarios ven. Esto no tiene relación con como el navegador realmente recupera una página del servidor Web; en ese caso, el texto es todavía más la mejor opción.

Una mirada mas profunda a los navegadores Web
Para algunos de ustedes, todo lo que han leído hasta ahora puede ser una revisión divertida de tu rol en el proceso del desarrollo Web. Pero en lo que concierne a que hace el navegador Web, muchos de los diseñadores y desarrolladores Web mas listos a menudo no se dan cuenta de que pasa realmente "abajo del capot". Me focalizaré en eso en esta sección. Y no te preocupes, el código vendrá pronto, pero aguanta tu impaciencia de codificar por que entender exactamente que hace un navegador Web es esencial para que trabajes en tu código correctamente
Las desventajas del markup de texto
Justamente como texto el markup tiene ventajas fabulosas para un diseñador o un creador de páginas, también tiene desventajas un tanto significativas para el navegador. Específicamente, los navegadores tienen un tiempo muy difícil en cuanto a representar markup de texto visualmente para el usuario (para mas de esto, ver algunos pensamientos adicionales sobre markup)Considerar estas tareas frecuentes del navegador:

• Aplicar estilos CSS --frecuentemente de múltiples hojas de estilo en archivos externos-- para un markup basado en el tipo de elementos, sus clases, sus ids y sus posiciones en el documento HTML.
• Aplicar los estilos y formatos basados en código JavaScript --también frecuentemente en archivos externos-- a partes diferentes del documento HTML.
• Cambiar el valor de los campos de formulario basado en el código JavaScript
• Dar soporte a efectos visuales como rollover e intercambio de imágenes en código JavaScript.

La complejidad no está en codificar esas tareas; es bastante fácil hacer cada una de esas cosas. La complejidad viene desde el navegador realmente, llevando a cabo la acción solicitada. Si el markup es almacenada como texto y, por ejemplo, querés centrar el texto (text-align: center) de un elemento p en la clase center-text,¿como lográs esto?

• ¿Agregás estilo en la linea del texto?
• ¿Aplicás el estilo al texto HTML en el navegador y solo continuas con cual contenido centrar o no centrar?
• ¿Aplicás HTML sin estilo y luego aplicas el formato?

Estas tan difíciles preguntas son porqué pocas personas codifican navegadores estos días. (Esos quienes deberían recibir un caluroso agradecimiento)
Claramente, texto plano no es una gran manera de guardar HTML para el navegador aun cuando el texto fuera una buena solución para obtener el markup de una página en primer lugar. Sumale a esto la habilidad de JavaScript de cambiar la estructura de una página y las cosas se vuelven realmente difíciles. ¿Debería el navegador reescribir la estructura modificada al disco? ¿Como puede actualizar con cual es la etapa actual del documento?
Claramente, texto no es la respuesta. Es difícil de modificar, torpe para aplicar estilos y comportamiento y lleva en última instancia poca semejanza a la naturaleza dinámica de Web pages de hoy.
Mudanza a una vista de árbol
La respuesta a este problema --al menos, la respuesta elegida por los navegadores Web de hoy en día-- es usar una estructura de árbol para representar HTML. Veamos el listing 1 , una página HTML bastante simple y aburrida representada como texto markup.

Listing 1 Pagina HTML simple en markup de texto

<html>
<head> <title>Arboles, árboles por todas partes</title>
</head> <body>
<h1> Arboles, árboles por todas partes</h1>
<p> Bienvenido a una página <em>realmente</em> aburrida</p>
<div>
Vuelve pronto.
<img scr="come-again.gif" />
</div>
</body>
</html>

El navegador toma esto y lo convierte en una estructura como árbol, como en la figura 1
Figura 1. La vista de árbol del listing 1

Hice algunas simplificaciones menores para mantener este artículo en tema. Los expertos en DOM o XML se van a dar cuenta que ese espacio en blanco puede tener un efecto en como el texto es representado en un documento y una ruptura en la estructura de árbol del navegador Web. Meterse en esto suma poco y confunde el tema, entonces si sabés sobre el efecto del espacio en blanco, genial, si no, continua leyendo y no te preocupes por el. Cuando se convierta en un tema, vas a encontrar todo lo que necesites en ese momento. el árbol empieza con el elemento contenedor mas exterior que es el elemento HTML. Este se llama el elemento raíz(root) manteniendo la metáfora del árbol. Aunque esté en la parte inferior del árbol, siempre empieza acá cuando observes y analices arboles. Si te ayuda, podes dar vuelta el esquema, aunque se pierde un poco la metáfora del árbol.
De la raíz surgen lineas que muestran las relaciones entre las diferentes partes del markup. los elementos head y el body son hijos del elemento raíz html; title es un hijo de head y luego el texto "Arboles, arboles, en todas partes" es un hijo de title. El árbol entero se organiza así, hasta el navegador obtiene una estructura similar a lo que ves en la figura 1.
Algunos términos adicionales
Para continuar con la metáfora del árbol, head y body se dice que son ramas del html. Son ramas por que ellas por su lado tienen sus propios hijos. SI vas a las extremidades del árbol, te vas a encontrar mayormente con texto como "Arboles, árboles, por todos lados" y "realmente". A estos normalmente nos referimos como Hojas por que no tienen hijos. No necesitas memorizar esos términos y es frecuentemente mas fácil solo visualizar la estructura de árbol cuando trates descubrir que significa un término particular.

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.

Traducción de Artículo de Ajax XVIII

Tipos de peticiones adicionales
Si realmente quieres tener el control del objeto XMLHttpRequest, considera este última parada -- agregar peticiones HEAD a tu repertorio. En los dos artículos previos, te mostré como hacer peticiones GET, en un próximo artículo, vas a aprender todo sobre mandar información al servidor usando las peticiones POST. Con el espíritu de realzar la gestión de errores y la reunión de información, debes aprender como hacer peticiones HEAD.
Hacer la Petición
Realmente hacer una petición HEAD es absolutamente trivial. Simplemente llama al método open() con HEAD en vez de GET o POST como primer parámetro, como de muestra en el listing 9.

Listing 9. Hacer una petición HEAD con Ajax

function getSalesData(){
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

Cuando haces una petición HEAD como esta, el servidor no devuelve una respuesta real como lo haría para una petición GET o POST. En su lugar, el servidor solo tiene que devolver las cabeceras de la fuente que incluye la ultima hora que el contenido de la respuesta fue modificado, si la fuente de la petición existe o no, y algunas otras partes interesantes de información. Podés usar varias de esas para descubrir sobre un recurso antes que el servidor haya procesado y devuelto ese recurso.
La cosa mas fácil que puedes hacer con una petición como esta es simplemente mostrar todas las cabeceras de la respuesta. Esto te da la pauta de que es lo que tenes disponible a travez de las peticiones HEAD. El listing 10 provee una funcion de rellamada simple para exteriorizar todas las cabeceras de respuesta de una peticion HEAD.

Listing 10. Imprimir todas las cabeceras de respuesta de una petición HEAD

function updatepage(){
if (request.readyState == 4){
alert(request.getAllResponseHeader());
}
}

Controlar la figura 7, que muestra las cabeceras de respuestas de una aplicación simple que hace peticiones HEAD a un servidor.

Figura 7. Cabeceras de respuesta de una petición HEAD

Podés usar cualquiera de esas cabeceras (desde el tipo de servidor hasta el tipo de contenido) individualmente para dar información extra o funcionalidad dentro de una aplicación Ajax.
Controlar una URL
Ya has visto como controlar un error 404 cuando una URL no existe. Si esto se vuelve un problema comun --probablemente algún script o servlet este fuera de lineo cada tanto-- podrías querer controlar la URL antes de hacer una petición GET o POST completa. Para esto, haz una petición HEAD y luego controla el error 404 en tu funcion de rellamada; El listing 11 muestra una rellamada de muestra.

Listing 11. controlar si una URL existe

function updatePage(){
if (request.readyState ==4){
if (request.status==200){
alert ("Existe URL");
} else if (request.status ==404){
alert ("No existe la URL");
} else{
alert ("El estado es: " + request.status);
}
}
}

Para ser honestos, esto tiene poco valor. El servidor tiene que reponder la petición y resolver una respuesta para poblar el tamaño del contenido de la cabecera de respuesta, entonces no salvas nada de tiempo de procesamiento. Además, toma tanto tiempo hacer la petición y ver si la URL existe usando un petición HEAD que si lo hicieras usando GET o POST, solo estionando los errores como se muestra en el Listing 7. Aún así, a veces es útil saber exactamente que está disponible; nunca sabes cuando surgirá la creatividad y necesites la petición HEAD.
Peticiones HEAD útiles
Un área donde vas a encontrar útil la petición HEAD es para controlar el tamaño del contenido o también el tipo del contenido. Esto te permite determinar si tal cantidad de información va a ser devuelta para procesar la petición o si el servidor va a tratar de devolver información binaria en vez de HTML, texto o XML (los cuales son mucho mas fácil de procesar por JavaScript que la información binaria).
En esos casos, usas la cabecera apropiada y lo pasas al método getResponseHeader() del objeto XMLHttpRequest. Entonces para obtener el tamaño de una respuesta, solo llama al request.getResponseHeader("Content-Length");. Para obtener el tipo del contenido, usa request.getResponseHeader("Content-Type");.
En muchas aplicaciones, hacer peticiones HEAD no agrega funcionalidad y hasta poner lenta una petición (forzando una petición HEAD para obtener información sobre la respuesta y luego la petición GET o POST para obtener la respuesta propiamente dicha). Sin embargo, en el caso de que no estes seguro sobre un script o un componente del lado servidor, una petición HEAD puede permitirte obtener alguna información básica sin tener que lidiar con información de respuesta ni necesitas el ancho de banda para enviar esa respuesta.
En Conclusión
Para muchos programadores de Ajax y Web, el material en este artículo puede parecer bastante avanzado. ¿Cual es el valor de hacer una petición HEAD?¿Cual es realmente el caso donde deberías gestionar un codigo de estado de redireccionamiento explicito en tu JavaScript? Son buenas preguntas; para aplicaciones simples, la respuesta es que esas tecnicas avazadas probablemente no sean validas.
Sin embargo, la Web no es mas un lugar donde solo son toleradas aplicaciones simples; usuarios han vuelto más avanzados, los clientes esperan robustez y reportes de errores avanzados, y los directores son despedidos porque una aplicacion se cae un 1% del tiempo.
Es tu trabajo entonces, ir más allá de una simple aplicación y eso requiere una comprensión más profunda de XMLHttpRequest.

• Si puedes explicar la variedad de estados ready --y comprender como se diferencian de navegador a navegador -- serás capas de eliminar errores de una aplicación rápidamente. Puede ser que incluso aparezcas con una creativa funcionalidad basada en los estados Ready y reportes un estado de la petcion a los usuarios y clientes.
  
• Si tiene un manejo de los códigos de estados, podes fijar tu aplicación para que maneje los errores en el script, las respuestas inesperadas y los casos límite. Como resultado, tu aplicación va a trabajar todo el tiempo, mas que solo en llas situaciones en que todo está bien.
  
• Agregas a hesta habilidad el hacer peticiones HEAD, controlar la existencia de una URL, y descubrir cuando un archivo fue modificado y puede asegurar que los usuarios acceden a páginas validas, estan actualizados en su información y (lo más importante) los sorprendes con solo lo robusta y versatil que es tu aplicación.
  

Este artículo no va a hacer tus aplicaciones llamativas, ayudarte a resaltar el texto con luces amarillas que se devanecen, o que se sientan más como un escritorio. Mientras estas son todas fortalezas de Ajax (y temas que trataremos en próximos artículos) son en algun grado solo beneficios adicionales. Si podés usar Ajax para construir una sólido base en la cual tu aplicación maneje los errores y problemas suavemente, los usuarios van a volver a tu sitio y aplicación. Agregale a esto los trucos visuales de los que vamos a hablar en próximos artículos y vas a tener clientes emosionados, entusiasmandos y felices. (seriamente, no querrás perderte el próximo artículo!)