Frameworks para RIAs

En esta cuarta entrega del desarrollo basado en Ajax, nos vamos a centrar en los diferentes frameworks existentes que nos pueden ayudar en nuestros desarrollos. Si no os habéis leído los posts anteriores, os recomiendo que os los leáis para entender mejor este:

• ¿Qué es eso del AJAX?: Introducción a ajax, a su funcionamiento y al objeto XMLHttpRequest.
• AJAX para CAMPEONES o ¿Qué es eso del AJAX? (Segunda Parte): en este segundo post, nos adentramos un poco más en la implementación práctica a través de ejemplos de las llamadas asíncronas.
• AJAX PARA SUPERCAMPEONES o ¿Sabremos alguna vez qué es AJAX? (III): en la tercera entrega vimos cómo hacer múltiples llamadas de forma simultánea y cómo enlazar múltiples llamadas secuenciales.

En este post vamos a ver diferentes alternativas de las que disponemos para agilizar nuestra tarea (otra gente se ha pegado con el teclado por nosotros). Vamos a ver, aunque existen muchísimos más, los siguientes:

• YUI: Yahoo User Interface, framework de Yahoo (que listo soy) para aplicaciones ricas de internet (RIA: Rich Internet Application). Muy completo y con un montón de ejemplos y documentación.
• Dojo: Framework de la Dojo Foundation. Es también muy completo, quizás un poco más sencillo de utilizar que el de Yahoo y menos pesado para el explorador, aunque con menos documentación.
• GWT: Google Web Toolkit. Es la implementación que da Google para Ajax sobre Java. En realidad, la filosofía de GWT es la de programar en Java y él interpreta el código Java para generar las páginas con los controles AJAX.
• AJAX ASP.NET: La implementación para asp.net de AJAX. Incluye, aparte del core de librerías de comunicación una librería de controles llamada Atlas Control Toolkit. Se puede utilizar aunque no se utilice asp.net.

Todas estas librerías son de libre distribución. Por supuesto, existen muchas librerías de pago con controles flipantes que casi te programan la aplicación solas, pero los currelas de a pié, nos conformaremos con éstas (de hecho son muy buenas todas). Personalmente, la que más uso (todos los días) es la de ASP.NET, que hace cosas muy chulas. Tened en cuenta que en lo que más dan estos frameworks son controles para hacer nuestras aplicaciones más interactivas. Pero, vamos al tajo:

Yahoo User Interface:
Esta fue la primera librería que utilicé en mis pruebas. Tiene varias cosas muy buenas a tener en cuenta:

• Una documentación muy buena con unas cheatsheets muy curradas.
• Un mogollón de ejemplos con el código bien puesto.
• Muchos controles
• El respaldo de una gran empresa que soporta el proyecto (no te van a dejar tirado).

Cosas negativas que he visto y comprobado:

• Puede llegar a ser bastante pesado para el cliente (las librerías javascript)
• Es el framework más complejo con el que trabajar debido a que puedes hacer lo que quieras con él.

Este conjunto de librerías las puedes utilizar donde quieras porque son Javascript puro. De hecho, puedes mezclar diferentes librerías. ¿Os acordáis del ejemplo que puse en una de las entregas en el que se ponía el nombre y el servidor devolvía "Te devuelvo tu nombre: " y el nombre? Os acordéis o no, aquí tenéis ese mismo ejemplo pero implementado con YUI:

http://www.nidea-soluciones.com/PruebasAjax/YUI/yui1.html

El código javascript utilizado se divide en dos partes: primero tenemos que importar los scripts de YUI que vayamos a utilizar (lo miramos en su web para saberlo) y después realizamos nuestros propios scritps:







Los scripts a importar dependerán de qué es lo que vamos a utilizar de la librería de controles de Yahoo. En la página web se indica para cada caso cuáles son necesarios. La parte de programación es la siguiente:
















El meollo se encuentra en la línea YAHOO.util.Connect.AsyncRequest() que es la que crea el objeto XMLHttpRequest y realiza la llamada. Se le pasa el método, la url y una variable que contiene toda la información relativa a la función si va todo bien, la función si no va bien, los argumentos, etc. Es muy importante el orden, no podemos definir la variable callback antes de las funciones que manejarán las respuestas, ni podemos definir la variable callback después de la llamada al servidor.

Utilizamos también uno de los controles de YUI, el container en su versión panel. La programación con YUI se puede realizar de dos maneras distintas, por marcación o por Javascript. Todos los controles se pueden definir directamente en Javascript (caso del ejemplo) o definir en HTML (Markup). Al definir por HTML, cuando se llama al método render, la librería busca determinadas clases css y las convierte en controles. El mismo panel que se define en el ejemplo con HTML sería:











La librería lee las clases y las renderiza en pantalla en forma de panel.

Framework Dojo:
Este es el siguiente framework con el que trabajé. Tiene otras ventajas e inconvenientes que el YUI. Los que encontré fueron los siguientes:

Cosas buenas:

• Un montón de controles
• Definición en la programación más intuitiva que la de YUI.
• Menos importaciones a nuestras páginas

Cosas malas:

• La documentación es mucho peor.
• Existen menos ejemplos en la utilización de los diferentes controles.

Veamos un ejemplo. Os he puesto el mismo ejemplo que con YUI pero programado con Dojo. Lo podéis ver en:

http://www.nidea-soluciones.com/PruebasAjax/Dojo/dojo1.html

El estilo de programación varía ligeramente entre ambos frameworks. En ambos disponemos de una parte de inicialización de dependencias que en el caso de YUI es mediante la incorporación de scripts y mediante Dojo se realiza más al estilo Java o C#:







Lo primero es importar la librería base dojo.js y después utilizamos la sentencia para importar aquellas partes que vayamos a utilizar. Podemos utilizar una sintaxis del tipo dojo.require() dojo.require("dojo.widget.*"); para importar todos los widgets. En este caso, como sólo vamos a utilizar el tipo Dialog pues lo importamos. La sentencia djConfig = {isDebug:true}; nos permite sacar mensajes de debug o de error en la librería por pantalla.

Dojo se diferencia de YUI en que al definir los elementos HTML, introducimos un nuevo parámetro llamado dojotype en el que le indicamos qué tipo de elemento dojo va a ser. De esta forma al inicializar el elemento en Javascript, la mayoría de la definición se encuentra en el elemento HTML. Vayamos por pasos: paso 1, el código HTML:
























En el código definimos tres divs a los que les decimos que son dojotype="dialog". De esta forma, Dojo sabe que tiene que renderizarlos como diálogos. Además les definimos una serie de características propias de Dojo (las subrayadas en rojo): bgcolor(color de fondo de la pantalla no del div), bgOpacity(opacidad del fondo de la pantalla), toogle (forma en la que aparece o desaparece la pantalla) y toogleDuration (duración del efecto de aparecer y desaparecer).

El resto del código es html normal. Veamos cómo se definen los diálogos y las funciones (ved que llamo a dos funciones Javascript CargarNombre() y Empezar()).
























He dividido el Javascript en trozos. En la primera parte tenemos las definiciones de las variables que vamos a utilizar después, los tres diálogos, y las dos funciones manejadoras de los eventos de respuesta correcta y respuesta incorrecta, hasta aquí todo igual que antes. Tenemos también la función init, que se ejecuta al cargar la página que define el primer diálogo que aparece en pantalla. La definición es muy simple, solamente utilizamos la sentencia dojo.widget.byId() y le pasamos el id del div que va a ser el diálogo (ese div tiene que tener el dojotype="dialog"). Le definimos el botón que va a ocultar el diálogo con la sentencia setCloseControl(). Ved que podemos utilizar con los diálogos las sentencias show() y hide() para mostrarlos u ocultarlos desde cualquier parte del código. ¿Y las llamadas a servidor cómo se hacen? Pues veamos el resto del código:
















Tenemos la función CargarNombre() que muestra el diálogo de espera y llama al servidor. Con Dojo, las llamadas se realizan utilizando el método dojo.io.bind al que le pasamos parámetros. Los más comunes y necesarios (algunos) son: url (dirección a la que llamar), load (método que controlará la respuesta correcta del servidor), error (método que manejará la respuesta de error del servidor), mimetype (mimetype de los datos de la llamada).

Dojo también permite realizar llamadas cross-domain mediante el método bind(), pero hay que importar el espacio dojo.require("dojo.io.XhrIframeProxy"), proque la llamada se realiza mediante un iFrame Proxy. Esto está aún en pruebas así que os aconsejo que vayáis a la documentación y os lo leáis.


Conclusión (hasta la próxima):
Como se me está haciendo demasiado largo el post, dejaremos los dos frameworks restantes para el siguiente. Sólo comentaros mi experiencia con ambos: personalmente prefiero el framework de Dojo que es bastante más intuitivo de utilizar, aunque YUI tenga más documentación (es realmente buena), cuando empiezas a trabajar con Dojo y te empiezas a enterar de cómo funciona, es más liviano. De todas formas, al ser frameworks completamente independientes de plataformas, siempre podéis conjugarlos y utilizar aquellas partes que más os gusten de uno y de otro.

Proximamente: GWT y ASP.NET AJAX