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()”.

[ftf w=”450″ h=”250″]
// Nota: Es necesario crear al menos una variable para que el copmpiler incluya la clase de la misma,
//para que en tiempo de ejecucion se pueda instanciar la clase e invocar un metodo.
private var classForCompile:Array = [PedidoBO,ProductoBO];
/**
* Registramos la vista principal en el viewLocator y
* Leemos el fichero de configuracion de guasax
*/
public function initGuasax():void{
ViewLocator.getInstance().register(ConstantsApp.MAIN_VIEW,this);
// —————————————————————
/**
* Parseamos el fichero de configuracion para el container con la ayuda de la clase
* XMLConfParser
*/
GuasaxContainer.getInstance().parseConfFile(“./conf/guasax-conf.xml”,inicializaModeloDeDatos);
}
/**
* Cuando terminamos de leer el fichero de configuracion, inicializamos la carga de los
* productos mediante el caso de uso, PIDE_PRODUCTOS.
*/
private function inicializaModeloDeDatos(event:Event):void
{
// 1 Version simple
//Controlador.getInstance().dispatchEvent( new ProductoEvent(ProductoEvent.PIDE_PRODUCTOS) );

// 2 Version con cairngorm
//new ProductoEvent(ProductoEvent.PIDE_PRODUCTOS).dispatch();

// 3 Version con guasax
GuasaxContainer.getInstance().executeAction(ConstantsApp.PIDE_PRODUCTOS,null);
}
[/ftf]

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.

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













[/ftf]

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.

[ftf w=”450″ h=”250″]
package conf
{
public class ConstantsApp
{
// —– Acciones de PEDIDO ——————————–
public static const AGREGAR_LINEA_DE_PEDIDO :String = “agregarLineaDePedido”;
public static const BORRAR_LINEA_DE_PEDIDO :String = “borrarLineaDePedido”;
public static const ENVIAR_PEDIDO :String = “enviarPedido”;

// —– Acciones de PRODUCTO ——————————–
public static const PIDE_PRODUCTOS :String = “pideProductos”;
public static const PRODUCTO_SELECCIONADO :String = “productoSeleccionado”;

// —– Nombre del metodo para actualizar la vista visible en cada momento ———-
public static const SELECTED_VIEW : String = “selectedView”;

// —– VISTAS del fichero principal ———-
public static const MAIN_VIEW : String = “MAIN_VIEW”;
public static const VISTA_CREACION_PEDIDO : Number = 0;
public static const VISTA_PROCESO_PEDIDO : Number = 1;

// —– VISTAS del fichero ProcesarPedido——————————
public static const PROCESAR_PEDIDO_VIEW : String = “PROCESAR_PEDIDO_VIEW”;
public static const VISTA_FORM_ENVIO_DATOS : Number = 0;
public static const VISTA_ENVIO_SATISFACTORIO : Number = 1;
public static const VISTA_ENVIO_ERRONEO : Number = 2;
}
}
[/ftf]

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.

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




[/ftf]

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.

[ftf w=”450″ h=”250″]
/**
* Metodo de la vista , llamado a través de guasax, desde otros ficheros MXML para
* lanzar una actualizacion del interface visual de esta vista. Ejecución de un efecto,
* transiciones, fitrado de datos, ordenacion de elemento visuales,
*/
public function selectedView(index:Number):void{
this.selectedIndex = index;
// En las anteriores soluciones se trabajaba con una varible en el modelo para determinar
// es estado que debía adoptar nuestra vista. Eliminando esta parte aligeramos el modelo del
// de controlar el estado visuales de los objetos que representan vista en nuestra aplicación.
//selectedIndex=”{ ModeloDeDatos.getInstance().vistaProcesarPedidoSelectedindex }”
}
[/ftf]

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.

[ftf w=”450″ h=”250″]
/**
* Metodo de la vista , llamado a través de guasax, desde otros ficheros MXML para
* lanzar una actualizacion del interface visual de esta vista. Ejecución de un efecto,
* transiciones, fitrado de datos, ordenacion de elemento visuales,etc..
*/
public function selectedView(index:Number):void{
// De esta manera cambiamos la vista que tenemos visible a través del efecto cube
//
if(index == ConstantsApp.VISTA_CREACION_PEDIDO){
rotateEffectRight.play();
}else if(index == ConstantsApp.VISTA_PROCESO_PEDIDO){
rotateEffectLeft.play();
}
}
[/ftf]

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

[ftf w=”450″ h=”250″]
private function agregarLineaDePedido():void
{
var lineaDePedido:LineaDePedido = new LineaDePedido();
lineaDePedido.producto = ModeloDeDatos.getInstance().productoSeleccionado;
lineaDePedido.cantidad = cantidad.value;
// 1ª Version simple
//Controlador.getInstance().
// dispatchEvent(new LineaDePedidoEvent(LineaDePedidoEvent.AGREAGR_LINEA_DE_PEDIDO,lineaDePedido) );
// 2ª Version con cairngorm
//new LineaDePedidoEvent(LineaDePedidoEvent.AGREAGR_LINEA_DE_PEDIDO,lineaDePedido).dispatch();

// 3ª Version con guasax
GuasaxContainer.getInstance().executeAction(ConstantsApp.AGREGAR_LINEA_DE_PEDIDO,[lineaDePedido]);
}
[/ftf]

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.

3 Comentarios

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

  2. Pingback: MadeInFlex » Blog Archive » MiniFlexStore Guasax con RemoteService sobre AMFPHP1.9

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