Ajax: Solución a 5 problemas.

Hola amigos taringueros, hoy queria darles este post donde habla de AJAX Primero lo primero ¿Que es A.J.A.X? Y ¿Para que sirve? En Techlosofy siempre hablamos de aplicaciones Web y en algunas ocasiones mencionamos algo llamado "Ajax", pero algunos lo confundirán con una marca de detergente o un equipo de futbol, pero no lo es o por lo menos en la parte de desarrollo Web no. Antes de entrar ha hablar sobre AJAX se definirá en primera instancia ¿Qué es?, y ¿Para qué sirve?. AJAX es la unión de varias tecnologías de desarrollo Web que buscan crear aplicaciones interactivas. AJAX por sus siglas en ingles significa Asynchronous JavaScript And XML (JavaScript asíncrono y XML) y la importancia de ésta técnica está en que al utilizarla, ésta se ejecuta en el lado del cliente – es decir el navegador Web-, pero por debajo mantiene una comunicación asíncrona con el servidor. Con ésta asincronía utilizando XML, cuando se desee hacer algún cambio en el desarrollo Web, no será necesario que la página se recargue nuevamente; lo que en últimas se traduce en aplicaciones mucho más interactivas, rápidas y veloces y eficientes. A continuación una gráfica que ilustrará mejor el modelos de aplicación Web básico, comparado con el modelo de “moda” AJAX. El desarrollador web moderno que no tiene en cuenta el Ajax en la planificación o la construcción de sus páginas web, está perdiéndose de una poderosa herramienta para mejorar la usabilidad. Sin embargo, existen desafíos en la aplicación de de AJAX en una página web. En esta nota vamos a analizar las soluciones a cinco de los retos más comunes que un desarrollador se enfrenta cuando utiliza Ajax para mejorar el contenido de su sitio web. Problema # 1: El contenido no es compatible con versiones anteriores Este problema se produce cuando un diseñador ha incorporado mejoras en JavaScript y Ajax en la arquitectura de su sitio web sin establecer disposiciones para los navegadores que tienen deshabilitado JavaScript. No hay nada malo con la planificación de un sitio Web con JavaScript y Ajax, de hecho, en el mercado actual, las consideraciones JavaScript deberían ser parte integral del proceso de planificación. Pero aún te debes asegurar de que el sitio es compatible con versiones anteriores al iniciarse. Solución: Implementar Ajax como una mejora de un sitio ya en funcionamiento Mientras que el Ajax puede ser parte integral de la planificación de la arquitectura del sitio web, asegúrate de que todo el contenido es accesible a través de métodos convencionales del lado del servidor. Digamos que tienes una página de "Información del empleado" que tiene un enlace separado para cada empleado. El uso de tecnología del lado del servidor, puedes mostrar el contenido de un empleado en particular sobre la base de un valor pasado a través del string de consulta, como éste: 1-John Doe - CEO 2-Frank Smith - Vice President 3-Jim Williams - Accountant Todos los enlaces anteriores apuntan a la misma página, la página "Empleados", que cambia de acuerdo a la variable del string de consulta. La información de cada empleado se puede cargar desde el servidor, lo que puede hacerse de varias maneras: a través de inclusiones del lado del servidor, a través de una base de datos, o incluso usando XML. Cualquiera que sea el enlace de empleados en que se hace clic, la página completa tendría que cargar para que la información solicitada sea entregada. Así, el contenido es totalmente accesible antes de que las mejoras Ajax se coloquen en la parte superior. Luego, usando JavaScript, la actualización de la página completa puede ser interrumpida y el contenido cargado a través de Ajax. El link sobre el que se hace clic puede ser identificado por un ID o por la comprobación del valor del atributo href en el anchor. Aunque el contenido es totalmente accesible con JavaScript desactivado, la mayoría de los usuarios verán la versión AJAX mejorada. El principio de la mejora progresiva de Ajax es bien conocido, ya que se utiliza comúnmente para técnicas de JavaScript no obstrusivo y es inherente en CSS. Por lo tanto, es mejor construir tu sitio web para trabajar sin JavaScript, y luego añadir JavaScript como un accesorio, tal como lo harías con el código de tu HTML y luego lo mejoras con CSS. Problema # 2: El indicador de carga del navegador no se desencadena por peticiones Ajax. Casi todos los navegadores tienen una manera de indicar visualmente al usuario que el contenido se está cargando. En los navegadores actuales, el indicador aparece en la pestaña que está cargando el contenido. Las imágenes siguientes muestran el indicador animado de algunos navegadores populares. El indicador de carga de Internet Explorer es un círculo sólido con un gradiente que gira mientras se carga el contenido Firefox muestra un ícono similar de pequeños círculos gira en diferentes tonos de gris. Google Chrome rueda un medio círculo. El problema es que las peticiones Ajax no activan este indicador de carga en los navegadores. Solución: Inserta un indicador similar cerca del contenido que está cargando La solución común a esto es incorporar un indicador de progreso personalizado en la petición Ajax. Un número de sitios web ofrecen gratis gráficos de "carga Ajax". Preloaders.net tiene un gran número de elegantes y personalizables gráficos animados para escoger. En esta nota te damos, además, consejos para hacer atractivos visualmente estos tiempos de carga » La aplicación de este gráfico de carga personalizado, o indicador de progreso, en la funcionalidad Ajax de tu sitio es simplemente una cuestión de mostrarlo y ocultarlo en el momento adecuado a través de JavaScript. Tu código de Ajax incluye líneas de código que indicará si la solicitud está en curso o ha finalizado. Utilizando JavaScript, puedes mostrar el gráfico animado mientras que la petición está siendo procesada y esconderlo cuando la acción se ha completado. Problema # 3: El usuario no sabe que una petición Ajax ha finalizado Esto se relaciona con el problema anterior, pero a menudo es pasado por alto, debido a que el desarrollador podría suponer que la desaparición del indicador de carga es suficiente para informar al usuario que el contenido está completamente cargado. Pero en la mayoría de los casos, indicar definitivamente que el contenido se ha actualizado o renovado es lo mejor. Solución: Utiliza un mensaje distintivo de "Solicitud completada" Esto se puede hacer de forma similar a como se confirman los envíos de formularios. Después de que un vínculo ha sido presentado en Digg, la página te permite saber con toda claridad que su presentación se ha recibido: Aunque este indicador no señala que una petición Ajax haya terminado, el principio es el mismo: la baja de "éxito" aparece después de que la página que envía el formulario ha terminado de cargar, y la caja es de colores y distintiva. Un gráfico similar o indicador podría utilizarse al final de una petición Ajax para indicar a los usuarios que el contenido se ha actualizado. Esto se aplicará en adición a, no en lugar de, el indicador de progreso para el problema anterior Problema # 4: Las solicitudes AJAX no pueden tener acceso a servicios web de terceros El objeto XMLHttpRequest, que está en la raíz de todas las peticiones Ajax, se limita a hacer peticiones en el mismo dominio que la página de la petición. Pero hay casos en los que se desea tener acceso a datos de terceros a través de una petición Ajax. Muchos servicios web hacen que sus datos sean accesibles a través de una API. Solución: usar el servidor como un proxy. La solución a este problema es utilizar el servidor como un proxy entre el servicio de terceros y el navegador. Aunque los detalles de esta solución van mucho más allá del alcance de este artículo, vamos a repasar el principio fundamental en el trabajo. Debido a que una petición Ajax se origina en el navegador del cliente, se debe hacer referencia a un archivo en otro lugar, pero en el mismo dominio que el origen de la petición. Tu servidor, sin embargo, a diferencia de el navegador del cliente, no se limita de esta manera. Así que, cuando se llama a la página de tu servidor, se ejecuta en segundo plano como lo haría normalmente, pero con acceso a cualquier dominio. Esto no presenta ningún riesgo de seguridad para el usuario debido a que las peticiones al servicio de terceros se hacen en el servidor. Así que, una vez que la información se ha obtenido a nivel de servidor, el siguiente paso en la llamada Ajax es enviar una respuesta al cliente, que en este caso incluirá los datos obtenidos del servicio de terceros web. Problema # 5: Enlaces no disponibles Este es un tema complicado, pero puede no ser necesario dependiendo de tu tipo de sitio web o aplicación. El problema se produce cuando el contenido se carga a través de Ajax y luego el "estado" de la página web se cambia sin que la dirección URL que apunta a esa página se vea afectada. Si el usuario vuelve a la página a través de un marcador o comparte el vínculo con un amigo, el contenido actualizado no se mostrará de forma automática. El sitio web, en su lugar, volverá a su estado original. Los sitios web Flash solían tener el mismo problema: no permitían que los usuarios hagan enlace a otra cosa que no fuera la pantalla inicial. Solución: Utiliza anchors de páginas internos Para garantizar que un determinado "estado" en un sitio basado en Ajax sea enlazable y bookmarkable, puedes utilizar enlaces internos, que modifican la dirección URL, pero no recargan la página o afectan a su posición vertical. Este código simple demuestra cómo se hace esto: 1-var currentAnchor = document.location; 2- currentAnchor = String(currentAnchor); 3-currentAnchor = currentAnchor.split("#" ) ; 4- if (currentAnchor.length> 1) { 5- currentAnchor = currentAnchor[1]; } 6-} 7- else { 8-currentAnchor = currentAnchor[0]; 9- } switch(currentAnchor) { 10- case "section1": 11-case "section2": 12-case "section3": 13-default: // load content for section 1 break; 14-} Lo anterior no es una porción de código funcional, sino más bien un ejemplo teórico para demostrar los pasos principales. Las dos primeras líneas de código establecen la ubicación actual de la página (URL) en una variable. Entonces, la ubicación se convierte en un string de forma que podamos manipularla. A continuación, "dividimos" el string en dos partes a través del símbolo de anchor (#) y, posteriormente, verificamos si la matriz que se crea a partir de la división es mayor que un elemento. Mayor que un elemento significa que la dirección tiene un anchor. Si la dirección URL tiene una sola parte, esto significa que no hay un anchor presente. La posterior declaración de "switch" carga el contenido de acuerdo con el valor del anchor. La sentencia switch tiene una opción por defecto en caso de que no esté presente el anchor, que sería lo mismo que cargar la página en su estado original. Además, se aplicaría el código para tratar con enlaces que apuntan directamente al contenido específico a través de los anchors internos. Un enlace que apunta a "contenido2" cargaría el contenido de "contenido2", y el string "#contenido2" se adjuntaría a la dirección actual. Esto cambiaría la dirección mediante la adición de un anchor interior, sin cambiar la vista de la página, pero conservando un identificador que indica el estado deseado de la página. Esta explicación es sólo teoría. Sin embargo, el concepto funciona, y funciona muy bien.