El motor AJAX - parte II

AJAX un nuevo acercamiento a las aplicaciones Web.

¿Que es AJAX?

AJAX es el acronimo ingles para Asynchronous JavaScript and XML (JavaScript y XML asincrono). Es una tecnica de desarrollo web que genera aplicaciones web interactivas combinando:

* Document Object Model (DOM) para visualizar dinamicamente e interactuar con la informacion presentada.

* XML, XSLT para intercambiar y manipular datos.

* CSS para definir el aspecto (look and feel) del documento.

* JSON y JSON-RPC pueden ser alternativas a XML/XSLT

* XMLHttpRequest para recuperar datos de forma asincronica.

* Javascript como nexo de union de todas estas tecnologias.

AJAX es un patron de diseño que propone un nuevo modelo de interaccion Web combinando las tecnologias anteriores.

¿Por que AJAX?

Las aplicaciones web proliferan debido a su simplicidad, pero ofrecen una menor interactividad y usabilidad en comparacion con las aplicaciones de escritorio, debido a que la interaccion del usuario con una aplicacion web se interrumpe cada vez que se necesita algo del servidor.

Varias tecnologias han sido diseñadas para resolver este problema, Java Applets, FLASH, AJAX es una nueva solucion que no requiere plugins o capacidades especificas de ciertos navegadores.

DHTML y AJAX, ¿lo mismo?

DHTML (Dynamic HTML) tecnica de desarrollo de webs interactivas combinando HTML, client-side scripting con JavaScript y el lenguaje de definicion de estilos CSS. Realmente AJAX es un refinamiento de DHTML y al igual que en AJAX el principal problema de DHTML es el diferente soporte de estas tecnologias en los navegadores y los diferentes tamaños o resoluciones de pantalla de usuarios.

Como el DHTML o LAMP, AJAX no constituye una tecnologia en si, por eso carece de un entorno de desarrollo propio, pero es un termino que engloba a un grupo de estas que trabajan conjuntamente.

El hecho de que el intercambio de datos se realice de forma asincrona sirve para hacer que las aplicaciones Web funcionen de una manera casi transparente al usuario en terminos de comunicacion con el servidor.

El resultado es una interfase con mayor respuesta, dado que la cantidad de datos intercambiados entre el navegador web y el servidor web es reducida enormemente. Tambien se ahorra mucho tiempo de procesamiento en el servidor web, ya que una parte importante de dicho procesamiento se realiza en el lado del cliente.
Caracteristicas AJAX

* Las aplicaciones son mas interactivas, responden a las interacciones del usuario mas rapidamente, al estilo aplicaciones de escritorio.

* Estas aplicaciones tienen un aspecto (look and feel) muy similar a las aplicaciones de escritorio tradicionales sin depender de plugins o caracteristicas especificas de los navegadores.

* Se reduce el tamaño de la informacion intercambiada

o Muchas micro-peticiones, pero el flujo de datos global es inferior

* Se libera de procesamiento a la parte servidora (se realiza en la parte cliente)

* AJAX actualiza porciones de la pagina en vez de la pagina completa.

AJAX contra aplicaciones Web tradicionales

En las aplicaciones Web tradicionales los usuarios interactuan mediante formularios, que al enviarse, realizan una peticion al servidor Web. El servidor se comporta segun lo enviado en el formulario y contesta enviando una nueva pagina Web. Se desperdicia mucho ancho de banda, ya que gran parte del HTML enviado en la segunda pagina Web, ya estaba presente en la primera. Ademas, de esta manera no es posible crear aplicaciones con un grado de interaccion similar al de las aplicaciones habituales.

Ademas en este tipo de aplicaciones Web tradicionales mientras el servidor esta haciendo lo suyo, ¿que esta haciendo el usuario? Exacto, esperando. Y, en cada paso de la tarea, el usuario espera por mas. Obviamente, si estuvieramos diseñando la Web desde cero para aplicaciones, no querriamos hacer esperar a los usuarios. Una vez que la interfaz esta cargada, ¿por que la interaccion del usuario deberia detenerse cada vez que la aplicacion necesita algo del servidor? De hecho, ¿por que deberia el usuario ver la aplicacion yendo al servidor?

En aplicaciones AJAX se envian peticiones via http(s) mediante eventos, scripts o rutinas al servidor Web, para obtener unicamente la informacion necesaria, empleando SOAP o algun otro lenguaje para servicios Web basado en XML, y usando JavaScript en el cliente para procesar la respuesta del servidor Web. Esto redunda en una mayor interaccion gracias a la reduccion de informacion intercambiada entre servidor y cliente, y a que parte del proceso de la informacion se hace en el propio cliente, liberando al servidor de ese trabajo. Ademas esta peticion se realiza como proceso de fondo (background), por lo que el usuario no tiene que esperar que el proceso concluya en su totalidad para continuar interactuando con la aplicacion. La contrapartida es que la descarga inicial de la pagina es mas lenta al tenerse que bajar todo el codigo JavaScript.

En el modelo clasico, cada vez que queremos cargar una nueva pagina Web con nuevos datos, hemos de enviar una peticion al servidor Web, y este nos devuelve la pagina entera, que incluye tanto los datos a mostrar como la presentacion de la misma.

Sin embargo utilizando el modelo AJAX, cuando queremos cargar datos nuevos lo que hacemos en enviar una peticion HTTP al servidor Web que nos devuelve unicamente los datos a mostrar (en formato XML), no la presentacion de la pagina. Con este sistema lo que conseguimos es reducir el volumen de trafico entre cliente y servidor, y tambien conseguimos que no se tengan que cargar paginas HTML enteras cada vez que queremos representar nuevos datos.
¿Por que AJAX es diferente?

Una aplicacion AJAX elimina esas paradas en la ejecucion introduciendo un intermediario (el motor AJAX) entre el usuario y el servidor. Pareceria que añadir una capa a la aplicacion le conferiria una peor respuesta, pero en realidad ocurre lo contrario.

En lugar de cargar una pagina Web, al iniciar la sesion, lo que hace el navegador es cargar el motor AJAX (escrito en JavaScript y normalmente escondido en un marco oculto).
El motor AJAX

El motor AJAX (AJAX engine) colocado entre el usuario y el servidor web evita el ciclo start-stop-start-stop caracteristico de las aplicaciones web tradicionales y no es mas que un fichero JavaScript que acompaña al HTML. El cual es cargado al inicio de la sesion y tiene una doble responsabilidad, primero generar la interfaz visualizada por el usuario y segundo comunicarse con el servidor en representacion del usuario, lo cual ocurre de manera asincrona evitando que el usuario vea una pagina blanca o el reloj de arena (de espera) cada vez que realice una accion.

Toda accion del usuario que normalmente generaria una peticion HTTP, adquiere la forma de una llamada JavaScript al motor AJAX. Cualquier accion del usuario que no requiera un viaje al servidor (tales como validacion de datos, edicion de datos en memoria e incluso la propia navegacion) es procesada por el mismo. Si el motor necesita algun tipo de proceso en el servidor para generar la respuesta (enviar datos para procesamiento, carga de codigo de interfaz adicional o peticion de datos nuevos) realiza las peticiones de manera asincrona, normalmente usando el objeto XMLHttpRequest, sin detener la interaccion del usuario con la aplicacion.
Mirando adelante

Los mayores desafios al crear aplicaciones AJAX no son tecnicas. Las tecnologias centrales son maduras, estables y bien conocidas. En cambio, los desafios son para los diseñadores de estas aplicaciones: olvidar lo que creemos saber sobre las limitaciones de la Web, y comenzar a imaginar un rango mas amplio y rico de posibilidades.
Seguridad en AJAX

Por motivos de seguridad las invocaciones a recursos via HTTP solamente pueden efectuarse a paginas alojadas en el mismo dominio que el de la pagina que contenia el script. Si queremos que la informacion de nuestras peticiones no sea visible deberemos utilizar un canal HTTPS.
Nuestra primera aplicacion AJAX

Vamos a considerar una aplicacion web con un formulario que requiere validacion en el servidor sin necesidad de refrescar la pagina completamente. Es decir, realizar un HTTP POST de la pagina implicitamente.

Los flujos de control serian:

1. Un evento ocurre

2. Un objeto XMLHttpRequest es creado e inicializado

3. Se realiza una invocacion remota a traves del objeto XMLHttpRequest

4. La peticion es procesada por el servidor el cual devuelve un documento XML con el resultado.

5. El objeto XMLHttpRequest invoca la funcion callback() y procesa el resultado.

6. El arbol DOM de la pagina web es actualizado.

Un evento ocurre

Como resultados de eventos generados por la interaccion del usuario funciones JavaScript son invocadas.

Ejemplo: <input type=”text” id=”userID” onkeyup=”validate();”>

Creando el objeto XMLHTTPREQUEST

Hacer dos funciones genericas es la mejor idea para este modelo. Y usando try y catch podemos hacer una funcion cross-browser:

function simple_ajax(){

var xmlhttp=false;

try{

xmlhttp = new ActiveXObject(”Msxml2.XMLHTTP”);

} catch (e) {

try {

xmlhttp = new ActiveXObject(”Microsoft.XMLHTTP”);

} catch (E) {

xmlhttp = false;

}

}

if (!xmlhttp && typeof XMLHttpRequest != ‘undefined’) {

xmlhttp = new XMLHttpRequest();

}

return xmlhttp;

}

function LoadContent(callback, url, method, query_string){

ajax=simple_ajax();

if (method == ‘GET’) {

ajax.open(method, url +”?” + query_string, false);

} else {

ajax.open(method, url, false);

}

ajax.onreadystatechange=function() {

if (ajax.readyState==4) {

if (req.status == 200) {

callback (ajax.responseText, ajax.responseXML);

}

}

}

if (method == ‘GET’) {

ajax.send(null)

} else {

ajax.setRequestHeader(’Content-Type’, ‘application/x-www-form-urlencoded; charset=ISO-8859-1′);

ajax.send(query_string);

}

}

Listo con estas dos funciones lograremos hacer casi cualquier aplicacion web usando AJAX. Volviendo a nuestro ejemplo, el campo userID (input tipo texto), hace referencia a la rutina validate(), pues definamos esta funcion:

function validate (){

obj_userID = document.getElementById(”userID”);

qs = “userID=” obj_userID.value;

LoadContent(mostarMsg, “validar.php”, “POST”, qs);

}

function mostarMsg (pText, pXml){

var userMessageElement = document.getElementById(”userIdMessage”);

userMessageElement.innerHTML = pText;

}

Esta ultima funcion supone la existencia de un elemento (div, p, td, etc) con id=userIdMessage.

Por ultimo debemos crear el archivo validar.php en el cual se coge el parametro userID que esta contenido en la variable global $_POST["userID"] (esto es porque el metodo que se utilizo para enviar los datos fue el POST), y se procesa la informacion, es decir se verifica si el valor es valido o no, esto puede ser verificar si el valor userID es un id valido almacenado en una base de datos, y segun sea el caso emitir una respuesta, que puede ser imprimir el mensaje “valido” o “invalido”.
Referencias

* XMLHttpRequest – http://developer.apple.com/internet/webcontent/xmlhttpreq.html
* Asynchronous JavaScript Technology and XML (AJAX) With Java 2 Platform, Enterprise Edition http://java.sun.com/developer/technicalArticles/J2EE/AJAX
* AJAX gives software a fresh look – http://news.com.com/AJAX+gives+software+a+fresh+look/2100-1007_3-5886709.html?tag=st.prev
* HTML DOM – http://www.w3schools.com/htmldom
* Javascript – http://en.wikipedia.org/wiki/Javascript
* Core JavaScript Reference – http://research.nihonsoft.org/javascript/CoreReferenceJS15/index.html
* AJAX for Java developers: Build dynamic Java applications – http://www-128.ibm.com/developerworks/library/j-AJAX1/?ca=dgr-lnxw01AJAX
* JavaScript XSLT – http://www.soi.city.ac.uk/~sa386/epterm2/sqlxml/week9/The%20XSLT-JavaScript%20Interface%20In%20Gecko.htm
* Web 2.0 http://www.web2con.com

El motor AJAX - parte I

Resumen

