Traducción de Artículo de Ajax XVII

Redireccionamientos y reenrutamiento
Antes de hablar en profundidad sobre errores, vale la pena hablar sobre algo que probablemente no hay que preocuparse cuando estas usando Ajax -- redireccionamientos. En los códigos de estado de HTTP, esta es la familia 300 de los códigos de estado, incluyendo:

• 301: Movido permanentemente
  
• 302: Encontrado (La petición fue redireccionada a otra URL/URI)
• 305: Usar Proxy (La petición debe usar proxy para acceder al recurso solicitado)

los programadores de Ajax probablemente no están preocupados por los redireccionamientos por dos razones:

• Primero, las aplicaciones ajax siempre se escriben para un script, servlet o aplicación del lado-servidor especifico. Para que ese componente desaparesca y sea movido a otro lado sin que vos, el programador de ajax, te enteres es un poco extraño. Entonces, más a menudo que no, vas a saber que ese recurso fue movido (por que lo moviste), cambias la url en tu petición y nunca te encuentras con este tipo de resultados.
• y la razon las relevante es: Las aplicaciones Ajax tiene sandbox. esto significa que el dominio que sirve a una página Web que hace peticiones Ajax es el dominio que tiene que responder a esas peticiones. Por esto una pagina web servida por ebay.com no puede hacer una peticion de estilo Ajax a un script que se ejecuta en amazon.com; Aplicaciones Ajax en ibm.com no pueden peitcionar a los servlets que se ejecutan en netbeans.org

Como resultado, tus peticiones no pueden ser redirecciondas a otro servidor sin generar un error de seguridad. En esos casos, no vas a recibir un código de estado. Normalmente solo vas a tener un error JavaScript en la consola de debug. Por esto, mientras que piensas en un montón de códigos de estado, puedes ignorar en gran parte los códigos de redireccionamiento en conjunto.

Casos límite y casos difíciles
En este punto, los programadores principiantes se preguntaran qué es todo este lio. Es cierto que menos del 5% de las peticiones Ajax requieren trabajar con los estados ready 2 y 3 y los códigos de estados como el 403 (de hecho, sería más cercano al 1% o menos). Estos casos son importantes y se llaman casos límites -- ocurren en situaciones muy inusuales en las cuales se desarrollan las condiciones más extrañas. Apesar de ser inusuales los casos límites probocan alrededor de 80% de las frustraciones de los usuarios!
Los usuarios típicos de olvidan de las 100 veces que una aplicación funciona correctamente pero recuerdan claramente la vez que no lo hace. Si podes manejar los casos límite -y los casos dificiles-suavemente, entonces vas a tener contenidos a los usuarios que volveran a tu sitio.

Errores
Una vez que hayas tenido cuidado con el código de estado 200 y te hayas dado cuenta de que podes ignorar rotundamente la familia de códigos de estado 300, el otro grupo de códigos que queda para preocuparse es la familia 400, que indica varios tipos de error. Mirar de nuevo el listin 7 y notar que mientras se manejan los errores, solamente se muestra al usuario un mensaje de error genérico. Mientras este es un paso en la direccion corretam, es aun un mensaje bastante inutil a losefectos de decirle al usuario o programador que está trabajando en la aplicación que es lo que realmente esta mál.
Primero, agregar soporte a las paginas perdidas. Esto no pasa mucho en los sistemas de producción, pero no es raro en pruebas para mover un script o que un programador ingrese una URL incorrecta. Si podes reportar los errores 404 con gracia, vas a proveer mucha mas ayuda a los usuarios y programadores confundidos. Por ejemplo, si un script en el servidor fue removido y usas el codigo en el listing 7, verías un error no descriptivo como el que se muestra en la figura 5.

Figura 5. Manejo de error genérico

El usuario no tiene manera de decirte si el problema es de autenticación, o un scrip perdido (que es el caso acá), o un error de usuario, o más si algo en el código causó el problema o no. Un poco de código simple adicional puede hacer este error mucho más especifico. Hechale una ojeda al listing 8 que trata los script perdidos, así como errores de autenticación con un mensaje especifico.

Listing 8. Controlar el código de estado válido

function updatePage(){
if (request.readyState == 4){
if (request.status == 200){
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML = response[1].replace)/\n/g, "<br /&g;");
} else if (request.status == 404){
alert ("No se encontro URL solicitada.");
}else if (request.status == 403){
alert ("Acceso denegado.");
}else
alert ("El estado es " + request.status);
}
}

