Indice

1. Indice • Introducción a guasax • Arquitectura interna de guasax • Fichero de Configuración • Estructura de un programa guasax • HolaMundoGuasax paso a paso • Funciones avanzadas • Versiones , Roadmap y Enlaces • Conclusiones

2. Introducción a guasax

3. Introducción a guasax (1/4) • Guasax es un framework de programación para facilitar la creación ordenada de programas en tecnología Flex. • Guasax implementa el patrón MVC para guiar el ciclo de vida de las acciones que deseamos llevar a cabo desde nuestro programa. • Guasax te ayuda a separar la lógica de negocio de tu aplicación de los datos y de la vista de la misma, para mantener estas capas con una grado de acoplamiento muy bajo. • Guasax se apoya en técnicas de Reflexion, Introspección y patrones como IoC para ejecutar las operaciones que le indicamos y tomar decisiones sobre las mismas, en determinados casos. • Guasax no es intrusivo en nuestras clases, no teniendo que extender las mismas para poder trabajar con el mismo.

4. Introducción a guasax (2/4) • Guasax tiene similitudes con frameworks de programación web como WebWork 2.2.4 , Struts 2.0 e implementa ciertas utilidades de una manera similar a Cairngorm 2.1. • Guasax se basa en un contenedor de componentes configurables (Bussiness Objects) en los que definimos los métodos que implementan la lógica de negocio. • Dentro de nuestro programa lo que ejecutamos son “acciones” y una acción pertenecen a un determinado componente y la lleva a cabo un método de ese componente. El componente está representado por una clase que denominamos Bussiness Object. • La configuración del framework se toma de un fichero XML externo.

5. Introducción a guasax (3/4) • Los objetivos de guasax son: • Separar las capas de nuestra aplicación en Vista, Modelo de datos, Clases de negocio, y Servicios remotos. • Estandarizar el proceso de creación de nuevos casos de uso y resolver el problema de “que se debe hacer en cada sitio” dando un patrón a seguir. • Desacoplar el código entre capas. • Perseguir la reutilización “real” de código a nivel de componentes funcionales.

6. Introducción a guasax (4/4) • Una última consideración introductoria: • Para programar con guasax no es necesario conocerse todos los patrones de diseño. Precisamente una de las características de guasax es que implementando internamente dichos patrones, garantiza que si el programador sigue las guías del framework, estará programando con buenas técnicas de diseño. Si no es así, es que el framework no cumple su labor en algún aspecto.

7. Arquitectura interna de guasax

8. Arquitectura interna de guasax (1/7) • La arquitectura de guasax se basa en el concepto de contenedor de componentes. • Los componentes del framework tienen su correspondencia en una clase ActionScript, que implementa las operaciones del componente. • Mediante un fichero de configuración XML externo se definen los componentes y las operaciones que se pueden invocar de los mismos (acciones). • En el proceso de inicialización del Container, se instancian estas clases(BO – Bussiness objects) actuando a partir de ese momento como Clases Singleton. • Dentro del container se mantiene una lista de componentes y cada uno de estos con una lista de acciones.

9. Arquitectura interna de guasax (2/7)

10. Arquitectura interna de guasax (3/7) • Cada componente almacena una lista de acciones y una serie de propiedades , que en primera instancia se cargan del fichero xml, y posteriormente se pueden modificar desde el container. • Un componente tiene una instancia de una clase de tipo BO. Esta instancia se crea por reflexión a través del nombre cualificado de la clase, que le indicamos en el fichero xml. • Esta instancia solo se crea una vez, no cada vez que se ejecuta una acción, ahorrando tiempo de instanciación.

11. Arquitectura interna de guasax (4/7) • Del fichero de configuración se leen las acciones que tiene cada componente asociado. • Estas acciones están implementadas en los métodos de la clase BO que tiene asociado el componente. • Por lo que en definitiva , diremos que un componente tiene acciones. • Las acciones contienen una serie de atributos, que dependiendo de cómo se ejecuten a través del contenedor, tomarán un valor u otro.