AJAX parece ser la palabra de moda en el “mundo” de desarrollo de aplicaciones Web. Pero debe quedar claro que en realidad AJAX no es una tecnologia; AJAX es una tecnica, es la union de varias tecnologias, tales como: DOM, XML, XSLT, CSS, XMLHttpRequest, JavaScript entre otras, para lograr cosas realmente impresionantes, como GoogleMaps, Gmail el Outlook Web Access entre otras aplicaciones Web.
Introduccion

Los diseñadores de sitios Web no pueden evitar sentirse envidiosos de nuestros colegas que crean software de escritorio. Las aplicaciones de escritorio tienen una riqueza y respuesta que parecia fuera del alcance en Internet. De ahi que uno de los objetivos de introducir AJAX en nuestras aplicaciones Web, es simular o acercarnos a las aplicaciones de escritorio.
Historia de AJAX

A pesar de que el termino “AJAX” fuese creado en 2005, la historia de las tecnologias que permiten AJAX se remonta a una decada antes con la iniciativa de Microsoft en el desarrollo de Scripting Remoto. Sin embargo, las tecnicas para la carga asincrona de contenidos en una pagina existente desde la introduccion del elemento iframe en Internet Explorer 3 en 1996 y el tipo de elemento layer en Netscape 4 en 1997, abandonado durante las primeras etapas de desarrollo de Mozilla. Ambos tipos de elemento tenian el atributo src que podia tomar cualquier direccion URL externa, y cargando una pagina que contenga javascript que manipule la pagina paterna, pudiendo lograrse efectos parecidos al AJAX.

El Microsoft’s Remote Scripting (o MSRS, introducido en 1998) resulto un sustituto mas elegante para estas tecnicas, con envio de datos a traves de un applet Java el cual se puede comunicar con el cliente usando JavaScript. Esta tecnica funciono en ambos navegadores, Internet Explorer version 4 y Netscape Navigator version 4. Microsoft la utilizo en el Outlook Web Access provisto con la version 2000 de Microsoft Exchange Server.

La comunidad de desarrolladores Web, primero colaborando por medio del grupo de noticias microsoft.public.scripting.remote y despues usando blogs, desarrollaron una gama de tecnicas de scripting remoto para conseguir los mismos resultados en diferentes navegadores. Los primeros ejemplos incluyen la libreria JSRS en el año 2000, la introduccion a la tecnica imagen/cookie en el mismo año y la tecnica JavaScript bajo demanda (JavaScript on Demand) en 2002. En ese año, se realizo una modificacion por parte de la comunidad de usuarios al Microsoft’s Remote Scripting para reemplazar el applet Java por XMLHttpRequest.

Frameworks de Scripting Remoto como el ARSCIF aparecieron en 2003 poco antes de que Microsoft introdujera Callbacks en ASP.NET.

Desde que XMLHttpRequest esta implementado en la mayoria de los navegadores, raramente se usan tecnicas alternativas. Sin embargo, todavia se utilizan donde se requiere una mayor compatibilidad, una reducida implementacion, o acceso cruzado entre sitios web. Una alternativa, el Terminal SVG (basado en SVG), emplea una conexion persistente para el intercambio continuo entre el navegador y el servidor.
Navegadores que permiten AJAX

Debe tenerse en cuenta que esta es una lista general, y el soporte de las aplicaciones AJAX dependera de las caracteristicas que el navegador permita.

* Navegadores basados en Gecko como Mozilla, Mozilla Firefox, SeaMonkey, Camino, Flock, Epiphany, Galeon y Netscape version 7.1 y superiores

* Microsoft Internet Explorer para Windows version 5.0 y superiores, y los navegadores basados en el

* Navegadores con el API KHTML version 3.2 y superiores implementado, incluyendo Konqueror version 3.2 y superiores, Apple Safari version 1.2 y superiores, y el Web Browser for S60 de Nokia tercera generacion y posteriores

* Opera version 8.0 y superiores, incluyendo Opera Mobile Browser version 8.0 y superiores

Navegadores que no permiten AJAX

* Opera 7 y anteriores

* Microsoft Internet Explorer para Windows version 4.0 y anteriores

* Microsoft Internet Explorer para Macintosh, todas las versiones

* Dillo

* Navegadores basados en texto como Lynx y Links

* Navegadores para incapacitados visuales (braille)