Esto es todavía bastante simple, pero provee algo de información adicional. La figura 6 muestra el mismo error que en la figura 5, pero esta vez el código tratador de error da una mucho mejor imagen de que esta pasando al usuario o programador.

Figura 6. Gestión de error especifica.

En tus propias aplicaciones, podrias considerar despejar el nombre de usuario y la contraseña cuando ocurre una falla de autenticación y agregar un mensaje de error a la pantalla. Pueden ser aplicadas mejoras similares para una gestion mas amigable de los script perdidos u otros errores tipo 400 (tal como el 405 para un método de petición inaceptable como enviar una petición HEAD que no está permitida o 407 en la que se requiere autenticacion de proxy). Cuaquier elección que hagas, empieza con la gestión del código de estado devuelto por el servidor.

Traducción de Artículo de Ajax XVI

Conseguir datos seguros
Toda la documentación y especificaciones insiten en que solamente cuando el estado ready esta en 4 la información es segura para usar. Creeme, rara vez encontraras un caso donde la información no pueda ser obtenida de la propiedad responseText cuando el estado ready está en 3. Sin embargo, confiar en eso en tu aplicacion es una mala idea -- desde el momento que escribis código que dependa de información completa con estado ready en 3, está casi garantizado que llegará el momento en que la información sea incompleta.
Una mejor idea es proveer al usuario de alguna información cuando el estado ready este en 3, que una respuesta esta proxima. Mientras que usar una funcion como alert() es obviamente una mala idea --usar Ajax y luego bloquear al usuario con un cuadro de dialogo de alerta es muy poco razonable -- podes actualizar un campo en tu formulario o página mientras los estados ready cambian. Por ejemplo, trata de establecer el ancho de un indicador de progreso a un 25% para el estado ready en 1, 50% para el 2, 75% para el 3 y 100% (completo) cuando el estado ready llega a 4.
Por supuesto, como has visto, esta mejora es inteligente pero navegador-dependiente. En Opera, nunca obtendrás esos dos primeros estados ready y en Safari salta el primero (1). Por esa razón, dejo el codigo como este como ejercicio antes que incluirlo en el articulo.
Tiempo de echar un vistaso a los códigos de estado.
Una mirada mas cercana a los códigos de estado de HTTP
Con los estados READY y la respuesta del servidor en tu bolsa de técnicas de programación de Ajax, etas listo para agregar otro nivel de la sofisticación a tus aplicaciones Ajax --trabajar con códigos de estado del HTTP. Estos códigos son nada nuevo a Ajax. Han estado alrededor de la Web siempre que hubo Web. Ya has visto probablemente varios de éstos con tu navegador web:

• 401: Sin autorizacion
  
• 403: Prohibido
• 404: No encontrado
  

Podes encontrar mas (Para una lista completa, ver Resources). Para agregar otra capa de control y sensibilidad (y particularmente un manejor de error más robusto) a tus aplicaciones Ajax, entonces necesitas comprobar los códigos de estado en una petición y responder apropiadamente.

• 200: Todo está Bien

En muchas aplicaciones Ajax, vas a ver una funcion de rellamada que controla el estado ready y luego continuan trabajando con la información de la respuesta del servidor, como en el listing 6.

Listing 6. Funcion de rellamada que ignora el codigo de estado

function updatePage(){
if(request.readystate ==4){
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML = response[1].replace(/\n/g, "<br />");
}
}

Esto resulta ser una mejora miope y propensa a error en programacion Ajax. Si un script requiere autentificación y tu peticion no provee credenciales validas, el servidor va a devolver un código de error como el 403 o 401. Sin embargo, el estado ready va a estar establecido en 4 ya que el servidor respondió la petición (a pesar de que la respuesta no sea la que querias o esperabas para tu petición). Como resultado, el usuario no va a obtener información valida y hasta podría obtener un error feo cuando tu JavaScript trate de usar una unformación del servidor no existente.
Toma un esfuerzo minimo asegurarse que el servidor no solo haya terminado con una petición, sino que haya devuelto un código de estado "todo esta bien". Ese código es "200" y se reporta a traves de la propiedad status del objeto XMLHttpRequest. Para estar seguro de que no solo el servidor haya terminado con una petición sino que también reporte un estado ok, agrega un control adicional en tu función de rellamada como se muestra en el listing 7.

