Caso de estudio: FlexStore con Guasax

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.