12. Arquitectura interna de guasax (5/7) • La otra parte fundamental de guasax son los servicios que provee para invocar las acciones que hemos definido. Principalmente tenemos: • executeAction(actionName:String, params:Array): ResponseActionVO • Ejecutamos una acción pasándole un Array de parámetros que coinciden con los parámetros formales que recibe ese método. • executeActionWithView(actionName : String,params : Array, viewObjectArray : Array, viewMethodName: String,viewParams:Array): ResponseActionVO • Similar a la anterior pero podemos pasar un array de obj de tipo vista, y el método de esta/s que queremos invocar, una vez se haya ejecutado la acción del BO, guasax invocará ese método de la vista por nosotros.

13. Arquitectura interna de guasax (6/7) • executeActionWithViewAfterService(actionName : String params : Array, viewObjectArray :Array,viewMethodName : String,viewParams:Array): ResponseActionVO • Similar al servicio anterior pero en este caso, si llamamos a un servicio remoto de manera asíncrona, el container en lugar de continuar con la redirección a la vista, aplaza esta redirección hasta que tengamos una respuesta de este servicio. • De esta forma podemos lograr que cuando el container redirecciona a la vista para continuar la ejecución de la tarea el servicio remoto ya ha finalizado. • De esta manera somos conscientes, cuando programamos la lógica de la operación, que en el método de update de la vista ya tendremos el resultado del servicio remoto.

14. Arquitectura interna de guasax (7/7) • Además de las operaciones anteriores de servicio, a través del contenedor también podemos realizar operaciones como: • parseConfFile(xmlfile:XMLNode):void • findAction(actionId:String):ActionVO • findComponent(componentId:String):ComponentVO • setEnabledComponent(componentId:String,value:Boolean):void • isEnabledComponent(componentId:String):Boolean • setEnabledAction(actionId:String,value:Boolean):void • isEnabledAction(actionId:String):Boolean • setUserRole(userRole: String):void • getUserRole():String

15. Fichero de configuración

16. Configuración de un programa guasax(1/3) • Un programa guasax se configura a través de una fichero XML. Aquí tenemos un ejemplo:

17. Configuración de un programa guasax(2/3) • Los componentes tiene una referencia, “className”,a la clase que instancian. • Las acciones tienen un atributo “method” que indica el método de la clase que se debe invocar, cuando se pide ejecutar dicha acción. • Los componentes y las acciones pueden tener un atributo “enabled” que indica si se pueden ejecutar o no. El “enabled” del componente predomina sobre el de las acciones. • Las acciones permiten definir que rol o roles, separados por comas, están capacitados para ejecutar esa acción. El rol se puede asignar para el usuario actual en el contenedor.

18. Configuración de un programa guasax(3/3) • Las acciones también permiten definir interceptors (acciones a su vez) de diferentes tipos: • Preinterceptor: Una o unas acción que queremos que se ejecute antes que la acción en cuestión. • Interceptor: Una sola acción que queremos que capture los parámetros que recibe la acción los modifique y se los pase modificados a la acción origen. • Postinterceptors: Una o unas acciones que queremos que se ejecuten con posterioridad a nuestra acción.

19. Estructura de un programa guasax

20. Estructura de un programa guasax(1/4) • Para inicializar el framework, en primer lugar declararemos un obj XML que apuntará al fichero XML de configuración de nuestro aplicación. Por Ejemplo: <mx:XML id="xmlfile" format="e4x|xml" source="/es/guasax/samples/helloworld/conf/guasax-conf.xml" /> • Si vamos a utilizar servicios remotos , definiremos un objeto “<services:Services id="services" />” , que extendiendo del ServiceLocator define los servicios remotos que vamos a utilizar. • Este obj “services” lo definiremos en el main.mxml de nuestra aplicación. • Podemos utilizar el evento creationComplete="init()“ , para definir una función “init” en la que cargar la configuración del framework, GuasaxContainer.getInstance().parseConfFile(xmlfile);

21. Estructura de un programa guasax(2/4) • Las clases que implementarán la lógica de negocio de nuestra aplicación estarán agrupadas en cuanto al rol que desempeñan. • Los principales roles que identificamos en el framework son: • Value Objects • Model • Bussiness Objects • Services • Views • Además podemos tener todas las clases internas que necesitemos para nuestra lógica de negocio, clases util, etc… • Dentro de lo que llamamos “Views” agruparemos los ficheros MXML y las clases de soporte que estén relacionadas con estos, tipo filtros, formats functions,etc…

22. Estructura de un programa guasax(3/4) • El ciclo de vida típico de una acción guasax suele ser: • Desde una clase de la vista se desea realizar una operación. • A través del guasax container ejecutamos esa acción, pudiendo indicar un Array de objetos vista y un método de las mismas a ejecutar. Por ejemplo: • executeActionWithView(actionName ,params, viewObjectArray , viewMethodName,viewParams): ResponseActionVO • El container busca entre sus componentes la acción, y la invoca a través de la instancia del BO que tiene almacenada, pasándole los parámetros que indicamos en la llamada. • Cuando el método del BO termina, el contenedor, recoge la respuesta que devuelve el método, e invoca el método de la vista pasando como parámetro esta respuesta.Tambien se puede invocar la vista sin pasar ningún parámetro y que coja los datos a través del ModelLocator.

23. Estructura de un programa guasax(4/4) • Diagrama típico del ciclo de vida y los elementos que pueden intervenir en una petición:

24. HolaMundoGuasax paso a paso

25. HolaMundoGuasax paso a paso(1/1) • En este capítulo veremos el código necesario y la estructura de directorios creada para crear el mínimo programa bajo guasax. • En primer lugar crearemos un proyecto Flex. En el fichero principal llevaremos a cabo tres tareas. • Definir el fichero de configuración en XML. • Inicializar el framework en el método oncreation • Crear al menos una variable de las clases que vamos a instanciar por reflexion. Esto es necesario para que el compilador incluya la información de estas clases, y en tiempo de ejecución dispongamos de la misma, y podamos intanciarla.

26. HolaMundoGuasax paso a paso(2/5) • Aquí podemos ver la estructura del proyecto. Tenemos el fichero GuasaxHelloWorld.mxml, fichero principal de la aplicación. • Tenemos un clase HelloWorldBO que contiene el método que vamos a invocar. • En el directorio conf, tenemos el fichero Constants.as, en el que indicamos las constantes para identificar el nombre de las acciones, y servicios. • También tenemos el fichero guasax-conf.xml en el definimos los componentes y acciones.

27. HolaMundoGuasax paso a paso(3/5)

28. HolaMundoGuasax paso a paso(4/5) • En la imagen anterior podemos ver el código completo del fichero GuasaxHelloWorld.mxml desde el que hacemos la llamada a la acción guasax mediante un botón. • Podemos observar el método initcon el que inicializamos el framework, y el objeto XML , en el que definimos el fichero xml de configuración.

29. HolaMundoGuasax paso a paso(5/5) • Por último aquí podemos ver la clase HelloWorldBO que hace las veces de BO. • Tenemos un método sayHelloque se invoca a través de la accion del mismo nombre sayHello (Nota:no es obligatorio que tenga el mismo nombre). • En este método simplemente mostramos un mensaje a modo de demo. Desde aquí se podrían invocar servicios remotos, y meter resultados en el Modelo a través del ModelLocator.

30. Funciones avanzadas

31. Funciones avanzadas (1/6) • Ya hemos hablado en anteriores capítulos de las posibilidades de redireccionar a la vista por parte del framework después de ejecutar una acción, ahora vamos a comentar otras posibilidades que nos brinda guasax. • Habilitación de acciones , componentes • Configuración de roles de acceso • Programación de interceptors • Acciones de un componente implementados por otra de otro componente. Acciones redirigidas. • Ejecución de un método un obj de una vista (sin la necesidad de pasar por un método de un BO).

32. Funciones avanzadas (2/6) • A través de los servicios setEnabled podemos activar o desactivar una acción o componente, prohibiendo la ejecución de sus acciones. • Mediante los roles de acceso podemos definir para cada acción los roles que pueden ejecutar la misma. Al loguear al usuario en nuestra aplicación , definimos el rol en el container y así el container sabe que rol tiene el usuario, y posteriormente al invocar las acciones sabe si puede o no puede ejecutarlas. La definición de roles es opcional. • A través de los interceptors podemos configurar en una acción, el hecho de que se ejecute otra acción de las que tenemos definidas antes(pre) , después (post) o que directamente intercepte la ejecución , modificando los parámetros que llegan a la acción origen.

33. Funciones avanzadas (3/6) • Un ejemplo de preinterceptor, sería llevar a cabo la búsqueda o preparación de unos datos en la base de datos, previos a la ejecución de la acción, o verificar si estamos logueados en el sistema. • Un ejemplo de interceptar los parámetros de entrada, sería tomar un cadena que viene cifrada, y aplicarle una acción de descifrado , para que cuando se ejecute la acción no tenga que tener esta el algoritmo de descifrar. • Por último un ejemplo de postinterceptor, sería aplicarle a una acción un postinterceptor para que genere log de esa acción de una determinada manera. • La ventaja de los interceptors es que permiten dotar de ciertos aspectos a las acciones sin que estas tengan que variar su código.

34. Funciones avanzadas (4/6) • Otra posibilidad que permite el framework es la de indicar a una acción en su fichero xml de configuración que realmente, el componente y acción que se debe ejecutar cuando la invoquen es otra. • Imaginaros que tenéis un componente que lee noticias de un sistema regularmente y cuando detecta una nueva, genera un evento invocando una acción guasax que tiene definida. Si nosotros queremos utilizar ese componente en nuestra aplicación deberíamos tener la forma de capturar esa llamada a esa acción para procesarla (o sobrecargarla digamos) según la necesidad de la aplicación en la que estoy. • Para esto se puede indicar en el fichero xml de configuración, para ese componente y acción, que la acción que realmente atenderá a la misma será una de las nuestras, en lugar de la original del componente. De esta manera uno de nuestros componentes particulares podrá capturar la acción originada por el componente externo.

35. Funciones avanzadas (5/6) • A veces tenemos que llamar a una método de una vista para llevar a cabo una actualización de una parte de interface visual, realizar una transición de estados, desencadenar unos efectos, etc... • En definitiva operaciones que no llevan asociado un trabajo desde un BO , ni actualizar nuestro modelo de datos ninguna manera. • En estos casos, habitualmente tenemos que lanzar esta actualización de la VistaA a la VistaB, con los problemas de ámbito que esto puede conllevar. • A veces estas funciones las podemos resolver trabajando con algún tipo de variable tipo “workflowState” en el Model de nuestra aplicación, cambiandole el valor , y que esta variable este bindada, por ejemplo, en un ViewStack de la Vista.

36. Funciones avanzadas (6/6) • Si esta solución no nos gusta (particularmente tener en el Singleton que representa mi modelo de datos, un variable que indique el estado de mi vista no me parece correcto) podemos a través de guasax hacer una llamada para invocar de un obj vista un determinado método. • Para almacenar y acceder posteriormente desde cualquier parte de nuestro programa a los objetos vista de nuestra aplicación podemos utilizar la clase “ViewLocator” que funciona como un contenedor de objetos vistas almacenados por nombre, tipo HashMap. • De esta manera podemos llamar a guasax así: var viewObjectArray:Array = [ViewLocator.getInstance().getViewObject(“ID_VIEW”)]; GuasaxContainer.getInstance(). executeViewUpdate(viewObjectArray , viewMethodName , viewParams):void • Invocándose el método que pasamos como “viewMethodName” de los objetos viewObjectArray. También podemos pasar parámetros en el tercer valor.

37. Versiones, Roadmap, y recursos

38. Versiones , roadmap y recursos(1/2) • El Roadmap previsto: • En estos momentos la versión de guasax es la 0.9 Alpha, ya que todavía se pueden incorporar funcionalidades al framework. • Beta 0.9, Mayo 2007. • Final Release, versión 1.0 , con documentación, ejemplos de uso avanzados , y guías de desarrollo, FinalesJunio 2007

39. Versiones, roadmap y recursos(2/2) Web oficial • www.guasax.com Blog • http://guasax.wordpress.com Grupo discusión y lista correo • http://groups.google.es/group/guasaxcoders/ Código fuente SVN • http://code.google.com/p/guasax/source Wiki • http://code.google.com/p/guasax/w/list Downloads y ejemplos • http://code.google.com/p/guasax/downloads

40. Conclusiones

41. Conclusiones (1/1) • Guasax es un framework de programación de código abierto que pretende ayudar a la comunidad de desarrolladores Flex a llevar a cabo desarrollos con buenas practicas de diseño. • La finalidad de guasax es contribuir a desarrollar programas con una código fuente ordenado, desacoplado, fácilmente mantenible y ampliable, y en el que un grupo de desarrolladores puedan trabajar a gusto bajo las mismas premisas de desarrollo. • El objetivo final de guasax sería proporcionar un entorno de desarrollo basado en componentes reutilizables, evitando la reescritura de código.