Listing 7. Controlar el código de estado válido

function updatePage(){
if (request.readyState ==4) {
if (request.status == 200){
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML = response[1].replace(/\n/g,"<br />");
} else
alert ("el estado es " + request.status);
}
}

Con la adición de algunas líneas del código, podes estar seguro de que si algo sale mal, tus usuarios van a obtener un (custionablemente) útil mensaje de error antes que ver una pagina con información mutilada sin explicación alguna.

Traducción de Artículo de Ajax XV

Inconsistencia de navegadores
Una vez que tenes un entendimiento básico de este proceso, trata de acceder desde varios navegadores diferentes. Deberías notar algunas inconsistencias en como estos estados ready son manipulados. Por ejemplo en Firefox 1.5, ves los siguientes estados ready:

• 1
• 2
• 3
• 4

Esto no debería ser una sorpresa ya que todos los estados están representados acá. Sin embargo si accedes la misma aplicación usando Safari, deberías ver --o mas, no ver-- algo interesante. Acá están los estados que ves en Safari 2.0.1

• 2
• 3
• 4

Safari realmente deja afuera el primer estado ready y no hay una explicación sensata de porqué; es simplemente la manera en que trabaja Safari. Esto ilustra también un punto importante: mientras es una buena idea asegurar que el estado Ready de una petición sea 4 antes de usar la información del servidor, escribir código que dependa de cada cambio del estado ready es una manera segura de obtener resultados distintos en navegadores distintos.
Por ejemplo, cuando se usa Opera 8.5, las cosas son todavía peores con la salida de los estados ready:

• 3
• 4

Por último pero no menos, Internet Explorer responde con los siguientes estados:

• 1
• 2
• 3
• 4

Si tienes problemas con una petición, este es el primer lugar para buscar los problemas. Agrega un alerta para mostrar el estado ready de tu petición para que puedas asegurarte de que las cosas estan operando correctamente. Mejor todavía, prueba en Internet Explorer y Firefox--vas a obtener los 4 estados readyy vas a poder controlar cada etapa de la petición.
Luego yo miro el lado de la respuesta.
Información de respuesta bajo el microscopio
Una vez que entiendas los varios estados ready que ocurren durante una petición, estás listo para mirar otra pieza importante del objeto XMLHttpRequest --la propiedad responseText. Recuerda del último artículoque esta es la propiedad usada para obtener la información del servidor. Una vez que el servidor ha terminado de procesar la petición, situa toda información que se necesita para responder la petición en el responseText de la petición. Luego tu función de rellamada puede usar esa información, como se ve en el listing1 y 4.

Listing 4. Usar la respuesta del servidor

function updatePage() {
if(request.readyState == 4) {
var newTotal = request.responseText;
var totalSoldEl = document.getElementById("total-sold");
var netProfitEl = document.getElementById("net-profit");
replaceText(totalSoldEl, newTotal);
/*Descubrir la nueva ganancia neta*/
var boardCostEl = document.getElementById("board-cost");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("man-cost");
var manCost = getText(manCostEl);
var profitPerBoard = boardCost - manCost;
var netProfit = profitPerBoard * newTotal;
/*Actualizar la ganancia neta el el formulario de ventas*/
netProfit = Math.round(netProfit *100)/100;
replaceText (netProfitEl, netProfit);
}
}

El Listing 1 es bastante simple; el Listing 4 es un poco mas complicado, pero para empezar, ambos controlan el estado ready y luego toman el valor (o valores) de la propiedad responseText.
Visualizar el texto de respuesta durante una petición
Como el estado ready, el valor de la propiedad responseText cambia durante el ciclo de vida de la petición. Para ver esto en acción, usa el código como el que se muestra en el listing 5 para probar el texto de respuesta de una petición, tal como los estados ready.

Listing 5. Probar la propiedad responseText

function updatePage(){
//Mostrar el estado ready actual
alert("updatePage() llamada con el estado ready en " + request.readyState + " y un texto de respuesta de '" + request.responseText + "'");
}

