Caso de estudio: FlexStore con Cairngorm

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:

[ftf w=”450″ h=”250″]




[/ftf]

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.

[ftf w=”450″ h=”250″]
public class Controller extends FrontController
{
// toda las acciones de la aplicación se gestionan desde esta clase
public function Controller()
{
addCommand( LineaDePedidoEvent.BORRAR_LINEA_DE_PEDIDO, BorrarLineaDePedidoCommand );
addCommand( LineaDePedidoEvent.AGREAGR_LINEA_DE_PEDIDO, AgregarLineaDePedidoCommand );
addCommand( ProductoEvent.PIDE_PRODUCTOS, PideProductosCommand );
addCommand( ProductoEvent.PRODUCTO_SELECCIONADO, ProductoSeleccionadoCommand );
addCommand( CambioVistaEvent.VISTA_CREACION_PEDIDO, VistaCreacionPedidoCommand );
addCommand( CambioVistaEvent.VISTA_PROCESAR_PEDIDO, VistaProcesarPedidoCommand );
addCommand( CambioVistaEvent.VISTA_ENVIO_SATISFACTORIO, VistaEnvioSatisfactorioCommand );
addCommand( CambioVistaEvent.VISTA_ENVIO_ERRONEO, VistaEnvioErroneoCommand );

addCommand( PedidoEvent.ENVIAR_PEDIDO, EnviarPedidoCommand );

}
}
[/ftf]

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:

[ftf w=”450″ h=”250″]
// las acciones se encapsulan en Commands
// un Command es una acción cualquiera en la aplicación
public class BorrarLineaDePedidoCommand implements ICommand
{
public function execute( evt:CairngormEvent ):void
{
var index:int = ModeloDeDatos.getInstance().productosAdquiridos.
getItemIndex((evt as LineaDePedidoEvent).lineaDePedido);
ModeloDeDatos.getInstance().productosAdquiridos.removeItemAt( index );
}
}
[/ftf]

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:

[ftf w=”450″ h=”250″]



[/ftf]

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.

9 Comentarios

  1. Joan Garnet

    Finalmente tendremos una buena triología de casos de estudio con el Flex Store como base. Todo un clásico ya…
    Será muy interesante ver la comparativa final entre los dos frameworks: Cairngorm y Guasax. Espero ansioso el desenlace 😉
    un saludo!

  2. SeViR

    Cuando los desarrolladores web JS+CSS+HTML por fin hemos aprendido a quitar los manejadores de eventos del diseño, ahora todo el mundo en Flex tiene la manía de ponerlos de nuevo metiendo en nuestras vistas los típicos click=”” out=”” over=”” ……..

    Yo acostumbro a crear en Flex las vistas con el mínimo de referencias a código Script, y luego separar la capa de programación por otro lado. Cuando digo mínimo, es poner únicamente (si es necesario) el:

    Y luego en el código tirar de addEventListener para cualquier cosa. ¿Un framework inteligente con el que podamos hacer estas cosas en flex?

    No sé pero aún no termina de contentarme el modelo Cairngorm. Aún así muy interesante el ejercicio

  3. Pingback: MadeInFlex » Blog Archive » Caso de estudio: FlexStore con Guasax

  4. Pingback: Comparativa de aplicaciones en Flex « think different, think flex

  5. Comet

    Supongo que el flujo de trabajo para Cairgorm sigue los mismos pasos que en el ejemplo de Joan, esto es:

    Un posible flujo a seguir:

    1. Crear la estructura del proyecto
    2. Detectar las vistas principales.
    3. Crear el modelo de datos.
    4. Desglosar cada vista principal en sub-vistas.
    5. Definir los eventos y crear el controlador.

    Cierto o es mejor hacer ante el controlador como parece que se hace en tu ejemplo?

    Gracias!

  6. Pingback: Flex+Cairngorm en castellano desde MIF » Joan | Garnet Flex:Flash:PHP:MySQL:JS

  7. adsfasdf

    💡 :mrgreen: 😐 😈 ➡ 😯 👿 😳 😛 😥 😡 ❗ ❓ 😈 😕 👿 💡 😛 😆 ❗ :mrgreen: :mrgreen: 👿 🙄 🙄 😉 😡 😡 ❗

  8. Pingback: Flex+Cairngorm en castellano desde MIF : Joan Garnet :: Arquitectura y desarrollo RIA

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase