Este es un ejemplo para lanzar un reporte JasperReports con una aplicación Air utilizando el proyecto Merapi (AIR’s Java Bridge).

Encontrareis el ejemplo en este link, en el  .zip  encontrareis los dos proyectos, para probar-lo solo hay que ejecutar el airReports.java y el aiReports.mxml.

Nos complace presentar un nuevo producto para nuestra sección de Casos de Uso. Se trata de GeoStratum 2.0, un nuevo producto RIA de ultimísima generación basado en Flex y Java y construido sobre la plataforma avanzada de producción RIA llamada RIAlity. Ambos productos, GeoStratum y RIAlity son obra de Codeoscopic.

GeoStratum es un sistema de información basado en un visor cartográfico sobre el que podemos desarrollar diferentes aplicaciones basadas en visualización georeferenciada.

La usabilidad de una aplicación de estas características alcanza niveles excelentes gracias a la sencillez de navegación, basada principalmente en clicks y movimientos del ratón, en contraposición a los típicos formularios de las aplicaciones de gestión tradicionales y la exposición de la información de foma espacial sobre localizaciones geográficas en vez de las tablas de datos normales en estos casos.

Este es sin duda un buen ejemplo de aplicación RIA, desarrollada sobre Flex y JEE, por uno de los equipos de producción de Codeoscopic. El concepto principal detrás del producto es el poder extender la base GIS para añadir información propia de un negocio concreto. En ese aspecto, GeoStratrum 2.0 es la herramienta apropiada para gestionar infraestructuras de suministro (agua, electricidad, etc), planes urbanísticos, líneas de transporte (metro, autobus,...), servicios de logística, polígonos industriales, parques naturales, etc...

Este es un sencillo ejemplo para llamar un servlet desde flex, el proyecto lo he creado con un Eclipse java-jee combinado con el plugin del Flex Builder 3.

Para importar el proyecto, en el Flex Builder  hay que selccionar File/Import/Flex Project y selccionar este fichero.

Ya es por todos muy conocido la excelente integración que existe entre las tecnologías Java/Flex.

Generalmente, apreciamos la tecnología Flex en aplicaciones de poco utilización, o utilización complementaria, en forma de multimedia interactivas asociadas a páginas web o aplicaciones enfocadas a tareas pequeñas, como configurar un producto X, o un buscador de propiedades, etc.

Aún y cuando la tecnología Flex tiene infinidad de posibilidades, pocas veces la podemos observar en aplicaciones robustas, que requieran de un uso diario y periódico por parte de sus usuarios y con grandes volúmenes de datos, tablas y objetos, como sí visualizamos aplicaciones Swing o Web.

Hace aproximadamente 1.5 años nos embarcamos en la aventura de desarrollar una aplicación tipo ERP llamada KINETIK-ERP, sobre arquitecturas Java/Flex, y hasta el momento la combinación de ambas tecnologías ha sido todo un éxito, tanto en la parte técnica, como en la parte funcional y de usabilidad, ambas tecnologías se han integrado de una forma completamente natural.

En el inicio de este proyecto, valoramos varias tecnologías para realizar la parte Cliente, entre estas se encontraban OpenLaszlo, Flex y Swing. Luego de varias pruebas y analizar el ambiente particular de cada tecnología, descartamos OpenLaszlo y Swing. En general, OpenLaszlo en ese momento estaba muy verde y aún cuando sé que muchos amantes de Swing puedan decir lo contrario, Swing no termina de parecerme una tecnología de arquitectura muy pesada y rígida en muchos sentidos.

Actualmente, KINETIK-ERP consta de más 16000 líneas java y más de 5000 líneas Flex. La arquitectura de la aplicación en la parte servidor consta de las tecnologías Java/Spring/Hibernate/Acegi/JasperReports y GraniteDS. En la parte de cliente, la aplicación esta implementada sobre Flex/Cairngorm/Modules, más innumerables clases que hemos desarrollo de nuestra parte.

Durante este proceso, nuestro aprendizaje ha sido constante, y hemos tenido que ir solucionando algunos baches de integración entre ambas tecnologías, que no se encuentran completamente satisfechos a la actualidad, pero en general nuestra experiencia ha sido muy positiva.

Algunos problemas de integración que hemos ido solucionando son:

• Integración, manejo y vencimiento de la sesión Web.
• Optimizaciones de comunicación entre plataformas.
• Integración de Flex con JasperReports.
• Reportes Dinámicos.

En resumen y basado en nuestra experiencia, les recomiendo el uso e integración de ambas tecnologías.

A continuación un link de nuestra aplicación con el fin que puedan observar nuestro trabajo.

KINETIK - ERP.

En según qué ocasiones podemos requerir que nuestra aplicación ejecute una serie de Commands de forma asíncrona siguiendo un órden determinado.
Cairngorm viene de serie con la capacidad de encadenar Commands asíncronamente. La clase com.adobe.cairngorm.commands.SequenceCommand es la que se ocupa de que esto sea posible.
En esta entrada veremos dos formas de implementar el secuenciado. Una de forma estática y la otra de forma dinámica.

Encadenado estático

De forma nativa Cairngorm soporta encadenado estático de Commands, esto significa que para una secuencia dada deberemos crear una serie de Commands exclusiva para ésta.
El principal problema que se nos puede plantear en este caso es que si queremos reutilizar un Command que ya forma parte de una secuencia no podremos. Nos veremos forzados a duplicar código.
La causa de este problema viene del hecho que la clase SequenceCommand, la clase de la que extienden nuestros Commands a secuenciar, utiliza una propiedad nextEvent que es la que decide cuál es el siguiente Evento (y por consiguiente Command) que se va a ejecutar. La forma en la que los Commands son lanzados hace que sea imposible parametizar esta propiedad y por lo tanto se mantega estática.

Un ejemplo de un Command que forma parte de una secuencia:

HolaCommand.as (ejemplo estático)

Encadenado dinámico

El encadenado dinámico es mucho más flexible que el estático dado que permite crear de forma dinámica las secuencias de Commands, de este modo podremos reutilizar un mismo Command para formar parte de diferentes secuencias o para ser lanzado individualmente.
Para conseguir este objetivo nos vamos a servir de una colaboración que Bjorn Schultheiss ha hecho al repositorio de recursos para Cairngorm: cairngormdocs.com.
Se trata de dos clases: com.bjorn.event.ChainEvent y com.bjorn.event.EventChainFactory.
La clase ChainEvent es un wrapper de com.adobe.cairngorm.control.CairngormEvent que añade la propiedad nextChainedEvent:ChainEvent, y la clase EventChainFactory es la que se ocupa de enlazar dinámicamente las diferentes instancias de eventos que queremos secuenciar. Se le pasa un Array de instancias de ChainEvent y va asignando de mayor a menor (en índice) cual es su nextEvent.

Un ejemplo de un Command que se añade dinámicamente a una secuencia, su evento relacionado y la forma de crear la secuencia:

HolaCommand.as (ejemplo dinámico)

HolaEvent.as (ejemplo dinámico)

Creación dinámico de la secuencia

Proyectos de ejemplo

Incluyo dos proyectos muy simples de ejemplo. Uno para secuenciado estático y otro para secuenciado dinámico:

Secuenciado estático de Commands

Secuenciado dinámico de Commands

Como veíamos en el post anterior, hemos pasado la versión inicial del Flex Store simplificado a una versión bajo el framework de Cairngorm. En este post pasaremos esta misma aplicación a la versión con guasax para poder apreciar mejor los pros y los contras de una u otra solución.

En este ejemplo no hacemos uso de todas las posibilidades que nos aporta el framework, roles de usuario, interceptors, reutilización de componentes, acceso a servicios remotos,acciones delegadas entre componentes, etc... Pero permite apreciar de una manera muy sencilla la forma de lanzar los casos de uso de nuestra aplicación.

Comencemos entonces, a ver esta versión y analizar las posibilidades que nos aporta este framework en el desarrollo de nuestros proyectos.

En primer lugar para los que tengan dudas de como se plantea una programa bajo el framework guasax , recomiendo echar un vistazo a los post del Hola mundo en guasax, y ejemplo Calculadora en guasax, en los que se define la forma de crear un proyecto guasax, y como poner en marcha el mismo.

Para seguir el articulo , podéis ver el ejemplo online pudiendo acceder al código fuente, y descargar el proyecto para importar en Flex Builder aqui.

Fichero principal de la aplicación

En primer lugar vemos como cargamos el fichero de configuración de guasax en el fichero Main.mxml de la aplicación, ejecutamos el método initGuasax en el evento preinitialize="initGuasax()".

Cuando termina de parsear el fichero y cargar el framework , ejecutamos el método inicializaModeloDeDatos, llamando la caso de uso PIDE_PRODUCTOS. Vemos comentadas las lineas de las otros dos versiones del ejemplo.

Creación del fichero guasax-conf.xml

En el fichero guasax-conf.xml definimos los componentes y las acciones de estos, que queremos invocar en nuestra aplicación a través del framework. Una vez definidas estas acciones podremos invocarlas desde cualquier parte de nuestra aplicación.

En este fichero definimos dos componentes, con sus acciones y los métodos de las clases BO (Business Object) que se van a ejecutar cuando invoquemos estas acciones.
Como veremos en posteriores ejemplos podemos incluir mas ficheros de definición de componentes desde este fichero de configuración pudiendo separar en varios ficheros la configuración de los componentes de nuestra aplicación.
Acompañando al fichero de configuración en muy recomendable definirnos un fichero de constantes en las que definir los nombres de los métodos , de los servicios remotos , y de las vistas.

De esta manera a lo largo de nuestro código siempre invocaremos a nuestras acciones de negocio, servicios remotos, recuperaremos las vistas del ViewLocator, a través de constantes, para tener menos dependencia de los nombres (String) que ponemos a los métodos y poder referenciarlos siempre a través de una constante, fácilmente accesible.

De los Command a los business objects

Como hemos visto en el fichero de configuración, para este ejemplo creados dos clases que harán las veces de business objects, concentrando la lógica de nuestra aplicación en la que accederemos y modificaremos el modelo de datos. Estás clases agruparan conceptualmente los métodos relacionados con los Productos y los Pedidos.

A diferencia de las clases comando del ejemplo con Cairngorm , en este caso los métodos de los BO reciben los parámetros directamente en lugar de una clase Event de la que se extraen los atributos que pasamos al método.

Los métodos de estos BO deben estar totalmente desacoplados de la vista sin tener que hacer referencia directamente a ningún elemento del interface de usuario, para poder ser reutilizados sin tener que tener presente una dependencia con dicho interface. De esta manera conseguimos un mayor grado de reutilización en nuestros componentes.

Invocando las acciones desde la vista

Para cada una de los disparos de los eventos que veíamos en el ejemplo con cairngorm tenemos en este caso una invocación a una acción de guasax. En el ejemplo con cairngorm había una serie de acciones que desencadenaban una actualización del interface, en este caso esas acciones se llevan a cabo llamando a través de GuasaxContainer, a un método de la vista.

Como vemos en estos dos ejemplos de llamadas(de la clase FormEnvioDatos.mxml) , tenemos un método en el framework que nos permite ejecutar un método de una vista pasándole el objecto que representa esa vista (previamente lo hemos almacenado con una key en el ViewLocator), el nombre del método, y los parámetros que queremos pasarle como un Array.

En el codigo de arriba recuperamos el objeto vista que previamente hemos metido en el ViewLocator, con el nombre ConstantsApp.PROCESAR_PEDIDO_VIEW, que corresponde en este caso con la vista ProcesarPedido.mxml.
En esta vista tenemos el metodo selectedView, desde el que actualizamos el indice del viewStack.

En el fichero principal Main.mxml , también tenemos un método selectedView en el que dependiendo de que valor pasamos al mismo, llevamos a cabo un efecto u otro, en este caso rotamos el Cubo hacia un sentido u otro.

En nuestras vistas podemos tener todos los métodos de actualización que queramos, con cualquier nombre y con cualquier paso de parámetros. No estamos limitados a un solo método selectedView. Podemos definir métodos concretos que lleven a cabo trabajos concretos sobre las vistas que sean invocados después de finalizar diferentes acciones de los BO, dependiendo de como esas sean llamadas, con redirección a la vista y sin redirección.

Para el resto de acciones del ejemplo que llaman a acciones tenemos invocaciones del tipo , executeAction, como podemos ver en el metodo agregarLineaDePedido() del fichero DetalleProducto.mxml

Por ejemplo, en el código de arriba vemos las tres formas de invocar a la misma acción en cada una de las versiones.

Conclusiones

De una manera muy breve:
- Los Events y Commands en Cairngorm se sustituyen por los métodos de nuestros diferentes componentes de negocio o business objects. Conseguimos con esta agrupación una menor cantidad de clases, Eliminando las clases comando y las clases evento, siendo sustituidas por las clases business objects en las que agrupamos conceptualmente nuestros métodos de negocio

- El FrontController de Cairngorm desaparece en la versión en guasax, en la creamos un fichero de configuración donde definimos los componentes , sus acciones, y modificadores sobre las mismas como interceptors, roles, etc....

- En la versión con guasax , no tienes que extender tus clases de ninguna clase del framework, para que estas desarrollen su trabajo. Es un framework poco intrusivo.

- La actualización del interface no la hacemos a través de unas variables en el modelo, sino que tenemos una método concreto en el framework para llevar a cabo invocaciones a métodos definidos en nuestros ficheros de vista. De esta manera no acoplamos nuestra vista a nuestro Modelo de datos.

- En el momento de ejecutar una acción de tu lógica de negocio, puedes pasar que vista/s quieres que sea notificada(ejecutando un método de la misma) después de ejecutar el método del business object. Este encadenamiento de ejecución de una parte de logica y otra de la vista(a la que llamamos coloquialmente, "redirección a la vista") , no esta definida en tiempo de compilación, sino que se lleva a cabo en tiempo de ejecución, en el momento de invocar el "executeAction", por lo que logica de negocio y vista no esta acoplados en ningún momento.
Nuestras clases de negocio no saben absolutamente nada de las acciones de vista que les van a seguir, estas serán indicadas desde el lugar en el que se lance la acción, en tiempo de ejecución. De esta manera en un determinado momento nos puede interesar que a una acción le acompañe una ejecución de un método en una determinada vista de nuestra interface, pero en otro momento nos puede interesar solamente ejecutar la acción sin redireccionar a un método de la vista seguidamente.

En posteriores post analizaremos más funciones como acceso a servicios remotos, reutilización de componentes, encadenamiento de acciones, funciones delegadas en otros componentes, etc... viendo las posibilidades que nos brinda guasax para solventar estas acciones en nuestros programas.

Enlaces y recursos

- El enlace para descarga del proyecto lista para ser importado en Flex Builder

- El enlace para ver el ejemplo online con la opción de ver codigo fuente activada.

- Fuente para los efectos de distorsión mostrados en el ejemplo

Las 3 versiones del ejemplo Flex Store simplificado

- Sin framework: Articulo 1 version Flex Store simplificado.

- Cairngorm: Articulo 2 version Flex Store simplificado Cairngorm.

- Guasax: Articulo 3 version Flex Store simplificado Guasax.

Con la idea de preparar varias aproximaciones a la solución de un mismo problema he pasado la aplicación Flex Store simplificada desarrollada por Joan Garnet tanto a cairngorm como a guasax.

En la primera versión que desarrolló Joan mostraba en el ejemplo una serie de buenas practicas en cuanto a la organización de código y separación de conceptos dentro de una aplicación Flex simulando una Flex Store simplificada.

En este ejemplo vemos esa misma aplicación pasada, con los mínimos cambios posibles, a Cairngorm.

En primer lugar decir simplemente que debido al gran trabajo de joan , pasarlo a cairngorm ha resultado extremadamente directo, ya que la aplicación estaba muy preconcebida para ello.

Como punto de partida recomendamos leer nuevamente el articulo de Joan para centrar el tema de discusión.
En este articulo simplemente mostraremos algunos cambios relevantes en el código entre las dos versiones. Esperamos que tanto esta versión como la basada en guasax sirva como piedra de toque para la adopción de determinado framework, si todavía no utilizamos uno, entorno al cual organizar y hacer crecer nuestros proyectos de la mejor manera posible.

El ejemplo de la aplicación con (acceso al código fuente para descarga y visualización ) se puede ver aqui.

La podéis descargar directamente aquí como proyecto para importar directamente en Flex Builder , con la libreria de Cairngorm incluida.

Preparando el proyecto

Como podemos ver en la estructura de la aplicación, tenemos un directorio swclibs en el que tenemos la libreria swc de cairngorm que deberos cargar en el Flex Build Path de nuestra aplicación.
Además en el fichero principal de la aplicación , en este caso el Main.mxml, debemos cargar el Controlador que se encargará de crear y añadir los eventos necesarios para el funcionamiento de la aplicación:

Como podemos ver en el código, a través de la instrucción "control:Controller" inicializamos el singleton del Controller ,lo que hará que este declare los eventos, vincule los comandos que los van a atender , y los añada al FrontController. Una nota importante, si un evento no es añadido al FrontController , aunque lo disparemos , NO se ejecutará el Comando que tiene asociado. Por ello si disparáis un evento y veis que no se ejecuta el Comando asociado, revisar si habéis añadido esta relación en el Controller.
Una vez cargado el Controller, vemos que en el método inicializaModeloDeDatos lanzamos el primer evento para que se ejecute una acción. En la linea comentada podéis observar la forma de hacerlo en la versión anterior.

El controlador en Cairngorm

Cairngorm nos aporta un FrontController del cual podemos heredar para crear nuestro propio Controlador, en este controlador declararemos nuestros eventos y les asignaremos una clase Comando a cada uno de estos para que desarrollen su función.

Creación de las clases Evento y Commands

Partiendo de la clase Controlador del ejemplo inicial, en la que teníamos declarados los eventos que va a disparar la aplicación, así como los métodos que atienden a dichos eventos, podemos crear las clases comando para atender a cada uno de estos eventos que vamos a lanzar desde el código.
Las clases Evento tiene pocos cambios respecto a la version anterior, simplemente heredan de la clase de Cairngorm CairngormEvent, la que les permitirá entre otras cosas, poder disparase directamente sin necesidad de utilizar la clase CairngormEventDispatcher.
Para cada uno de los eventos y casos de uso que queremos lanzar en nuestra aplicación nos creamos una clase Comando. Para ello debemos implementar la interface ICommand.
Aqui podemos ver un ejemplo de uno de los comandos de la aplicación:

Los métodos que en el ejemplo anterior teníamos en el Controlador , los hemos encapsulado en clases comando. Si desde estas clases comando tenemos que realizar llamadas a servicios remotos , estas llamadas se delegan en un BusinessDelegate que es el encargado de hacer la invocación al servicio remoto.

Lanzando los eventos

Para lanzar los eventos de Cairngorm lo podemos hacer a través del CairngormEventDispatcher o directamente desde el propio evento , llamando al método dispatch();

Como podemos ver en esta porción de codigo:

vemos como desde una parte de la vista de nuestra aplicación, en el manejador del evento click, sobre un botón ponemos el disparo de algunos eventos. Desde el click del boton estamos desencadenando el evento que hará que se ejecute el comando que tenga asociado dicho evento, desde este comando llevaremos a cabo nuestra lógica de negocio , llamada a servicios remotos , y actualización de nuestro modelo de datos.

Conclusiones

En este ejemplo hemos podido ver como Cairngorm nos aporta una cierta organización de código en torno a unos patrones de diseño. En el ejemplo preliminar el codigo ya estaba organizado en torno a unas practicas programativas similares por lo que la diferencia no es excesiva. Cairngorm nos aporta como valía añadida un FrontController con alguna función añadida, una forma de definir y consumir servicios remotos (a través del ServiceLocator) y una forma de vincular una evento con una clase que implemente el patrón Comando.

En el siguiente post mostraremos el mismo ejemplo en guasax para empezar a trabajar en algunas de las problemáticas que se plantean cuando creamos proyectos con un volumen de clases considerable y debemos primar la reutilización de código así como la mantenibilidad de la aplicación.

Finalmente, agradecer a Joan las facilidades prestadas para utilizar su ejemplo como plataforma para trabajar este tipo de problemáticas en el desarrollo de aplicaciones Flex.

Enlaces y recursos

- Articulo de Joan con la primera versión del ejemplo Flex Store simplificado.

- Enlace online al ejemplo con opción de ver codigo fuente con el boton derecho del raton.

- Enlace para descarga del proyecto para importar directamente en Flex Builder con la librería de cairngorm incluida.

Hola a todos,

Recientemente he realizado mi proyecto fin de carrera de Ingeniería Informática utilizando Flex 2. Aunque tengo experiencia previa en otros lenguajes de programación, era la primera vez que me introducía en este mundo de las RIAs y que utilizaba Flex y ActionScript.

Me gustaría enseñaros lo que he conseguido hacer.

La aplicación consiste en la simulación de una red cuya topología puede diseñar el usuario para estudiar el comportamiento de los datagramas ante la fragmentación IP.

No quiero enrollarme mucho aquí, así que si alguno tiene interés y quiere más información o surge alguna pregunta sobre el funcionamiento de la aplicación adelante con ella. Antes de que me digais nada quisiera comentar que el tiempo del que se dispone para este tipo de proyectos es limitado. A mí me gustaría que la aplicación contemplase muchas más cosas (TCP y UDP, enrutamiento realista, etc.) Desafortunadamente no había tiempo para todo y eso queda abierto para futuras ampliaciones de la aplicación.

Ha sido mi primera vez. Sed benevolentes con los comentarios.

Aquí podeis probar fragSim.

Un saludo y seguid así con este estupendo sitio sobre Flex.

Presento un caso de uso de Cairngorm 2.2 incluyendo las últimas convenciones y funcionalidades. Ideal para iniciarse a la arquitectura por ser muy básico (es un formulario de Login).
El ejemplo consume servicios sobre AMFPHP 1.9 para poder mostrar también como pasar objetos tipados de Flex a PHP y viceversa.
Descargar ejemplo: Ejemplo Cairngorm 2.2 con amfphp 1.9 (Login)

Pikeo es un producto beta de France Telecom Research and Development LLC en South San Francisco.

Pikeo es otra de las alternativas que ofrece la web 2.0 para almacenar fotografías en linea y compartirlas con todo el mundo.

Pikeo te ayuda a organizar tus fotos en álbumes inteligentes basados en los datos "qué", "dónde", y "quién" (llamadas "etiquetas"). Puedes decidir cuales de tus fotos quieres compartir con tu familia, amigos, y otros, y cuales no quieres mostrar a nadie.

La interface de Pikeo es muy atractiva, ofrece 1GB de espacio gratis por cuenta. Además de soporte en inglés, francés y español.

Incluye también un mapa para localizar las fotos a travez de etiquetas, un buscador personalizable y soporte para comentarios.

Otra funcionalidad interesante es la de subir imágenes a Pikeo desde cualquier lugar a través del movil. Y por si deseas compartir tus fotos insertándolas en tu sitio web, Pikeo te da unas lineas de código que deberás pegar en tu sitio.

Este servicio aún continua en fase beta, por lo que el soporte al cliente es limitado de momento. Sin embargo, sigue siendo una buena alternativa para sitios como Flickr.