Ahora abre tu aplicación Web en un navegador y activa tu petición. Para obtener lo maximo de este código, usa Firefox o Internet Explorer ya que estos navegadores reportan todos los estados posibles durante una petición. Con un estado ready en 2, por ejemplo, la propiedad responseText es indefinida (ver figura 3) y deberías ver un error si la consola JavaScript está abierta tambien.

Figura 3. Texto de respuesta con un estado ready en 2

Con el estado ready en 3 sin embargo, ha colocado un valor en la propiedad responseText, al menos en este ejemplo (ver figura 4).

Figura 4: Texto de respuesta con un estado ready en 3

Vas a descubrir que tu respuesta en el estado ready 3 varía de scritp a script, servidor a servidor y navegador a navegador. SIn embargo esto aun es increiblemente util para eliminar errores de tu aplicación.

Traducción de Artículo de Ajax XIV

Dominar AJAX, Parte 3: Peticiones y respuestas Avanzandas en AJAX
Ganar una comprensión completa de los códigos de estado de HTTP, de los estados READY, y del objeto de XMLHttpRequest
Nivel: Introductorio
Brett McLaughlin (brett@oreilly.com), Autor y Editor, O´Reilly y Asociados.
14 Feb 2006

Para muchos desarrolladores Web, hacer peticiones simples y recibir respuestas simples es todo lo que siempre necesitaron, pero para desarrolladores que quieran dominar Ajax, se requiere un entendimiento completo de códigos de estado de HTTP, estados Ready y el objeto XMLHttpRequest. En este artículo Brett McLaughlin te va a mostrar los diferentes códigos de estado y va a demostrar como los maneja cada navegador y va a mostrar peticiones menos usadas que se pueden hacer con Ajax

En el último artículo de esta serie, proporcioné una sólida introducción al objeto XMLHttpRequest, la pieza central de una aplicación Ajax que maneja peticiones para aplicaciones o scripts del lado servidor y tambien trata con información devuelta por ese componente del lado servidor. Toda aplicación Ajax usa el objeto XMLHttpRequest, por eso vas a querer estar intimamente familiarizado con él, para realizar tus aplicaciones Ajax y para realizarlas bien.
En este artículo, me muevo más allá de los fundamentos del artículo pasado y me concentro más en detalle sobre tres parte claves de este objeto de petición:

• Los estados Ready de HTTP
• Los códigos de estado de HTTP
• Los tipos de peticiones que podes hacer

Cada uno de estos es considerado generalmente parte de la cañería de una petición; como resultado, poco detalle se registra sobre estos temas. Sin embargo vas a necesitar ser fluido en estados Ready, códigos de estado, y peticiones si querés hacer mas que solo salpicar en programación Ajax. Cuando algo anda mal en tu aplicación -- y las cosas siempres andan mal-- entender estados Ready, como hacer una petición de cabeceras o que significa un código de estado 400 puede hacer la diferencia entre 5 minutos de eliminar errores y 5 horas de frustración y confusión.
Miraré estados READY de HTTP primero.
Introduciendonos mas profundo en los estado ready de HTTP
Debés recordar del articulo anterior que el objeto XMLHttpRequest tiene una propiedad llamada readyState. Esta propiedad asegura que un servidor ha completado una petición y típicamente una función de rellamada usa la informacion del servidor para actualizar un formulario web o página. El listing 1 muestra un ejemplo simple de esto (también en el último artículo de la serie)

Listing 1.Tratar con una respuesta del servidor en una funcion de rellamada.

function updatePage(){
if(request.readyState==4){
if (request.status==200){
var response = request.responseText.split("|");
document.getElementById("order").value=response[0];
document.getElementById("address").innerHTML=response[1].replace(/\n/g."<br />");)
} else
alert ("El estado es " + request.status);
}
}

Este es definitivamente el uso más común (y el mas simple) de los estado ready. Como seguramente adivinaras por numero "4", hay varios otros estado ready (tambien viste esta lista en el último artículo):

• 0: La petición no está inicializada (antes de llamar a la funcion open()).
• 1: La petición esta establecida pero no enviada (antes de que hayas llamado a send()).
• 2: La petición fue enviada y está en proceso (podes normalmente obtener los contenidos de cabecera de la respuesta en este punto)
• 3: La petición está en proceso , a veces alguna información parcial está disponible de la respuesta, pero el servidor no ha terminado con esa respuesta.
• 4: La respuesta esta completa, podes tomar la respuesta del servidor y usarla.

Si deseas ir mas alla de los fundamentos de la programación en Ajax, necesitas saber no solo estos estados sino cuando ocurren y como podes usarlos. Sobre todo, necesitas aprender en qué estado de una petición encuentras cada estado READY. Desafortunadamente, esto es bastante poco intuitivo y también implica algunos casos especiales.
Estados ready ocultos
El primer estado ready, identificado por la propiedad del readyState 0 (readyState== 0), representa una petición no inicialidada. Tan pronto como llames a open() en tu objeto petición, esta propiedad se establece a 1. Como casi siempre llamas a open() tan pronto como inicializas tu petición, es raro ver readyState==0. Es más el estado ready sin inicializar es bastante inútil en aplicaciones prácticas.
No obstante, en el interés de ser completo, comprobar en el listing 2 que demuestra cómo conseguir el estado READY cuando es 0.

Listing 2. Obtener el estado ready 0

function getSalesData() {
//crear el objeto petición
createRequest();
alert("El estado Ready es " - request.readyState);
//Establecer (inicializar) la petición
var url = "/boards/servlet/updatePage";
request.send(null);
}

En este ejemplo simple, getSalesData() es la función que tu página Web llama para empezar una petición (como cuando un botón es presionado). Observar que tienes que comprobar el estado READY antes de que se llame a open() . La figura 1 demuestra el resultado de ejecutar esta aplicación.

Figura 1: Un estado ready en 0

Obviamente, esto no te hace mucho de bueno; hay muy pocas veces en que necesitarás cerciorarse de que open() no se haya llamado. El único uso para este estado READY en el casi-verdadero-mundo de programación de Ajax es si haces peticiones múltiples usando el mismo objeto de XMLHttpRequest a través de funciones múltiples. En esa situación (algo inusual), puede ser que desees asegurarse de que un objeto de la petición esté en el estado sin inicializar( readyState== 0) antes de hacer nuevas peticiones. Esto esencialmente se asegura de que otra función no esté utilizando el objeto al mismo tiempo.

Cuando 0 es igual a 4
En el caso de uso donde las funciones múltiples de Javascript utilizan el mismo objeto de petición, comprobar si hay un estado READY en 0 para asegurarse de que el objeto de la peticiónno esté en uso puede resultar ser problemático. Puesto que el readyState== 4 indica una petición terminada, encontrarás a menudo los objetos depetición que no se están utilizando con su estado READY todavía fijado en 4 -- los datos del servidor fueron utilizados, pero nada ha ocurrido desde entonces para reajustar el estado READY. Hay una función que reajusta un objeto de la petición llamado abort(), pero realmente no fue pensada para este uso. Si tenes que utilizar funciones múltiples, puede ser que sea mejor crear y utilizar un objeto de petición para cada función más que compartir el objeto a través de funciones múltiples.

Ver el estado READY de una petición en curso
Aparte del estado READY en 0, tu objeto de petición debe pasar con cada uno de los otros estados READY en una petición y respuesta típica, y finalmente terminar con un estado READY de 4. Éso es cuandola línea if(request.readyState == 4) del código que ves en la mayoría de las funciones de rellamada entra; asegura que el servidor terminó y es seguro actualizar la página Web o tomar una acción basada en la información del servidor.
Es una tarea trivial realmente ver este proceso tal como ocurre. En vez de solamente de ejecutar el código en tu rellamada si el estado READY es 4, solamente muestra el estado READY cada vez que tu rellamada sea llamada. Como ejemplo del código que hace esto, comprobar el listing 3.

Listing 3. Comprobar el estado Ready

function updatePage(){
//mostrar el estado Ready actual
alert("updatePage() llamado con un estado ready en " + request.readyState);
}

Si no estás seguro de cómo conseguir este funcionamiento, necesitarás crear una función para llamar desde tu página Web y para hacer que envíe una petición a un componente del lado servidor (tal como la función que fue demostrada en el listing 2 y a través de los ejemplos en el primero y segundo artículos en esta serie). Cerciorarte de que cuando estableciste tu petición, fijaras la función de rellamada al updatePage (); para hacer esto, fijar la propiedad onreadystatechange de tu objeto petición al updatePage ().
Este código es una gran ilustración de exactamente qué significa el onreadystatechange -- el estado READY de la petición cambia cada vez, se llama el updatePage () y ves una alarma. Figura 2 demuestra un ejemplo de esta función siendo llamada, en este caso con un estado READY de 1.

Figura 2 Un estado ready en 1

Probá este código vos mismo. Ponelo en tu página Web y luego activá tu evento (presionar un botón, salir de un campo con Tab, o cualquier metodo que hayas establecido como disparador el una petición). Tu función de rellamada se va a ejecutar varias veces -- cada vez que el estado ready de la petición cambie-- y vas a ver un alerta por cada estado ready. Esta es la mejor manera de seguir una petición en cada una de sus etapas.

Traducción de Artículo de Ajax XIII

En Conclusión
Ya estarás un poco cansado del XMLHttpRequest --rara vez leo un artículo entero sobre un solo objeto, especialmente uno que es tan simple. Sin embargo, vas a usar este objeto una y otra vez en cada página y aplicación que escribas donde uses Ajax. En verdad, todavía queda algo por decir sobre XMLHttpRequest. En próximos artículos, vas a aprender a usar POST ademas de GET en tus peticiones, establecer y leer contenidos de cabeceras en tus petición así como en la respuesta del servidor; vas a entender como codificar tus peticiones y también menjar XML en tu modelo petición/respuesta.
Un poco mas adelante vas a ver también algunos de los cajas de herramientas populares que están disponibles. Estas cajas de herramientas abstraen realmente la mayor parte de los detalles discutidos en este artículo y hacen la programación de Ajax más fácil. Puede ser que incluso te preguntes porqué tenés que códificar todo este detalle de bajo nivel cuando las cajas de herramientas estan tan fácilmente disponibles. La respuesta es, él es terriblemente durodarse cuenta que está mal en tu aplicación si no entendes qué está pasando en tu aplicación.
Por eso no ignores estos detalles o pases rapidamente por ellos; cuando tu práctico-excelente caja de herramientas crea un error, te no detengas racando tu cabeza y mandando un email a la ayuda. Con una comprensión de cómo utilizar XMLHttpRequest directamente, encontrarás fácil eliminar errores y arreglar incluso los problemas más extraños. Las cajas de herramientas están muy bien a menos que cuentes con ellas para resolver todos tus problemas.
Entonces ponete con XMLHttpRequest. De hecho, si tienes en funcionamiento código de Ajax que utilice una caja de herramientas, intenta reescribirla usando solo el objeto XMLHttpRequest y sus propiedades y métodos. Será un gran ejercicio y te ayudará probablemente a entender qué está pasando mucho mejor.
En el artículo siguiente, indagarás incluso más profundo en este objeto, explorando algunas de sus características particulares (como responseXML), así como tambien cómo utilizar peticiones POST y enviar datos en diversos formatos. Entonces empezá a codificar y chequée acá en alrededor de un mes.

Traducción de Artículo de Ajax XII

Códigos de estado del HTTP
A pesar del exito aparente en el código del listing 12, todavía hay un problema -- que pasa si el servidor responde a tu petición y termina de procesar, pero reporta un error? Recuerda, el código del lado servidor debería tener en cuenta si esta siendo llamado por Ajax, JSP, un formulario HTML común, o cualquier otro tipo de código; solo tiene los métodos especificos Web tradicionales de reportar información. Y en el mundo Web, códigos HTTP pueden tratar con varias cosas que pueden pasar en una petición.
Por ejemplo, has ingresado una petición para una URL, escribis mal la URL, y recibes un código de error 404 que indica que la página está perdida. Este es uno de tantos códigos de error que una petición HTTP puede recibir como estatus (ver Recursos por un link a una lista completa de códigos de estado). 403 y 401, ambos indican información segura u prohibidaesta siendo accedida, también son comunes. En cada uno de esos casos, son códigos que resultan de una
respuesta completa. En otras palabras, el servidor completa la petición (significa que el estado ready es 4), pero es probable que no devuelva la informacion deseada por el cliente.
Además del estado ready, tambien necesitas chequear el estado HTTP. Estas buscando al código de estado 200 que simplemente significa correcto. Con un estado ready 4 y un código de estado de 200, estas listo para procesar la información del servidor y esa información debería ser lo que pediste (y no un error u otro tipo de información problemática). Agrega otro control de estado a tu método de rellamado como se muestra en el listing 14.

Listing 14. Controlar el código de estado HTTP

function updatePage() {
if (request.readyState == 4)
if (request.status == 200)
alert("Server is done!");
}

Para agregar un manejo de error más robusto --con minimas complicaciones-- deberias agregar un control o dos para otros códigos de estado; ver la version modificada de updatePage() en el listing 15.

Listing 15. Agregar algún control de error liviano.

function updatePage() {
if (request.readyState == 4)
if (request.status == 200)
alert("Server is done!");
else if (request.status == 404)
alert("Request URL does not exist");
else
alert("Error: status code is " + request.status);
}

Ahora cambiar el URL en tu getCustomerInfo() a una URL no existente y vean que pasa. Deberias ver una alerta que te diga que el URL que solicitaste no existe -- perfecto! Dificilmente vaya a controlar toda condición de error, pero en una cambio simple que cubre el 80% de los problemas que pueden ocurrir en una típica aplicación Web.

Leer el texto de respuesta
Ahora que te aseguraste de que la petición fue procesada completamente (a traves del estado ready) y el servidor te da una respuesta normal y lista (a traves de el código de estado), podes finalmente trabajar con la información devuelta por el servidor. Esta es convenientemente almacenada en la propiedad responseText del objeto XMLHttpRequest.
Detalles sobre como se ve el texto en responseText, en terminos de formato o tamaño, es intensionalmente vago. Esto permite al servidor establecer este texto a virtualmente cualquier cosa. Por ejemplo, un script puede retornar valores separados con coma, otro valores separados con pipe (el pipe es el caracter |) y otro podria retornar una larga cadena de texto. Todo está en el servidor.
En el caso del ejemplo usado en este artículo, el servidor devuelve la última orden del cliente y luego su dirección, separadas por el simbolo |. La orden y la dirección son usados para establecer los valores de elementos en el fomulario; el listing 16 muestra el código que actualiza la pantalla.

Listing 16. tratar con la respuesta del servidor.

function updatePage(){
if(request.readyState==4){
if(request.status ==200) {
var response = request.responseText.split("|");
document.getElementById("order") .value = response[0];
document.getElementById("adress").innerHTML =
response[1].replace(/\n/g,"
");
}else
alert("el estado es "+request.status);
}
}

Primero, el responseText es extraido y separado en los simbolos | usando el metodo JavaScript split(). El arreglo de valores resultante, es volcado en response. El primer valor --la última orden del cliente-- se accede en el arreglo como response[0],y es establecido como el valor del campo con un ID "orden". El segundo valor en el arreglo, en response[1] es la dirección del cliente y requiere un poco más de procesamiento. Como las lineas en la direccion están separadas por separadores de linea normales (el caracter \n), el código necesita remplazar estas con separadores de lineas estilo XHTML, <br />s. Esto se realizo a traves del uso de la funcion replace() junto con una expresion regular. Finalmente, el texto modificado se establece como el HTML interior de un div en el fomulario HTML. El resultado es que el formulario es actualizado de repente con la información del cliente, como puedes ver en la figura 4.

Antes de concluir, otra propiedad importante del XMLHttpRequest se llama responseXML. Esta propiedad contiene (podes adivinar?) una respuesta XML en el evento de donde el servidor elija responder con XML. Trabajar con una respuesta XML es un tanto distinto que trabajar con una repuesta de texto plano, e involucra análisis, el Modelo de Objetos de documento (DOM) y otras varias consideraciones. Vas a aprender más sobre XML en un artículo futuro. Además, por que responseXML comunmente aparece en discuciones alrrededor de responseText, vale la pena mencionarlo acá. Para muchas aplicaciones simples de Ajax es todo lo que necesitas, pero pronto vas a aprender a manejar XML a travez de aplicaciones Ajax también.

Traducción de Artículo de Ajax XI

Manipulación de respuestas del servidor
Hiciste tu petición, tu usuario esta trabajando felizmente en el formulario Web (mientras el servidor tranaha en la petición), y ahora el servidor termina de tratar la petición. El servidor se fija en la propiedad onreadystatechange y detecta que método llamar. Una vez que eso ocurre, podes pensar en tu aplicación como en cualquier otra, asincrónica o no. En otras palabras, no tenes que tomar ninguna acción especial escribiendo métodos que respondan al servidor; solo cambiá el formulario, enviá al usuario a otra URL o hacé lo que necesites con la respuesta del servidor. En esta sección nos centraremos en responder al servidor y luego tomar una acción típica --cambiar al vuelo parte del formulario que ve el usuario.
Rellamadas y Ajax
Ya viste como hacer saber al servidor que hacer cuando termina: fijar la propiedad onreadystatechange del objeto XMLHttpRequest al nombre de la funcion a ejecutar. Luego, cuando el servidor haya procesado la petición, va a llamar automaticamente esa función. Tampoco necesitás preocuparte de ningún parámetro para ese método. Vas a empezar con un método simple como en el Listing 12.

Listing 12. Código del método de rellamada

<script language="javascript" type="text/javascript">
var request = false;
try {
request = new XMLHttpRequest();
} catch (trymicrosoft) {
try {
request = new ActiveXObject("Msxml2.XMLHTTP");
} catch (othermicrosoft) {
try {
request = new ActiveXObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error al inicializar XMLHttpRequest!");
function getCustomerInfo() {
var phone = document.getElementById("phone").value;
var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

function updatePage() {
alert("El servidor terminó!");
}
</script>

Esto solo dispara una alerta útil, para decirte cuando termina el servidor. Prueba este código en tu propia página, guarda la página y luego tirala en un navegador (si queres XHTML de este ejemplo, ver el listing 8) cuando ingreses un número de teléfono y dejes el campo, deberías ver la ventana de alerta (ver figura 3); pero si presionás OK va a aparecer otra vez... y otras.

Figura 3: Código de Ajax mostrando una ventana de alerta

Dependiendo de su navegador, vas a tener dos, tres, o aún cuatro alarmas antes de el formulario pare de mostrar alarmas. ¿Qué se está pasando? Resulta que no has considerado el estado ready del HTTP, un componente importante del ciclo de peticion/respuesta.
Estados ready de HTTP
Antes, dije que el servidor, una vez que termina con una petición, busca qué método llamar en la propiedad onreadystatechange de XMLHttpRequest. Eso es verdad, pero no es toda la verdad. De hecho, llama a ese método cada vez que el estado READY del HTTP cambia. ¿Qué significa? Bien, tenes que entender los estados READY del HTTP primero.
Un estado READY del HTTP indica el estado o situacion de una petición. Se utiliza para reconocer si se ha comenzado una petición, si se está contestando, o si el modelo de petición/respuesta ha terminado. Es también útil en la determinación de si es seguro leer cualquier texto o datos de la respuesta que un servidor pudo haber provisto. Necesitas saber sobre los cinco estados READY en tus aplicaciones Ajax.

• 0: La petición está sin inicializar (antes de que hayas llamado a open())
• 1: La petición esta seteada, pero no ha sido enviada (antes de que hayas llamado a send())
• 2: La petición fue enviada y está siendo procesada (normalmente podes obtener el contenido cabecera de la respuesta a este punto)
• 3: La petición está siendo procesada; a menudo alguna informacion parcial de la respuesta está disponible, pero el servidor todavía no ha terminado con esa respuesta.
• 4: La respuesta está completa; podes tomar la respuesta del servidor y usarla.

Como la mayoria de los asuntos de multi-navegador, estos estados ready son usados un poco incosistentemente. Esperarias ver siempre los estados ready moverse desde 0 a 1 a 2 a 3 a 4, pero en la práctica, es raramente el caso. Algunos navegadores nunca reportan 0 o 1 y saltan directamente al 2, después al 3 y luego al 4. Otros navegadores reportan todos los estados. Ademas otros van a reportar el estado 1 varias veces. Como ves en la ultima sección, el servidor llama al updatePage() varias veces, y cada invocación resulta en una caja de alerta mostrandose --probablemente no como querías!
Para la programación Ajax, el unico estado con el que necesitas tratar es el estado ready 4, que indica que la respuesta del servidor está completa y es segura para ver la información de respuesta y usarla. A cuenta de esto, la primera línea en el método de rellamada deberia ser como se muestra en el listing 13

Listing 13. Check the ready state

function updatePage() {
if (request.readyState == 4)
alert("Server is done!");
}

Este cambio comprueba para asegurarse de que el servidor realmente haya acabado con el proceso. Intenta ejecutar esta versión del código Ajax y solamente deberías obtener el mensaje alerta una vez, que es como debe ser.