Recientemente un viejo conocido de la comunidad Flex hispana (Nahuel Foronda) ha publicado una serie de interesantes posts sobre Optimización de Flex para Móviles que iremos posteando traducidos al español, previa autorización

Si estás comenzando a hacer desarrollo móvil y estás acostumbrado a crear todos los ItemRenderers en MXML, habrás notado que pequeños dispositivos como teléfonos y tabletas no tienen un desempeño tan bueno como en escritorio y necesitarás buscar diferentes maneras de optimizar tu aplicación.

Una de las formas de optimizar tu aplicación móvil es crear tus ItemRenderers con ActionScript. Narciso Jaramillo escribió un buen artículo para Devnet con buenos tips para el desarrollo móvil y uno de los puntos es precisamente eso, mantener tus ItemRenderers en puro ActionScript.

Narciso menciona que el Framework de Flex viene con dos ItemRenderers uno es LabelItemRenderer que extiende a UIComponent y el otro es IconItemRenderer que extiende a LabelItemRenderer. Esas clases son buenas, pero a veces tenemos un diferente caso de uso que necesita una serie diferente de clases. así que en los ejemplos, no utilizaré esos rendereres. En su lugar, extenderemos directamente desde UIComponent o desde SpriteVisualElement para tener inclusive una clase más ligera que UIComponent.

Para el propósito de este tutorial, estoy planeando una serie de entradas explicando las bases y pasar a renderers con mayor dificultad.

Ejemplo Básico

Comencemos con el renderer más simple, un TextField que muestre algún texto. Para hacerlo sencillo, extenderemos desde UIComponent e implementaremos la interfaz IDataRenderer requerida por List.

Pero antes de hablar sobre el renderer, hablemos de otros elementos.

Application

Necesitas crear un proyecto tipo Mobile. En este ejemplo, usaré el más simple de los contenedores raíz, ese es un Application, no las subclases TabbedApplication o ViewBasedApplication. Agregaremos un List que se expanda al 100% como único elemento.

Estilos

Agregué una hoja de estilos externa donde tenemos todos los estilos para el ItemRenderer:

ItemRenderer

Tenemos una clase simple que extiende a UIComponet que nos da algunos métodos útiles y la habilidad de participar en el framework de CSS.

Estos 3 métodos de UIComponent que utilizaremos son los siguientes:

measure donde nosotros leemos el tamaño mínimo del renderer desde la hoja de estilos. Esto se vuelve útil porque dispositivos con diferentes resoluciones dpi necesitan diferentes medidas.

createChildren donde nosotros creamos el TextField, establecemos los estilos y si hay datos disponibles, configuramos el texto en el TextField a ser mostrado.

updateDisplayList donde posicionamos los elementos y dibujamos cada línea separadora para cada ItemRenderer.

Adicionalmente a estos métodos, tenemos la propiedad data, que es la implementación de la iterfaz IDataRenderer. Esa interfaz es el contrato con List y es la forma en la que los datos son empujados hacia el ItemRenderer. Si el TextField existe al momento de configurar los datos, entonces configuramos el texto dentro del TextField, de otra manera, lo guardamos para después.

Como pueden ver escribir un ItemRenderer en ActionScript no es tan difícil como suena.

Estoy planeando mostrar otros ejemplos en el futuro con múltiples elementos, fondos, estados, manipulación de texto, columnas múltiples y más.

El código fuente esta disponible para descargar.

Nota: Este artículo está traducido en MadeInFlex con autorización previa del autor, si quieren consultar la fuente original aquí tienen el enlace.

El framework Pimento Data Services nos permite realizar el “lazy loading” de una asociación que haya sido configurada como “lazy” en JPA. Para ese tipo de asociación el framework envía al cliente solamente “proxies”, no los datos reales, los datos reales serán cargados en el momento que se invoque el método “initialize” de la clase EntityManager, y no obtendremos una excepción del tipo LazyInitializationException. Veamos cómo funciona a través de un ejemplo.

El ejemplo

Lo primero será descargar el framework de aquí. Luego creamos un proyecto de tipo “Dynamic Web Project” con las siguientes características:

• Nombre del proyecto: LazyPimentoServer
• Target Runtime: En nuestro caso usaremos Apache Tomcat 6, pero puede utilizarse cualquier otro que se haya configurado.
• Versión del módulo Web Dinámico: 2.5
• Configuración: Configuración por defecto para Apache Tomcat 6.0
• Cambiamos la carpeta donde se compilarán las clases a “LazyPimentoServer/WebContent/WEB-INF/classes”.

Una vez creado el proyecto copiamos el contenido de la carpeta “server/web/WEB-INF/lib” de la distribución del framework en “WebContent/WEB-INF/lib” de nuestro proyecto. Sustituimos el archivo de HSQLDB por el controlador JDBC de MySQL, y copiamos de la carpeta “server/release” los archivos “cinnamon-core”, “cinnamon-reflect” y “pimento-core”. Necesitamos copiar también el paquete “javassist”, este lo podemos encontrar en la distribución de Spring con dependencias.

Creamos una carpeta denominada “config” dentro de “WebContent/WEB-INF” de nuestro proyecto y copiamos los archivos “jpa-spring.xml” y “pimento-spring.xml” en “server/web/WEB-INF/config” en la distribución del framework; también copiamos el archivo “dp.properties.template.mysql” de “server/web/WEB-INF/config/db-templates” como “db.properties” en “WebContent/WEB-INF/config” de nuestro proyecto y ajustamos los valores de la conexión a la base de datos. Como estamos en fase de desarrollo ponemos “hibernate.hbm2ddl.auto=update”.

Finalmente el archivo “web.xml” de nuestro proyecto queda así:

Seguidamente crearemos las entidades asociadas:

Project

Task

Como vemos son dos entidades JPA con anotaciones de Pimento que indican que serán gestionadas por éste. La entidad “Project” tiene una asociación con la entidad “Task” de tipo OneToMany configurada como “lazy”, lo que implica que cuando se cargue una instancia de “Project” no se cargarán en ese instante las instancias de “Task” asociadas con ésta. En este caso el framework enviará al cliente “proxies” que serán utilizados para cargar los datos reales. Veamos cómo funciona esto desde la UI, pero primero cargaremos algunos datos en la base de datos:

Creamos un proyecto Flex con las siguientes características:

• Nombre del proyecto: LazyPimentoClient
• Tipo de aplicación: Web
• Seleccionamos el SDK por defecto
• Como tecnología del servidor no seleccionamos ninguna
• Como carpeta de salida seleccionamos la carpeta WebContent del proyecto LazyPimentoServer que creamos anteriormente.

Nuestra interface de usuario sería algo como esto:

Inicialmente cargaremos una instancia de Project e inspeccionaremos el contenido de su propiedad “tasks”, luego cargaremos las instancias de “Task” asociadas mediante el método “initialize” de la clase EntityManager, las cuales mostraremos en el “DataGrid”.

Para estructurar mejor el proyecto nos auxiliaremos del framework Robotlegs. Lo primero que haremos será incluir en el proyecto las librerías del framework Pimento y Cinnamon. Copiamos en la carpeta “libs” del proyecto los archivos “cinnamon-1.1.0.swc” y “pimento-1.1.0.swc” que se encuentran en la carpeta “client\release” de la distribución, incluimos también “spicelib-core-2.0.1.swc” y “spicelib-reflect-2.0.1.swc” de la carpeta “client\lib” y la librería del framework Robotlegs.

Creamos luego las clases en ActionScript que representan las entidades:

Project

Task

La configuración del framework en el cliente comienza con la creación de una instancia de la clase “PimentoConfig”, a través de la cual podemos obtener el “EntityManager” que usaremos para invocar las operaciones de persistencia. La clase PimentoConfig necesita conocer el URL de la aplicación JEE que a través de Cinnamon recibirá las solicitudes del cliente para invocar las operaciones de persistencia, específicamente el URL al servlet “service”. En nuestro caso cargaremos esta información de un archivo xml externo. El comando que hace todo esto y además carga la instancia de “Project” que insertamos en la base de datos es el siguiente:

Si corremos la aplicación con el “debugger” y nos paramos dentro del método loadResult veremos que el tipo de la propiedad “tasks” de Project no es un “Array” como está definido sino de tipo “ArrayProxy”.

Una vez cargada la instancia de Project, ante el evento “Click” del botón se ejecuta el comando que carga los datos de la asociación:

El método que carga los datos de la asociación es “initialize”, de “EntityManager”, se le pasa como argumento la propiedad “tasks” de la instancia de “Project” previamente cargada.

Una vez más, si corremos la aplicación con el “debugger” y nos paramos dentro del método “initializeResult” veremos que el tipo de la propiedad “tasks” ha cambiado de “ArrayProxy” a “Array”, conteniendo las instancias de “Tasks” asociadas.

El código fuente del la aplicación, cliente y servidor se puede descargar de aquí.

Conclusiones

Hemos visto como Pimento Data Services nos permite hacer “lazy loading” de entidades directamente desde ActionScript de una forma verdaderamente simple. Tan solo debemos poner las anotaciones en la entidad Java y el framework se encarga del resto, es una lástima que Pimento y Cinnamon no soporten ninguna funcionalidad que permita hacer sincronización de datos entre varios clientes. ¿Alguien se anima?

Al crear componentes en Flex, siempre deberíamos tener en mente la optimización: un componente más ligero ocupará menos memoria y repercutirá positivamente en la respuesta de la aplicación. Es un punto importantísimo, aunque, a menudo, no lo tengamos en cuenta, posiblemente debido a que cada vez tenemos equipos más potentes.
Es necesario si queremos tender a una programación que no exija un consumo de memoria excesivo y que no perjudique la performance de la aplicación, y es imprescindible para desarrollar aplicaciones con Flex para mobile devices.

Distintos tutoriales de Flex 4 explican que para crear componentes custom, extendamos SkinnableComponent, le demos el comportamiento deseado, tratemos los eventos y estados del componente y que finalmente creemos la skin para tener la representación visual del componente.

Después de leer varios artículos he descubierto unas clases que pueden ayudar a la creación de componentes gráficos custom y que quisiera compartir con vosotros.

SpriteVisualElement

Una de las clases de las que quiero hablar en este post es SpriteVisualElement.

Comparación entre SpriteVisualElement y UIComponent

Comparando esta clase con UIComponent, que es la clase base que se suele usar para componentes visuales, tanto los interactivos, como los que no, vemos que SpriteVisualElement parece ser más light-weight, ya no sólo pro el número de líneas que contiene esta clase (2900 aprox. UIComponent tiene unas 13000), sino por el número de interfaces que deben implementar cada una (SpriteVisualElement implementa 3 interfaces, UIComponent implementa 16).

UIComponent aporta más características, pero si no las necesitamos, SpriteVisualElement es la clase base ideal.

En la página de SpriteVisualElement dentro de la Language Reference, se describe como la clase más ligera para las implementaciones basadas en Sprite de la interface IVisualElement y que los layouts Spark pueden gestionar objetos de este tipo.

Si usamos ActionScript para añadir un componente FXG a nuestra aplicación, éste debe ser de tipo SpriteVisualElement. IVisualElement proporciona las constraints de layout tal que height, width, top, right, bottom, left…

Otro punto importante es que al ser una clase hija de Sprite, tiene las características de cualquier Flash interactive object, es un Sprite que puede ser usado en arquitecturas Spark.

Creación de un Custom SpriteVisualElement component

El proyecto que adjunto viene a ser como un cronómetro: haciendo click sobre él, podemos ponerlo en marcha o pararlo.

Pasos en la vida del componente

Al crear custom components debemos tener muy en cuenta el ciclo de vida del componente, y en este caso las dimensiones y layout del componente, importante a la hora de redibujarlo. Durante el proceso de layout del componente, Spark hace una llamada a setLayoutBoundsSize(width, height, postLayoutTransform), que determina las dimensiones del componente en la disposición de éste, es decir, las dimensiones que usa para dibujarse.
La llamada a setLayoutBoundsSize puede afectar a la posición del layout. Podemos llamar setLayoutBoundPosition() después de haber llamado a setLayoutBoundSize() para reubicar el componente.
En el código de ejemplo la función setLayoutBoundsSize ha sido sobrescrita:

Cuando el componente cambie una propiedad que afecte a su distribución y repintado, debemos invalidarlo para que Flex lo redibuje. Lo haremos con invalidateParentSizeAndDisplayList().

Al producirse esta invalidación, Flex lanza la función setLayoutBoundsSize para repintar el componente con los nuevos cambios en las propiedades.

GraphicElement

Es una clase más ligera que SpriteVisualElement, poniéndose, en cuanto a jerarquía, al nivel de DisplayObject. Es la clase base para definir un elemento gráfico, como shapes, text o images. Al definir un objeto gráfico, debemos especificar las dimensiones del elemento, pero no nos permite usar una especificación de éstas en valores porcentuales.

En este ejemplo,el autor nos muestra un uso adecuado de esta clase.

Debemos tener claros dos conceptos: las fronteras que delimita un determinado objeto dentro del espacio de coordenadas del padre y las fronteras que delimita dentro de su propio espacio de coordenadas.

Para hacer transformaciones necesitamos la clase Matrix, lo que sobrescribe valores de transformación previamente definidos como rotation, scaleX, scaleY, x e y. Si setteamos transform.matrix o las propiedades de transformación en ActionScript, se usarán los últimos valores aplicados.

La responsabilidad de la clase GraphicElement y sus subclases es la de dibujar componentes gráficos Spark, componentes FXG que parten de GraphicElement.

No confundir GraphicElement con DisplayObject, ya que la primera no nos da ningún tipo de interacción. GraphicElement usa un DisplayObject interno para dibujarse. Dentro del mismo display object podemos dibujar varios elementos gráficos. Así reducimos sobrecarga y damos un mayor rendimiento.

Será necesario implementar ciertas interfaces como IVisualElement y IGraphicElement y así poder ser dibujada y dispuesta por Spark.

Puntos claves de GraphicElement:

• GraphicElement usa un DisplayObject, que puede ser compartido, para dibujar dentro de él.
• Cuando un GraphicElement necesita ser repintado, todos los elementos gráficos que comparten el mismo DisplayObject se redibujan.
• Al crear un GraphicElement que comparte un display object con otros elementos gráficos, debemos asegurarnos de no hacer un clear de la instancia graphics, esto eliminaría las anteriores representaciones hechas por otros elementos.
• Si aplicamos ciertas propiedades al DisplayObject, éstas serán aplicadas a todos los elementos gráficos que compartan este display object. Esto implica que el uso de filtros, transformaciones, etc., a una determinada instancia, requieren que el GraphicElement tenga su display object propio. Con la implementación estándar lo solucionamos.
• GraphicElement necesita acceder a una instancia de graphics para dibujar. Podemos extraer esta referencia de la propiedad drawnDisplayObject de GraphicElement.
• Al dibujar, debemos tener en cuenta el desplazamiento del elemento gráfico en relación a su objeto de visualización.

Creación de un custom GraphicElement

Con FXG y el elemento Path, dibujamos la mayoría de elementos gráficos. Un Path se representa en un display object. A veces nos será más fácil crear elementos gráficos con GraphicElement, sobre todo cuando el elemento a dibujar es dinámico en cuando a cambio en su forma.

Al crear un GraphicElement custom debemos considerar lo siguiente:

• Sobrescribir la function updateDisplayList() para refrescar el dibujado del elemento.
• Usar una instancia de graphics para dibujar: (drawnDisplayObject as Sprite).graphics.
• Respetar las coordenadas del objeto GraphicElement en relación de su DisplayObject, mediante las propiedades drawX y drawY de la clase GraphicElement.
• La función que dibuje el elemento no puede hacer un clear de graphics, ya que el DisplayObject asociado puede ser compartido y esto provoca el borrado de los gráficos de otros elementos.
• GraphicElement implementa la interface IInvalidating para tomar parte en el proceso de invalidación. Si una propiedad que afecta al repintado del elemento es setteada, debemos invalidar este elemento y actualizarlo en el paso de validación.

Control del display object compartido

El control de los display objects asociados a un GraphicElement lo hace Flex. Si necesitamos manipular personalmente el DisplayObject en lugar de dejárselo a Flex, se nos ofrece diferentes vías:

• needsDisplayObject() nos permite determinar si el GraphicElement necesita su propio display object. La implementación por defecto comprueba si hay propiedades que requieren un display object propio (rotation, color transformation, blend modes, etc.).
• canShareWithNext() dice si el display object puede compartirse con el siguiente IGraphicElement de la secuencia.
• canShareWithPrevious() nos dice si el display object puede compartirse con el anterior IGraphicElement de la secuencia.
• Cuidado con el uso de displaySharingMode. No funciona como se espera, ya que Flex la usa para administrar los objetos. Si la usamos, los valores se sobrescribirán manualmente.
• Si Flex necesita crear un display object para un determinado GraphicElement, invoca la función itscreateDisplayObject(). La implementación por defecto nos devuelve un objeto de tipo InvalidatingSprite que implementa la interface ISharedDisplayObject.

Interacción

GraphicElement tiene como finalidad dibujar gráficos de manera optimizada, compartiendo display objects. No está pensado como elemento de interacción, el elemento se incrusta en el container Spark y la interacción debe hacerse a través del container.

Para permitir que un GraphicElement tenga interacción directa, debemos llevar a cabo ciertos aspectos que en muchos casos se consideran malas prácticas. Vamos a ver como conseguirlo.
El DisplayObject que usa el GraphicElement para dibujarse, es un InvalidatingSprite, que tiene las propiedades mouseEnabled y mouseChildren a false. Esto hace que la interactividad esté desactivada.
Debemos habilitar la interactividad en el element InvalidatingSprite y deshabilitar que el display object sea compartido para evitar que el repintado de otros elementos gráficos pueda afectar a este. Para ello es necesario:

• Subreescribir la function createDisplayObject()
• Settear mouseEnbled y mouseChildren del DisplayObject creado a true
• Añadir event listeners al DisplayObject
• Sobreescribir needsDisplayObject() y devolver true
• Sobreescribir canShareWithNext() y canShareWithPrevious() y devolver false

Conclusiones

SpriteVisualElement es una clase a tener en cuenta cuando queremos crear componentes gráficos ligeros, ya que los containers Spark aceptan elementos de este tipo y se pueden usar dentro de skins o combinarlos con FXG.
Por otro lado, la clase GraphicElement nos permite crear elementos gráficos muy optimizados, pero, como hemos visto, tiene la interactividad limitada.

Si necesitamos interacción directa con un elemento gráfico, es mejor usar SpriteVisualElement, que es un objeto interactivo (extiende de InteractiveObject).

]]> http://www.madeinflex.com/2010/10/23/clases-spark-para-crear-componentes-ligeros/feed/ 2 http://www.madeinflex.com/2010/08/13/autenticacion-en-aplicaciones-flex-con-spring-security-3/ http://www.madeinflex.com/2010/08/13/autenticacion-en-aplicaciones-flex-con-spring-security-3/#comments Thu, 12 Aug 2010 23:05:05 +0000 Nono F. Carballo Escalona http://www.madeinflex.com/?p=1679 El back-end La aplicación Flex Más información del usuario en Flex Conclusiones Spring Security es un framework que se centra en proveer mecanismos de autenticación y autorización para aplicaciones basadas en Spring. Mediante el paquete de integración de Spring con BlazeDS spring-flex, conjuntamente con Spring Security, podemos añadir seguridad a nuestras aplicaciones Flex/BlazeDS. En este artículo veremos, a través de [...]]]>




1. El back-end
2. La aplicación Flex
3. Más información del usuario en Flex
4. Conclusiones

Spring Security es un framework que se centra en proveer mecanismos de autenticación y autorización para aplicaciones basadas en Spring. Mediante el paquete de integración de Spring con BlazeDS spring-flex, conjuntamente con Spring Security, podemos añadir seguridad a nuestras aplicaciones Flex/BlazeDS.

En este artículo veremos, a través de un ejemplo, cómo podemos utilizar el mecanismo de autenticación de Spring Security desde una aplicación Flex. En la aplicación que desarrollaremos tenemos la información de los usuarios y los roles asignados a éstos en una base de datos MySQL, a la cual accederemos utilizando JPA e Hibernate. Desde Flex invocaremos el servicio de autenticación de Spring Security, el cual utilizará la información de los usuarios y roles en la base de datos para comprobar las credenciales de usuario suministradas, si el proceso termina exitosamente tendremos en la aplicación Flex la información del usuario autenticado, en caso contrario se nos notificará del error.

Para el desarrollo de la aplicación utilizaremos:

• Spring 3.0.2
• Spring Security 3.0.3
• Spring-Flex 1.5.0.M1
• BlazeDS 4.0.0.14931
• Flex 4
• Flash Builder 4 plugin en Eclipse IDE for J2EE (Galileo)
• RobotLegs 1.1.2

La aplicación la desarrollaremos en dos proyectos, un proyecto Web J2EE para el back-end y un proyecto Flex para la interface visual.

El back-end

Comenzaremos por la creación del proyecto Web J2EE

1. File … Import … Web->War File
2. WAR File: El camino del archivo blazeds.war
3. Web Project: FlexSpringSecurity
4. Target Runtime: Alguno que se haya configurado previamente
5. War Import: Web Libraries. No seleccionamos ningún paquete

Copiamos en la carpeta WebContent\WEB-INF\lib los archivos de Spring, Spring Security, Spring-Flex, el driver JDBC de MySQL. El listado de los archivos de la carpeta se puede ver aquí.

Como utilizamos el paquete de integración de Spring con BlazeDS solamente necesitamos en la carpeta WebContent\WEB-INF\flex el archivo services-config.xml. También necesitamos modificar el archivo web.xml en WebContent\WEB-INF, en el que se hace referencia a los archivos web-application-config.xml y web-application-context-config.xml, donde se configura el contexto de Spring.

Comenzaremos por crear la capa que accederá a la base de datos para obtener la información de usuarios y roles.

User.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.valueobject;
2.  
3. import java.util.List;
4.  
5. import javax.persistence.CascadeType;
6. import javax.persistence.Entity;
7. import javax.persistence.FetchType;
8. import javax.persistence.GeneratedValue;
9. import javax.persistence.Id;
10. import javax.persistence.ManyToMany;
11.  
12. @Entity
13. public class User {
14.  
15.     private Long id;
16.     private String fullName;
17.     private String userName;
18.     private String password;
19.  
20.     @Id
21.     @GeneratedValue
22.     public Long getId() {
23.         return id;
24.     }
25.  
26.     public void setId(Long id) {
27.         this.id = id;
28.     }
29.  
30.     public String getFullName() {
31.         return fullName;
32.     }
33.  
34.     public void setFullName(String fullName) {
35.         this.fullName = fullName;
36.     }
37.  
38.     public String getUserName() {
39.         return userName;
40.     }
41.  
42.     public void setUserName(String userName) {
43.         this.userName = userName;
44.     }
45.  
46.     public String getPassword() {
47.         return password;
48.     }
49.  
50.     public void setPassword(String password) {
51.         this.password = password;
52.     }
53.    
54.     private List<Role> roleList;
55.  
56.     @ManyToMany(cascade=CascadeType.ALL, fetch=FetchType.LAZY)
57.     public List<Role> getRoleList() {
58.         return roleList;
59.     }
60.  
61.     public void setRoleList(List<Role> roleList) {
62.         this.roleList = roleList;
63.     }
64. }

Role.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.valueobject;
2.  
3. import javax.persistence.Entity;
4. import javax.persistence.GeneratedValue;
5. import javax.persistence.Id;
6.  
7. @Entity
8. public class Role {
9.  
10.     private Long id;
11.     private String name;
12.  
13.     @Id
14.     @GeneratedValue
15.     public Long getId() {
16.         return id;
17.     }
18.  
19.     public void setId(Long id) {
20.         this.id = id;
21.     }
22.  
23.     public String getName() {
24.         return name;
25.     }
26.  
27.     public void setName(String name) {
28.         this.name = name;
29.     }
30. }

RoleType.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.valueobject;
2.  
3. public class RoleType {
4.     public static final String ADMIN = "ADMINISTRATOR";
5.     public static final String USER = "USER";
6.     public static final String GEST = "GEST";
7. }

IUserService.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.service;
2.  
3. import java.util.List;
4. import com.nonocarballo.flexspringsecurity.valueobject.User;
5.  
6. public interface IUserService {
7.     public List<User> loadAllUsers();
8.     public void addUser(User user);
9.     public User loabByUserName(String username);
10. }

UserService.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.service.impl;
2.  
3. import java.util.List;
4. import javax.persistence.EntityManager;
5. import javax.persistence.PersistenceContext;
6. import javax.persistence.PersistenceContextType;
7. import javax.persistence.Query;
8.  
9. import org.springframework.flex.remoting.RemotingDestination;
10. import org.springframework.flex.remoting.RemotingExclude;
11. import org.springframework.stereotype.Repository;
12. import org.springframework.transaction.annotation.Transactional;
13.  
14. import com.nonocarballo.flexspringsecurity.service.IUserService;
15. import com.nonocarballo.flexspringsecurity.valueobject.User;
16.  
17. @Repository
18. @RemotingDestination
19. public class UserService implements IUserService {
20.  
21.     private EntityManager entityManager;
22.    
23.     @RemotingExclude
24.     public EntityManager getEntityManager() {
25.         return entityManager;
26.     }
27.  
28.     @RemotingExclude
29.     @PersistenceContext(type = PersistenceContextType.EXTENDED)
30.     public void setEntityManager(EntityManager entityManager) {
31.         this.entityManager = entityManager;
32.     }
33.  
34.     @SuppressWarnings("unchecked")
35.     @Override
36.     public List<User> loadAllUsers() {
37.         // TODO Auto-generated method stub
38.         return entityManager.createQuery("from User u").getResultList();
39.     }
40.  
41.     @Override
42.     @Transactional
43.     public User loabByUserName(String username) {
44.         Query userQuery = entityManager.createQuery("from User u where u.userName = :user");
45.         userQuery.setParameter("user", username);
46.         User user = (User) userQuery.getSingleResult();
47.         return user;
48.     }
49.  
50.     @Override
51.     @Transactional
52.     public void addUser(User user) {
53.         // TODO Auto-generated method stub
54.         entityManager.persist(user);       
55.     }
56. }

Escribimos ahora un código en forma de test para generar las tablas de la base de datos y llenarlas con alguna información.

UserServiceTest.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.test;
2.  
3. import static org.junit.Assert.*;
4.  
5. import java.util.ArrayList;
6.  
7. import org.junit.Test;
8. import org.junit.runner.RunWith;
9. import org.springframework.beans.factory.annotation.Autowired;
10. import org.springframework.test.context.ContextConfiguration;
11. import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
12.  
13. import com.nonocarballo.flexspringsecurity.service.IUserService;
14. import com.nonocarballo.flexspringsecurity.valueobject.Role;
15. import com.nonocarballo.flexspringsecurity.valueobject.RoleType;
16. import com.nonocarballo.flexspringsecurity.valueobject.User;
17.  
18. @RunWith(SpringJUnit4ClassRunner.class)
19. @ContextConfiguration(locations={"classpath:/spring/web-application-context-config.xml"})
20. public class UserServiceTest {
21.  
22.     private IUserService userService;
23.  
24.     public IUserService getUserService() {
25.         return userService;
26.     }
27.  
28.     @Autowired
29.     public void setUserService(IUserService userService) {
30.         this.userService = userService;
31.     }
32.    
33.     @Test
34.     public void addUserTest(){
35.        
36.         User user = new User();
37.         user.setFullName("Nono Carballo Escalona");
38.         user.setUserName("nono");
39.         user.setPassword("mypassword");
40.        
41.         ArrayList<Role> roleList = new ArrayList<Role>();
42.        
43.         Role role = new Role();  
44.         role.setName(RoleType.GEST);
45.         roleList.add(role);
46.        
47.         role = new Role();   
48.         role.setName(RoleType.USER);
49.         roleList.add(role);
50.        
51.         role = new Role();   
52.         role.setName(RoleType.ADMIN);
53.         roleList.add(role);
54.        
55.         user.setRoleList(roleList);
56.        
57.         userService.addUser(user);
58.        
59.         user = new User();
60.         user.setFullName("Nono Carballo Escalona1");
61.         user.setUserName("nono1");
62.         user.setPassword("mypassword1");
63.        
64.         roleList = new ArrayList<Role>();
65.        
66.         role = new Role();   
67.         role.setName(RoleType.GEST);
68.         roleList.add(role);
69.        
70.         user.setRoleList(roleList);
71.        
72.         userService.addUser(user);
73.        
74.         user = new User();
75.         user.setFullName("Nono Carballo Escalona2");
76.         user.setUserName("nono2");
77.         user.setPassword("mypassword2");
78.        
79.         roleList = new ArrayList<Role>();
80.        
81.         role = new Role();   
82.         role.setName(RoleType.USER);
83.         roleList.add(role);
84.        
85.         user.setRoleList(roleList);
86.        
87.         userService.addUser(user);
88.        
89.         ArrayList<User> userList = (ArrayList<User>) userService.loadAllUsers();
90.        
91.         assertTrue(userList.size() == 3);
92.        
93.     }
94. }

Para la interacción entre spring-flex y Spring Security debe registrarse en el archivo web.xml el un filtro del tipo DelegatingFilterProxy.

PLAIN TEXT
XML:
1. <filter>
2.         <filter-name>springSecurityFilterChain</filter-name>
3.         <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
4. </filter>
5.    
6. <filter-mapping>
7.         <filter-name>springSecurityFilterChain</filter-name>
8.         <url-pattern>/*</url-pattern>
9. </filter-mapping>

Debemos crear una clase a través de la cual Spring Security recuperará de la base de datos la información del usuario que intenta autenticarse. Esta clase implementará la interface UserDetailsService, que tiene un único método, loadUserByUsername, el cual será invocado por el proveedor de autenticación del framework.

MyUserDetailsService.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.service;
2.  
3. import java.util.ArrayList;
4. import java.util.List;
5.  
6. import org.apache.commons.logging.Log;
7. import org.apache.commons.logging.LogFactory;
8. import org.springframework.beans.factory.annotation.Autowired;
9. import org.springframework.dao.DataAccessException;
10. import org.springframework.security.core.GrantedAuthority;
11. import org.springframework.security.core.authority.GrantedAuthorityImpl;
12. import org.springframework.security.core.userdetails.UserDetails;
13. import org.springframework.security.core.userdetails.UserDetailsService;
14. import org.springframework.security.core.userdetails.UsernameNotFoundException;
15. import org.springframework.stereotype.Repository;
16. import org.springframework.transaction.annotation.Transactional;
17.  
18. import com.nonocarballo.flexspringsecurity.valueobject.AuthenticatedUser;
19. import com.nonocarballo.flexspringsecurity.valueobject.Role;
20. import com.nonocarballo.flexspringsecurity.valueobject.User;
21.  
22. @Repository
23. public class MyUserDetailsService implements UserDetailsService {
24.    
25.     private IUserService userService;
26.  
27.     public IUserService getUserService() {
28.         return userService;
29.     }
30.  
31.     @Autowired
32.     public void setUserService(IUserService userService) {
33.         this.userService = userService;
34.     }
35.  
36.     @Override
37.     @Transactional
38.     public UserDetails loadUserByUsername(String arg0)
39.             throws UsernameNotFoundException, DataAccessException {
40.         User user = userService.loabByUserName(arg0);
41.         if(user == null){
42.             throw new
43. UsernameNotFoundException("User "+arg0+" not found.");
44.         }
45.         List<Role> roleList=(List<Role>) user.getRoleList();
46.         ArrayList<GrantedAuthority> grantedAuthorities = new
47.  ArrayList<GrantedAuthority>();
48.         for(Role role : roleList){
49.             grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
50.         }
51.         return new
52.  org.springframework.security.core.userdetails.User(user.getUserName(),
53.                 user.getPassword(), true, true, true, true, grantedAuthorities);
54.        
55.     }
56. }

El objeto de tipo org.springframework.security.core.userdetails.User contiene la información que llegará a la aplicación Flex, en este caso el nombre de usuario y los roles que tiene asignados.

Ahora debemos informar a Spring Security que use nuestra clase y no la que trae el framework, esto se hace en el archivo web-application-context-config.xml, la configuración final queda como sigue:

PLAIN TEXT
XML:
1. <security:http entry-point-ref="entryPoint">
2.  <security:anonymous enabled="false"/>
3.  </security:http>
4.    
5.  <bean id="entryPoint" class="org.springframework.security.web.authentication.Http403ForbiddenEntryPoint"/>
6.  
7. <security:authentication-manager>
8.     <security:authentication-provider user-service-ref="myUserDetailsService"/>
9. </security:authentication-manager>

Y finalmente de debemos informar a spring-flex (en el archivo web-application-config.xml) que utilice el servicio de autenticación de Spring Security.

PLAIN TEXT
XML:
1. <flex:message-broker>   
2.     <flex:secured />
3. </flex:message-broker>

La aplicación Flex

Crearemos un proyecto Flex que llamaremos FlexSpringSecurityUI con las siguientes características:

• Application Type: Web
• Flex SDK Version: Flex 4.0
• Application Server Type: J2EE
• Remote access service: BlazeDS
• RootFolder: el camino a la carpeta FlexSecurity/WebContent
• Root URL: el URL donde se desplegó el proyecto FlexSpringSecurity
• Context root: flexspringsecurity

Nuestra aplicación Flex contendrá un formulario para autenticación y un botón para entrar (login) y salir (logout).



Crearemos un objeto de tipo ChannelSet y le adicionaremos un canal de tipo AMFChannel, luego para invocar al servicio de autenticación de Spring Security desde Flex utilizaremos el método login de lal objeto ChannelSet, lo invocaremos pasándole como argumentos el nombre de usuario y la contraseña introducidos en el formulario. En esta aplicación recuperaremos el URL donde está desplegado el back-end en tiempo de ejecución, desde un archivo xml, y utilizaremos esa información para crear programáticamente el canal e insertarlo en el ChannelSet. Nos auxiliaremos del framework Robotlegs.

channels.xml

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <channels>
3.     <channel type="amf">
4.         <uri>http://localhost:8080/flexspringsecurity</uri>
5.     </channel>
6.     <channel type="secure-amf">
7.         <uri>https://localhost:8080/flexspringsecurity</uri>
8.     </channel>
9. </channels>
PLAIN TEXT
Actionscript 3:
1. package com.nonocarballo.flexspringsecurity.command
2. {
3.     import mx.messaging.ChannelSet;
4.     import mx.messaging.channels.AMFChannel;
5.     import mx.rpc.CallResponder;
6.     import mx.rpc.events.ResultEvent;
7.     import mx.rpc.http.HTTPService;
8.    
9.     import org.robotlegs.mvcs.Command;
10.    
11.     public class LoadConfigCommand extends Command
12.     {
13.         public function LoadConfigCommand()
14.         {
15.             super();
16.         }
17.        
18.         private var responder:CallResponder = new CallResponder();
19.        
20.         override public function execute():void{
21.             var service:HTTPService = new HTTPService();
22.             service.url = "config/channels.xml";
23.             service.resultFormat = "e4x";
24.            
25.             responder.addEventListener(ResultEvent.RESULT, resultHandler);
26.             responder.token = service.send();
27.         }
28.        
29.         private function resultHandler(event: ResultEvent):void{
30.             var xml:XML = event.result as XML;
31.            
32.             var channelSet:ChannelSet = new ChannelSet();
33.             for each(var item:XML in xml..channel){
34.                 if(item.@type=="amf"){
35.                     var amfChannel:AMFChannel = new AMFChannel();
36.                     amfChannel.uri = item.uri+"/messagebroker/amf";
37.                     channelSet.addChannel(amfChannel);
38.                     break;
39.                 }
40.             }
41.             injector.mapValue(ChannelSet, channelSet);
42.         }
43.     }
44. }

Cuando presionamos el botón “Entrar” invocamos el método login del objeto ChannelSet con la credencial del usuario:

PLAIN TEXT
Actionscript 3:
1. package com.nonocarballo.flexspringsecurity.command
2. {
3.     import com.nonocarballo.flexspringsecurity.event.AuthenticatedEvent;
4.     import com.nonocarballo.flexspringsecurity.event.LoginEvent;
5.    
6.     import flash.events.Event;
7.    
8.     import mx.messaging.ChannelSet;
9.     import mx.rpc.CallResponder;
10.     import mx.rpc.events.FaultEvent;
11.     import mx.rpc.events.ResultEvent;
12.    
13.     import org.robotlegs.mvcs.Command;
14.    
15.     public class LoginCommand extends Command
16.     {
17.         public function LoginCommand()
18.         {
19.             super();
20.         }
21.        
22.         [Inject]
23.         public var channelSet:ChannelSet;
24.        
25.         [Inject]
26.         public var event:LoginEvent;
27.        
28.         private var responder:CallResponder = new CallResponder();
29.        
30.         override public function execute():void{
31.             if(!channelSet.authenticated){
32.                 responder.addEventListener(ResultEvent.RESULT, resultHandler);
33.                 responder.addEventListener(FaultEvent.FAULT, faultHandler);
34.                 responder.token = channelSet.login(event.username,
35. event.password);
36.             }
37.         }
38.        
39.         private function resultHandler(event:ResultEvent):void{
40.             dispatch(new AuthenticatedEvent(AuthenticatedEvent.AUTHENTICATED,
41. event.result));
42.         }
43.        
44.         private function faultHandler(event:FaultEvent):void{
45.             dispatch(new AuthenticatedEvent(AuthenticatedEvent.LOGIN_FAILURE));
46.         }
47.     }
48. }

Si la credencial de usuario no es válida obtendremos:



En caso contrario:



Más información del usuario en Flex

Con el objeto org.springframework.security.core.userdetails.User solo obtenemos información del nombre de usuario y los roles, pero casi nunca esa información es suficiente. Haremos los cambios necesarios para poder traer hacia la aplicación Flex información extra del usuario que se ha autenticado.

Primeramente debemos crear nuestra propia implementación de UserDetails y añadir toda la información que necesitemos, en nuestro caso solo añadimos el nombre completo del usuario (fullname).

AuthenticatedUser.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.valueobject;
2.  
3. import java.util.Collection;
4.  
5. import org.springframework.security.core.GrantedAuthority;
6. import org.springframework.security.core.userdetails.UserDetails;
7.  
8. @SuppressWarnings("serial")
9. public class AuthenticatedUser implements UserDetails {
10.  
11.     private String username;
12.     private String password;
13.     private String fullname;
14.    
15.    
16.     public String getFullname() {
17.         return fullname;
18.     }
19.  
20.     private Collection<GrantedAuthority> authorities;
21.    
22.     @Override
23.     public Collection<GrantedAuthority> getAuthorities() {
24.         // TODO Auto-generated method stub
25.         return authorities;
26.     }
27.  
28.     @Override
29.     public String getPassword() {
30.         // TODO Auto-generated method stub
31.         return password;
32.     }
33.  
34.     @Override
35.     public String getUsername() {
36.         // TODO Auto-generated method stub
37.         return username;
38.     }
39.  
40.     @Override
41.     public boolean isAccountNonExpired() {
42.         // TODO Auto-generated method stub
43.         return true;
44.     }
45.  
46.     @Override
47.     public boolean isAccountNonLocked() {
48.         // TODO Auto-generated method stub
49.         return true;
50.     }
51.  
52.     @Override
53.     public boolean isCredentialsNonExpired() {
54.         // TODO Auto-generated method stub
55.         return true;
56.     }
57.  
58.     @Override
59.     public boolean isEnabled() {
60.         // TODO Auto-generated method stub
61.         return true;
62.     }
63.  
64.     public AuthenticatedUser() {
65.         super();
66.         // TODO Auto-generated constructor stub
67.     }
68.  
69.     public AuthenticatedUser(String username, String fullname, String password,
70.             Collection<GrantedAuthority> authorities) {
71.         super();
72.         this.username = username;
73.         this.fullname = fullname;
74.         this.password = password;
75.         this.authorities = authorities;
76.     }
77. }

Luego necesitamos crear nuestro propio interceptor de mensaje implementando MessageInterceptor. Esta clase es la encargada de extraer del resultado del proceso de autenticación la información que llegará a la aplicación Flex una vez concluido éste exitosamente.

MyLoginMessageInterceptor.java

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.service;
2.  
3. import org.apache.commons.logging.Log;
4. import org.apache.commons.logging.LogFactory;
5. import org.springframework.flex.core.MessageInterceptor;
6. import org.springframework.flex.core.MessageProcessingContext;
7. import org.springframework.stereotype.Service;
8.  
9. import flex.messaging.messages.CommandMessage;
10. import flex.messaging.messages.Message;
11.  
12. @Service
13. public class MyLoginMessageInterceptor implements MessageInterceptor {
14.  
15.     private final Log logger = LogFactory.getLog(getClass());
16.     
17.     @Override
18. public Message postProcess(MessageProcessingContext context, Message inputMessage,
19.             Message outputMessage) {
20.         // TODO Auto-generated method stub
21.         if (inputMessage instanceof CommandMessage &&
22. ((CommandMessage) inputMessage).getOperation() ==
23. CommandMessage.LOGIN_OPERATION) {
24.             if (outputMessage.getBody()!= null) {
25.                 outputMessage.setBody(
26. MyAuthenticationResultUtils.getAuthenticationResult());
27. }
28. }
29. return outputMessage;
30.     }
31.  
32.     @Override
33.     public Message preProcess(MessageProcessingContext context, Message inputMessage) {
34.         // TODO Auto-generated method stub
35.         return inputMessage;
36.     }
37.  
38. }

Como vemos, esta clase hace uso de MyAuthenticationResultUtils, la cual crearemos también, y donde ocurre la creación del objeto que llegará a la aplicación Flex en la propiedad result de la clase ResultEvent.

PLAIN TEXT
JAVA:
1. package com.nonocarballo.flexspringsecurity.service;
2.  
3. import java.util.HashMap;
4. import java.util.Map;
5.  
6. import org.springframework.security.core.Authentication;
7. import org.springframework.security.core.GrantedAuthority;
8. import org.springframework.security.core.context.SecurityContextHolder;
9.  
10. import com.nonocarballo.flexspringsecurity.valueobject.AuthenticatedUser;
11.  
12. public abstract class MyAuthenticationResultUtils {
13.  
14.     public static Map<String, Object> getAuthenticationResult() {
15.         Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
16.         if (authentication == null) {
17.             return null;
18.         }
19.         Map<String, Object> authenticationResult = new HashMap<String, Object>();
20.         authenticationResult.put("name", authentication.getName());
21.         String[] authorities = new String[authentication.getAuthorities().size()];
22.         int i=0;
23.         for (GrantedAuthority granted : authentication.getAuthorities()) {
24.             authorities[i++] = granted.getAuthority();
25.         }
26.         authenticationResult.put("authorities", authorities);
27.         authenticationResult.put("fullname", ((AuthenticatedUser)authentication.getPrincipal()).getFullname());
28.         return authenticationResult;
29.     }
30. }

Finalmente debemos registrar nuestro interceptor de mensaje personalizado:

PLAIN TEXT
XML:
1. <flex:message-broker>
2.         <flex:message-interceptor ref="myLoginMessageInterceptor"/>
3.         <flex:secured />
4. </flex:message-broker>

Cuando nos autenticamos nuevamente obtenemos:



El código fuente de los proyectos se puede descargar aquí.

Conclusiones

Spring Security provee un mecanismo flexible de autenticación (y control de acceso) para aplicaciones basadas en Spring. En nuestra aplicación de ejemplo utilizamos JPA e Hibernate para acceder a la información de los usuarios.

Utilizando el paquete de integración de Spring con BlazeDS y Spring Security podemos implementar mecanismos de autenticación en nuestras aplicaciones Flex/BlazeDS.

]]> http://www.madeinflex.com/2010/08/13/autenticacion-en-aplicaciones-flex-con-spring-security-3/feed/ 8 http://www.madeinflex.com/2010/07/13/utilizando-robotlegs-para-el-desarrollo-de-aplicaciones-flex/ http://www.madeinflex.com/2010/07/13/utilizando-robotlegs-para-el-desarrollo-de-aplicaciones-flex/#comments Tue, 13 Jul 2010 07:33:04 +0000 Nono F. Carballo Escalona http://www.madeinflex.com/?p=1506 Principio de funcionamiento El funcionamiento a través de un ejemplo Conclusiones Robotlegs es una microarquitectura escrita completamente en AS3 para el desarrollo de aplicaciones Flex, Flash y Air, cuyo principal objetivo es interconectar las diferentes partes de la aplicación y proveer un mecanismo para que se comuniquen, en este caso utiliza el sistema de mensajería nativo de Flex. El [...]]]>




1. Principio de funcionamiento
2. El funcionamiento a través de un ejemplo
3. Conclusiones

Robotlegs es una microarquitectura escrita completamente en AS3 para el desarrollo de aplicaciones Flex, Flash y Air, cuyo principal objetivo es interconectar las diferentes partes de la aplicación y proveer un mecanismo para que se comuniquen, en este caso utiliza el sistema de mensajería nativo de Flex.

El framework viene con una implementación de referencia basada en el patrón MVC+S que sirve de guía para estructurar la aplicación, que incluye las clases Mediator, Command y Actor (denominadas los actores del framework), y aunque no es obligatorio su uso constituye un punto de comienzo. La inyección de dependencias la realiza a través de la biblioteca SwiftSuspenders, aunque deja abierta la posibilidad de usar otras, los puntos de inyección de dependencias se indican declarativamente a través de metadata.

Principio de funcionamiento

La clase Context es el corazón del framework, sirve como un bus centralizado de eventos y permite que las implementaciones de las diferentes partes de la arquitectura se comuniquen entre sí. Es el mecanismo de arranque que inicializa la inyección de dependencias y otras utilidades del framework. El contexto define ámbito, los actores del framework viven dentro de un contexto y se comunican con otros que viven dentro del mismo ámbito de ese contexto. En una aplicación pueden existir varios contextos, y éstos pueden comunicarse entre sí, lo cual es muy útil para el desarrollo de aplicaciones modulares que requieren comunicación entre módulos.

La capa controladora se representa por la clase Command. Los comandos son objetos de corta vida, sin estado, que representan acciones individuales a ejecutar por la aplicación, comúnmente como respuesta a interacciones con el usuario pero su uso no está limitado a esto. Estos objetos pueden enviar eventos que pueden ser recibidos por mediadores para ejecutar acciones sobre las vistas, o que pueden desencadenar la ejecución de otros comandos.

La capa de la vista es representada por la clase Mediator. Las clases que heredan de Mediator se utilizan para controlar la interacción de los actores del framework con los componentes visuales. Los mediadores escuchan los eventos despachados por los actores del framework y en consecuencia modifican el estado del componente visual que representan, registran escuchadores de los eventos generados por el componente visual que representan y despachan además eventos como respuesta éstos. Esto permite poner la lógica del componente visual en el mediador y desacoplarlo al máximo de la aplicación, permitiendo su reutilización y modificación con el menor costo.

Para implementar la capa del modelo y de los servicios el framework ofrece la clase Actor. Cualquier clase que herede de Actor tiene la funcionalidad de comunicarse con el resto de los actores del framework.

El funcionamiento a través de un ejemplo

Para ejemplificar el funcionamiento de Robotlegs desarrollaremos un pequeño ejemplo en el que tendremos una vista compuesta por un botón y una tabla, al oprimir el botón recuperaremos un conjunto de datos en formato XML a través de una solicitud HTTP y los mostraremos en la tabla. Utilizaremos Flash Builder 4 y Robotlegs 1.1.1. Aunque el ejemplo es muy simple nos servirá para explorar cómo interactúan las diferentes partes de una aplicación que utilice Robotlegs.

Comenzaremos descargando el archivo robotlegs-framework-v1.1.1.zip de http://www.robotlegs.org y creando un proyecto Flex con las siguientes características:



Una vez creado el proyecto copiamos en la carpeta libs de proyecto el archivo “robotlegs-framework-v1.1.1.swc”, que se encuentra en la carpeta bin del archivo previamente descargado; y creamos la siguiente estructura en el proyecto:



A continuación procederemos a crear el único componente visual de la aplicación, al cual llamaremos CountryListView y se creará en la carpeta views del proyecto:



El código queda así:

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:VGroup xmlns:fx="http://ns.adobe.com/mxml/2009"
3.           xmlns:s="library://ns.adobe.com/flex/spark"
4.           xmlns:mx="library://ns.adobe.com/flex/mx"
5.           width="400" height="300"
6.           paddingLeft="10" paddingTop="10" paddingRight="10" paddingBottom="10">
7.    
8.     <fx:Declarations>
9.         <!-- Place non-visual elements (e.g., services, value objects) here -->
10.     </fx:Declarations>
11.    
12.     <s:Button label="Cargar Datos"
13.               click="dispatchEvent(new Event('LOAD_DATA'))"/>
14.    
15.     <mx:DataGrid id="country_dg"
16.                  width="100%" height="100%">
17.         <mx:columns>
18.             <mx:DataGridColumn headerText="Nombre" dataField="name"/>
19.             <mx:DataGridColumn headerText="Codigo" dataField="code"/>
20.         </mx:columns>
21.     </mx:DataGrid>
22. </s:VGroup>

Cuando se oprime el botón se despachará un evento que será atrapado por el mediador de este componente, el cual como respuesta despachará otro evento que desencadenará la ejecución de un comando.

Como vemos, este componente visual está totalmente desacoplado de la aplicación (no tiene enlaces –bindings- al modelo, etc.) y puede ser reutilizado y modificado sin incurrir en cambios en el código. Por supuesto que en un escenario real el componente seguramente será mucho más complejo, pero la idea es la misma.

El mediador será una clase que herede de la clase Mediator del framework y cuya responsabilidad será comunicarse con el resto de los actores de la aplicación e interactuar con el componente visual para actualizar su estado.

PLAIN TEXT
Actionscript 3:
1. package views
2. {
3.     import events.CountryListEvents;
4.    
5.     import flash.events.Event;
6.    
7.     import model.CountryListModel;
8.    
9.     import org.robotlegs.mvcs.Mediator;
10.    
11.     public class CountryListMediator extends Mediator
12.     {
13.         [Inject]
14.         public var view:CountryListView;
15.        
16.         [Inject]
17.         public var applicationModel:CountryListModel;
18.        
19.         public function CountryListMediator()
20.         {
21.             super();
22.         }
23.        
24.         override public function onRegister():void{
25.             addViewListener("LOAD_DATA", sendRequest);
26.             addContextListener(CountryListEvents.COUNTRY_DATA_LOADED, dataLoadedHandler);
27.         }
28.        
29.         private function sendRequest(event:Event):void{
30.             dispatch(new Event(CountryListEvents.LOAD_COUNTRY_DATA));
31.         }
32.        
33.         private function dataLoadedHandler(event:Event):void{
34.             view.country_dg.dataProvider = applicationModel.countryList;
35.         }
36.     }
37. }

En el método “onRegister”, el mediador registra los escuchadores tanto para los eventos despachados por el componente visual como para los eventos despachados por el resto de los actores del framework. El metadata “[Inject]” indica que el framework suministrará a las variables “view” y “applicationModel” referencias válidas de objetos de tipo “CountryListView” y “CountryListModel” respectivamente.

Cuando el mediador atrapa el evento despachado por el componente visual (LOAD_DATA), despacha el evento LOAD_COUNTRY_DATA, lo cual provoca que se ejecute el método “execute” del comando asociado a ese evento.
El comando, representado por la clase “LoadCountryData”, hereda de la clase Command del framework y es responsable de obtener los datos del archivo XML. Para este ejemplo se creó un servicio HTTP (CountryDataService) utilizando la funcionalidad de Data Centric Development de Flash Builder. El framework inyecta una referencia válida del servicio y el modelo cuando se crea un objeto de la clase “LoadCountryData”.

PLAIN TEXT
Actionscript 3:
1. package commands
2. {
3.     import model.CountryListModel;
4.    
5.     import mx.collections.ArrayCollection;
6.     import mx.rpc.CallResponder;
7.     import mx.rpc.events.FaultEvent;
8.     import mx.rpc.events.ResultEvent;
9.    
10.     import org.robotlegs.mvcs.Command;
11.    
12.     import services.countrydataservice.CountryDataService;
13.    
14.     import valueObjects.Country_list;
15.    
16.     public class LoadCountryData extends Command
17.     {
18.         [Inject]
19.         public var applicationModel:CountryListModel;
20.        
21.         [Inject]
22.         public var service:CountryDataService;
23.        
24.         public function LoadCountryData()
25.         {
26.             super();
27.         }
28.        
29.         private var responder:CallResponder = new CallResponder();
30.        
31.         override public function execute():void{
32.        
33.             responder.addEventListener(ResultEvent.RESULT, resultHandler);
34.             responder.token = service.getCountryData();
35.         }
36.        
37.         private function resultHandler(event:ResultEvent):void{
38.             applicationModel.countryList = (responder.lastResult as Country_list).country;
39.         }
40.        
41.     }
42. }

Cuando el servicio retorna (en el método “resultHandler”) se actualiza la lista de países en el modelo, lo cual provoca que se despache el evento COUNTRY_DATA_LOADED, el cual es atrapado por el mediador y este, en respuesta, actualiza el componente visual.

El modelo está representado en la clase “CountryListModel”, que almacena los datos de la aplicación, ésta hereda de la clase Actor del framework, la cual añade la funcionalidad básica para comunicarse con el resto de los actores.

PLAIN TEXT
Actionscript 3:
1. package model
2. {
3.     import events.CountryListEvents;
4.    
5.     import flash.events.Event;
6.    
7.     import mx.collections.ArrayCollection;
8.    
9.     import org.robotlegs.mvcs.Actor;
10.    
11.     public class CountryListModel extends Actor
12.     {
13.         public function CountryListModel()
14.         {
15.             super();
16.         }
17.        
18.         private var _countryList:ArrayCollection;
19.  
20.         public function get countryList():ArrayCollection
21.         {
22.             return _countryList;
23.         }
24.  
25.         public function set countryList(value:ArrayCollection):void
26.         {
27.             _countryList = value;
28.             dispatch(new Event(CountryListEvents.COUNTRY_DATA_LOADED));
29.         }
30.  
31.     }
32. }

Nótese que cuando se modifica la variable “countryList”, que almacena la lista de países, se despacha un evento (COUNTRY_DATA_LOADED), que es atrapado por el mediador, el cual en respuesta, actualiza el componente visual.

En este ejemplo, por razones de simplicidad, los eventos utilizados son de la clase “Event” de Flex, pero en un escenario real, lo más conveniente sería crear eventos personalizados que llevaran una carga útil de interés para la aplicación.

Finalmente el actor responsable de orquestar todo este trabajo es el contexto, representado por la clase “CountryListContext”, que hereda de la clase “Context” del framework.

PLAIN TEXT
Actionscript 3:
1. package
2. {
3.     import commands.LoadCountryData;
4.    
5.     import events.CountryListEvents;
6.    
7.     import flash.display.DisplayObjectContainer;
8.    
9.     import model.CountryListModel;
10.    
11.     import org.robotlegs.mvcs.Context;
12.    
13.     import services.countrydataservice.CountryDataService;
14.    
15.     import views.CountryListMediator;
16.     import views.CountryListView;
17.    
18.     public class CountryListContext extends Context
19.     {
20.         public function CountryListContext(contextView:DisplayObjectContainer=null, autoStartup:Boolean=true)
21.         {
22.             super(contextView, autoStartup);
23.         }
24.        
25.         override public function startup():void{
26.            
27.             injector.mapSingleton(CountryListModel);
28.             injector.mapSingleton(CountryDataService);
29.            
30.             commandMap.mapEvent(CountryListEvents.LOAD_COUNTRY_DATA, LoadCountryData);
31.             mediatorMap.mapView(CountryListView, CountryListMediator);
32.         }
33.     }
34. }

En el método “startup”, invocado cuando el dueño de este contexto se añade al stage, se realiza el trabajo de enlazar las diferentes partes de la aplicación.

En este caso, primeramente se indica al mecanismo de inyección que cree un singleton de las clases “CountryListModel” (el modelo) y “CountryDataService” (el servicio), cuyas referencias serán inyectadas en las clases “LoadCountryData” y “CountryListMediator” según sea necesario.

Luego se indica que para el evento LOAD_COUNTRY_DATA se registre el comando LoadCountryData. Esto hará que cuando algún actor del framework (en este ejemplo el mediador) despache un evento de ese tipo, se creará un objeto de tipo “LoadCountryData”, se inyectarán todas sus dependencias y se invocará el método execute.

Por último se indica que se registre como mediador del componente visual CountryListView la clase CountryListMediator. Esto provocará que cuando se añada el componente visual al stage, se creará una instancia de la clase “CountryListMediator”, se inyectarán sus dependencias y se invocará el método “onRegister”.

Finalmente se crea el contexto en la clase Application:

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
3.                xmlns:s="library://ns.adobe.com/flex/spark"
4.                xmlns:mx="library://ns.adobe.com/flex/mx"
5.                minWidth="955" minHeight="600" xmlns:views="views.*"
6.                xmlns:local="*">
7.    
8.     <fx:Declarations>
9.         <local:CountryListContext contextView="{this}"/>
10.     </fx:Declarations>
11.    
12.     <views:CountryListView/>
13. </s:Application>

Cuando ejecutamos la aplicación se obtiene lo siguiente:



El archivo XML con los datos se encuentra en la carpeta “data” del proyecto, el que se puede descargar de aquí.

Conclusiones

Robotlegs es un framework muy simple y compacto que ofrece una implementación de referencia del patrón MVC+S, nos permite crear aplicaciones Flex con bajo nivel de acoplamiento, componentes reutilizables y con una estructura que en proyectos grandes resulta de gran utilidad, nos permite aprovechar los beneficios de la Inversión de Control en nuestros proyectos.

]]> http://www.madeinflex.com/2010/07/13/utilizando-robotlegs-para-el-desarrollo-de-aplicaciones-flex/feed/ 7 http://www.madeinflex.com/2010/05/30/usando-data-centric-development-dcd-en-proyectos-flexjava-con-wtp/ http://www.madeinflex.com/2010/05/30/usando-data-centric-development-dcd-en-proyectos-flexjava-con-wtp/#comments Sun, 30 May 2010 12:12:22 +0000 Nono F. Carballo Escalona http://www.madeinflex.com/?p=1417 Introducción El problema La solución Conclusiones La instalación de Flash Builder 4 plug-in incluye el paquete Ganymede de Eclipse, pero podemos optar por instalarlo sobre una distribución de eclipse alternativa (y mas reciente), como el paquete Galileo del Eclipse IDE for Java EE Developers, el cual incluye Web Tools Platform (http://www.eclipse.org/home/categories/index.php?category=enterprise). Introducción Instalar Flash Builder 4 como plug-in del paquete Galileo [...]]]>




1. Introducción
2. El problema
3. La solución
4. Conclusiones

La instalación de Flash Builder 4 plug-in incluye el paquete Ganymede de Eclipse, pero podemos optar por instalarlo sobre una distribución de eclipse alternativa (y mas reciente), como el paquete Galileo del Eclipse IDE for Java EE Developers, el cual incluye Web Tools Platform (http://www.eclipse.org/home/categories/index.php?category=enterprise).

Introducción

Instalar Flash Builder 4 como plug-in del paquete Galileo nos permite crear proyectos Flex y Java combinados, esto es, en un mismo proyecto tendremos el código fuente de la capa de presentación (Flex) y de la capa de negocios (Java), sin necesidad de dos proyectos por separado.

El problema

Al parecer existe un bug en la creación de un proyecto Flex/Java en cuanto al uso de las macros web.context y web.content que provoca que la los parámetros "serverContextRoot" y "serverRootURL" no tomen los valores adecuados y que funcionalidad DCD no funcione.

Al crear un proyecto Flex aparece la opción de crear un proyecto combinado Flex/Java




Creación de proyecto Flex/Java con WTP


Al seleccionar la opción y oprimir “Next” pasamos a configurar el servidor J2EE. Si es la primera vez que creamos un proyecto de este tipo en el Workspace, debemos definir un nuevo servidor oprimiendo “New” y seguir los pasos del asistente. En caso contrario seleccionamos un servidor existente.

El valor del campo “Content Folder” (donde se almacenará la aplicación a desplegar luego en Tomcat) por defecto es “WebContent”, dejaremos este valor y luego veremos el efecto que trae. Debemos también indicar el lugar donde se encuentra el archivo “blazeds.war”, en este caso usamos el que viene en el paquete “blazeds-bin-4.0.0.14931.zip” (https://www.adobe.com/cfusion/entitlement/index.cfm?e=lc_blazeds). Oprimimos “Next” y luego “Finish”. Terminaremos con un proyecto con una estructura como esta:




Estructura de un proyecto Flex/Java


Notemos que la carpeta “WebContent” tiene la estructura de una aplicación J2EE, como la que se despliega en Tomcat. Intentemos ahora utilizar la funcionalidad de DCD en este proyecto. Lo que haremos será crear una clase Java con un método público y la expondremos como destino remoto, configuraremos el servlet RDSDispatchServlet (encargado de descubrir las clases expuestas como destinos remotos y los métodos que éstas contienen) y veremos si Flash Builder 4 es capaz de encontrarlo.

La clase Java puede ser una como ésta:

PLAIN TEXT
JAVA:
1. package com.flexwtp.service;
2.  
3. public class FlexWTPService {
4.  
5.     public String[] getAll(){
6.         return new String[]{"Uno","Dos","Tres"};
7.     }
8. }

Para hacerla disponible como destino remoto añadimos al archivo WebContent/WEB-INF/flex/remoting-config.xml lo siguiente:

PLAIN TEXT
XML:
1. <destination id="FlexWTPService">
2.     <properties>
3.         <source>com.flexwtp.service.FlexWTPService</source>
4.     </properties>
5. </destination>

Finalmente para configurar el RDSDispatchServlet añadimos lo siguiente al archivo WebContent/WEB-INF/web.xml

PLAIN TEXT
XML:
1. <servlet>
2. <servlet-name>RDSDispatchServlet</servlet-name>
3. <display-name>RDSDispatchServlet</display-name>
4. <servlet-class>flex.rds.server.servlet.FrontEndServlet</servlet-class> 
5.     <init-param>
6.         <param-name>useAppserverSecurity</param-name>
7.         <param-value>false</param-value>
8.     </init-param>   
9.     <load-on-startup>10</load-on-startup>
10. </servlet>
11.  
12. <servlet-mapping id="RDS_DISPATCH_MAPPING">
13.     <servlet-name>RDSDispatchServlet</servlet-name>
14.     <url-pattern>/CFIDE/main/ide.cfm</url-pattern>
15. </servlet-mapping>

Compilamos el proyecto y desplegamos la aplicación (el contenido de WebContent) en Tomcat (el que tenemos en el WorkSpace u otro externo) y cuando en la vista “Data/Services” de la perspectiva “Flash Development” tratamos de conectarnos a un servicio/datos de tipo BlazeDS sin usar autenticación:



Conexión a un servicio/dato de tipo BlazeDS

Obtenemos el siguiente error:



Error en la conexión al servlet RDSDispatchServlet

Luego de verificar que lo que se indica en los puntos 1, 2 y 3 está correcto sólo nos queda verificar la configuración del proyecto.
La configuración del servidor para el proyecto según como se definió en la creación del mismo queda de la siguiente manera:



Propiedades del proyecto Flex/Java

Pero al examinar el contenido del archivo “.flexProperties” que se encuentra en la raíz del proyecto notamos que el parámetro “serverContextRoot” está definido cómo

PLAIN TEXT
CODE:
1. serverContextRoot="/WebContent"

Sin embargo el parámetro “serverRootURL” tiene el valor:

PLAIN TEXT
CODE:
1. serverRootURL="http://localhost:8080/FlexWTPProject"

De esa manera el servlet “RDSDispatchServlet” no podrá encontrar la clase que hemos definido como destino remoto, el parámetro “serverContextRoot” debe contener el nombre de la aplicación desplegada en Tomcat, en este caso “FlexWTPProject” (la última parte del url, sin el slash final).

Cuando se crea el proyecto, “serverContextRoot” toma el valor del campo “Content Folder”, y no hay modo de cambiar su valor luego en las propiedades del proyecto. Se pudiera modificar manualmente en el archivo “.flexProperties”, pero éste se genera nuevamente cuando se modifica alguna propiedad del proyecto y se perderían los cambios.

La solución

La solución es asignar al campo “Content Folder”, durante la creación del proyecto, el valor del nombre del proyecto, que a su vez forma parte del parámetro “serverRootURL”.



Configuración del servidor JEE en un proyecto Flex/Java

De esta manera, una vez desplegada la aplicación, cuando intentemos conectarnos a un servicio/dato a través de la vista “Data/Services” obtendremos lo siguiente:



Resultado de la conexión a un servicio/dato de tipo BlazeDS

Lo cual nos indica que el servlet “RDSDispatchServlet” ha encontrado la clase java que hemos definido como destino remoto. Seleccionamos el destino, indicamos el nombre de los paquetes y al oprimir “Finish” el asistente generará el código correspondiente (en este ejemplo en particular no se genera ningún valueObject ya que el tipo de dato de retorno del método es String, el cual es soportado nativamente por ActionScript).



Código generado por el asistente.





Vista Data/Services luego de la generación de código

La opción de nombrar al proyecto “WebContent” y aceptar el valor inicial propuesto para el campo “Content Folder” ni siquiera se contempla, por razones obvias

Conclusiones

Siguiendo los pasos que hemos explicado en este artículo podremos crear proyectos Flex/Java con WTP y explotar la funcionalidad del Data Centric Development introducido en Flash Builder 4, la cual representa sin dudas un gran paso hacia el objetivo de lograr un entorno de trabajo altamente productivo para el desarrollo de RIA con Adobe Flex y Java.

]]> http://www.madeinflex.com/2010/05/30/usando-data-centric-development-dcd-en-proyectos-flexjava-con-wtp/feed/ 3 http://www.madeinflex.com/2009/07/18/fx4-iii-fxg-10/ http://www.madeinflex.com/2009/07/18/fx4-iii-fxg-10/#comments Sat, 18 Jul 2009 15:12:57 +0000 Joan Garnet http://www.madeinflex.com/2009/07/18/fx4-iii-fxg-10/ En esta cuarta versión de Flex se han producido cambios considerables en la arquitectura de componentes así como en el lenguaje MXML. Esto se ha hecho para potenciar varios aspectos como son la productividad, facilitar el workflow designer / developer o la integración con herramientas externas. En esta entrada se verá qué es FXG dentro del [...]]]>

En esta cuarta versión de Flex se han producido cambios considerables en la arquitectura de componentes así como en el lenguaje MXML. Esto se ha hecho para potenciar varios aspectos como son la productividad, facilitar el workflow designer / developer o la integración con herramientas externas.
En esta entrada se verá qué es FXG dentro del contexto Flex 4. FXG es la especificación del nuevo formato de intercambio de gráficos para el Flash Player.

1. Introducción
2. Documentos FXG
3. ¿FXG o Flex FXG?
4. Implementación FXG en Flex
   1. Formas
      1. fill
      2. stroke
      3. spark.primitives.Rect
      4. spark.primitives.Ellipse
      5. spark.primitives.Line
      6. spark.primitives.Path
   2. spark.primitives.BitmapImage
   3. Texto
   4. spark.components.Group
5. Library
6. Conclusión

Introducción

FXG (Flash XML Graphics) es un lenguaje basado en XML que expone toda la capacidad de renderizado del Flash Player de forma declarativa. La especificación de FXG se ha creado para ofrecer un formato de intercambio de gráficos entre aplicaciones de edición gráfica y el Flash Player que sea fácil de utilizar y a la vez ofrezca un control total del resultado final y de la optimización del mismo.
En la especificación de FXG encontramos un conjunto de elementos gráficos, texto, filtros, etc.. con los cuales se puede crear, agrupar, transformar y modificar formas vectoriales, bitmaps y texto.

Documentos FXG

En una aplicación Flex podemos utilizar FXG en línea dentro de un documento *.MXML de la misma forma que utilizamos otros componentes Flex o bien auto contenido como componente en un archivo *.FXG o *.MXML externo.
Aunque en ambos casos podamos obtener el mismo resultado internamente las cosas son ciertamente diferentes. En el caso de utilizar FXG en línea dentro de un archivo MXML lo que estamos haciendo es utilizar la implementación de FXG que el SDK de Flex nos proporciona, es decir, obtenemos instancias de clases que están dentro de la cadena de herencia del SDK de Flex.
En el caso de utilizar un FXG como componente desde un archivo externo lo que obtenemos en el momento de compilación es un recurso gráfico muy optimizado en cuanto a uso de memoria y que hereda de spark.core.SpriteVisualElement, una clase de mucho más bajo nivel y por lo tanto mucho más ligera.

¿FXG o Flex FXG?

Entonces, ¿cuándo utilizar una u otra opción? Si necesitamos elementos gráficos que soporten el ciclo de vida del sdk de Flex y que nos proporcionen toda la interactividad del framework (eventos, data binding, etc...) entonces debemos utilizar la implementación de FXG que nos proporciona Flex a través de Spark, de lo contrario lo mejor es externalizar en forma de componente FXG para sacar partido de las optimizaciones que el compilador nos brinda.
Debemos tener en cuenta que dentro de un comonente FXG no se pueden utilizar las funcionalidades del SDK, tampoco tipos nativos del Flash Player o en definitiva lógica alguna. El componente es puramente un descriptor de un elemento gráfico.

Implementación FXG en Flex

Flex contiene una implementación FXG completa en el espacio de nombres Spark. En esta entrada vamos a aprender a utilizar FXG a través de dicha implementación.
A continuación vamos a revisar los distintos elementos FXG de los que disponemos en Flex.

Formas

Las formas vectoriales se componen de los puntos que la definen, un relleno y un trazo.

fill

El relleno de cualquer forma se declara mediante la propiedad fill.
Esta propiedad acepta implementaciones de IFill:

• mx.graphics.BitmapFill
• mx.graphics.LinearGradient
• mx.graphics.RadialGradient
• mx.graphics.SolidColor

stroke

El trazo que define una forma se declara mediante la propiedad stroke.
Esta propiedad acepta implementaciones de IStroke:

• mx.graphics.LinearGradientStroke
• mx.graphics.RadialGradientStroke
• mx.graphics.SolidColorStroke

spark.primitives.Rect

spark.primitives.Ellipse

spark.primitives.Line

Estas primitivas declaran respectivamente una forma rectangular, una elipse y una línea.
Un ejemplo de uso:

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application
3.     xmlns:fx="http://ns.adobe.com/mxml/2009"
4.     xmlns:s="library://ns.adobe.com/flex/spark"
5.     xmlns:mx="library://ns.adobe.com/flex/halo">
6.    
7.     <s:Rect width="150" height="100" x="100" y="100">
8.         <s:stroke>
9.             <mx:SolidColorStroke color="#FF0000" weight="5"/>
10.         </s:stroke>
11.         <s:fill>
12.             <mx:SolidColor color="#000000"/>
13.         </s:fill>
14.     </s:Rect>
15.    
16.     <s:Ellipse width="100" height="150" x="50" y="50">
17.         <s:fill>
18.             <mx:RadialGradient>
19.                 <mx:GradientEntry color="#FF0000" alpha="0.5"/>
20.                 <mx:GradientEntry color="#00FF00" alpha="1"/>
21.             </mx:RadialGradient>
22.         </s:fill>
23.     </s:Ellipse>
24.    
25.     <s:Line xFrom="100" xTo="250" yFrom="100" yTo="250">
26.         <s:stroke>
27.             <mx:SolidColorStroke color="#0000FF" weight="10"/>
28.         </s:stroke>
29.     </s:Line>
30.    
31. </s:Application>



spark.primitives.Path

Esta primitiva permite declarar libremente cualquier forma.
Con Path podemos definir una secuencia de segmentos rectos o circulares para que conformen el perímetro de una forma. Dichos segmentos se asignan desde el atributo segments:Array y pueden ser de los siguientes tipos:

• spark.primitives.pathSegments.LineSegment
• spark.primitives.pathSegments.CubicBezierSegment
• spark.primitives.pathSegments.QuadraticBezierSegment

Adicionalmente disponemos de la clase spark.primitives.pathSegments.MoveSegment para mover el punto desde el que se empieza a dibujar.
Además de poder definir declarativamente la secuencia de segmentos disponemos del atributo data, el cual nos permite pasar un String con notación SVG para que defina dicha secuencia de segmentos.
Con toda esta versatilidad, la clase Path nos permite obtener el mismo resultado que con las primitivas que se muestran anteriormente y más
Un ejemplo de uso:

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application
3.     xmlns:fx="http://ns.adobe.com/mxml/2009"
4.     xmlns:mx="library://ns.adobe.com/flex/halo"
5.     xmlns:s="library://ns.adobe.com/flex/spark">
6.  
7.     <s:Path>
8.         <s:segments>
9.             <s:MoveSegment x="100" y="100"/>
10.             <s:LineSegment x="200" y="100"/>
11.             <s:LineSegment x="200" y="200"/>
12.             <s:LineSegment x="100" y="200"/>
13.             <s:CubicBezierSegment control1X="50" control1Y="175" control2X="50" control2Y="125" x="100" y="100"/>
14.         </s:segments>
15.         <s:stroke>
16.             <s:Stroke color="0x888888"/>
17.         </s:stroke>
18.     </s:Path>
19.  
20.     <s:Path>
21.         <s:data>
22.             M 50 50
23.             L 150 50
24.             L 150 150
25.             L 50 150
26.             C 0 125 0 75 50 50
27.         </s:data>
28.         <s:stroke>
29.             <s:Stroke color="0xFF0000" weight="10"/>
30.         </s:stroke>
31.     </s:Path>
32.    
33. </s:Application>



spark.primitives.BitmapImage

Esta primitiva nos permite cargar un bitmap en una superficie rectangular. El bitmap puede ocupar una porción, la totalidad o incluso más de la superficie disponible. Adicionalmente se puede controlar si el bitmap se escala o no y si se repite a lo largo de la superficie.
Un ejemplo:

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application
3.     xmlns:fx="http://ns.adobe.com/mxml/2009"
4.     xmlns:mx="library://ns.adobe.com/flex/halo"
5.     xmlns:s="library://ns.adobe.com/flex/spark">
6.  
7.     <s:Graphic x="10" y="10">             
8.         <s:BitmapImage source="@Embed('/mif_logo.png')"/>
9.     </s:Graphic>
10.       
11.     <s:Graphic x="10" y="101">
12.         <s:BitmapImage source="@Embed('/mif_logo.png')" width="600" height="100" resizeMode="scale" alpha="0.8"/>
13.     </s:Graphic>
14.    
15.     <s:Graphic x="10" y="211">
16.         <s:BitmapImage source="@Embed('/mif_logo.png')" width="432" height="162" repeat="true" alpha="0.5"/>
17.     </s:Graphic>
18.  
19. </s:Application>



Texto

FXG proporciona dos primitivas para tratar zonas de contenido textual:

• spark.primitives.RichText
• spark.primitives.SimpleText

RichText es para definir texto rico, en el cuál se pueden renderizar distintos tipos de formatos a la vez, distintos tipos de elementos como imágenes, texto, etc...
Esta clase saca partido del FTE (Flash Text Engine) a través del TLF (Text Layout Framework). El FTE es un conjunto de componentes de bajo nivel existentes en el Flash Player 10 que, a través de sus APIs ActionScript permiten crear por encima implementaciones listas para ser utilizadas como campos de texto, como el TLF.
A través de la propiedad content de RichText se pueden intercalar elementos de texto mezclados con distintos tags que permiten desde asignar formatos a grupos de caracteres hasta intercalar imágenes entre otros grupos de caracteres, etc..
Estos son los tags soportados:

• div
• p
• span
• a
• img
• br
• tab
• tcy

Cada uno de ellos sopora un conjunto de atributos y permite realizar una serie de operaciones determinadas. Toda esta potencia es, sin duda, un paso de gigante en lo que a renderizado de bloques de texto se refiere.
SimpleText soporta un solo formato que se aplica a todo el texto. Esta clase ofrece una funcionalidad parecida a la clase mx:Label de la versión 3 de Flex pero con soporte multiline.
Un ejemplo:

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application
3.     xmlns:fx="http://ns.adobe.com/mxml/2009"
4.     xmlns:mx="library://ns.adobe.com/flex/halo"
5.     xmlns:s="library://ns.adobe.com/flex/spark">
6.    
7.     <s:RichText x="100" y="100" fontFamily="Arial" fontSize="16" width="200">
8.         <s:content>
9.             Lorem <s:span fontWeight="bold" color="#FF0000">Ipsum</s:span> dolor sit amet,
10.             <s:img source="@Embed('/comment.png')" width="16" height="16"/> consectetur
11.             adipiscing elit. Aliquam <s:img source="@Embed('/search.png')" width="16" height="16"/>
12.             sodales magna vel nisl fermentum vel gravida orci bibendum.<s:br /> Quisque accumsan
13.             ultrices lacus id <s:span fontStyle="italic">sollicitudin</s:span>. Vivamus fermentum
14.             tortor a odiodapibus <s:img source="@Embed('/warning.png')" width="16" height="16"/>
15.             id posuere augue congue. Morbi ultricies felis a elit adipiscing dignissim.
16.         </s:content>
17.     </s:RichText>
18.    
19.     <s:SimpleText x="350" y="100" width="200" fontSize="12" fontFamily="Verdana">
20.         <s:text><![CDATA[Lorem ipsum dolor sit amet, "consectetur" adipiscing elit.<br/>Aliquam sodales magna vel nisl fermentum vel gravida orci bibendum.<br/>Quisque accumsan ultrices lacus idsollicitudin.]]></s:text>
21.     </s:SimpleText>
22.  
23. </s:Application>



spark.components.Group

La clase Group permite agrupar elementos en un lienzo con origen de coordenadas propio. Por defecto utiliza layout de posicionamiento absoluto que puede cambiarse en tiempo de ejecución por cualquier otro tipo de layout, ya sea uno de los disponibles en Spark o uno personalizado por nosotros mismos.
Se dispone de las subclases VGroup y HGroup para trabajar con layout vertical y horizontal respectivamente.

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application
3.     xmlns:fx="http://ns.adobe.com/mxml/2009"
4.     xmlns:mx="library://ns.adobe.com/flex/halo"
5.     xmlns:s="library://ns.adobe.com/flex/spark">
6.    
7.     <s:Group x="100" y="100" width="100" height="100">
8.         <s:Rect width="100%" height="100%">
9.             <s:stroke>
10.                 <mx:SolidColorStroke color="#FF0000" weight="5"/>
11.             </s:stroke>
12.             <s:fill>
13.                 <mx:SolidColor color="#00FF00"/>
14.             </s:fill>
15.         </s:Rect>
16.     </s:Group>
17.  
18.     <s:Group x="150" y="150">
19.         <s:Rect width="150" height="150">
20.             <s:stroke>
21.                 <mx:SolidColorStroke color="#000000" weight="5"/>
22.             </s:stroke>
23.             <s:fill>
24.                 <mx:SolidColor color="#0000FF"/>
25.             </s:fill>
26.         </s:Rect>
27.     </s:Group>
28.    
29. </s:Application>



Library

El concepto de librería y símbolo no es nada nuevo dentro del mundo Flash, de hecho has sido un pilar para la evolución de la tecnología y para ayudar a introducir los coneptos de de clase e instancia de POO a todos los usuarios no programadores de Flash.
Flex 4 se sirve nuevamente de esta metáfora a través del tag Library que proporciona el espacio de nombres de lenguaje MXML2009.
En este nodo MXML podemos anidar dentro de un tag Definition cualquier grupo o elemento gráfico a modo de template para ser usado (instanciado) en cualquier lugar del documento tantas veces como se quiera. Es importante notar que los elementos que añadimos en Library quedan accesibles exclusivamente dentro del ámbito del documento MXML que los declara.
Para crear las instancias de cada una de las definiciones utilizaremos el atributo name del Definition que deseemos para referenciar el template de objeto.

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application
3.     xmlns:fx="http://ns.adobe.com/mxml/2009"
4.     xmlns:mx="library://ns.adobe.com/flex/halo"
5.     xmlns:s="library://ns.adobe.com/flex/spark">
6.    
7.     <fx:Library>
8.         <fx:Definition name="grupo">
9.             <s:Group>
10.                 <s:Rect width="150" height="150">
11.                     <s:stroke>
12.                         <mx:SolidColorStroke color="#FF0000" weight="5"/>
13.                     </s:stroke>
14.                     <s:fill>
15.                         <mx:SolidColor color="#00FF00"/>
16.                     </s:fill>
17.                 </s:Rect>
18.                 <s:Ellipse width="150" height="150">
19.                     <s:stroke>
20.                         <mx:SolidColorStroke color="#000000" weight="5"/>
21.                     </s:stroke>
22.                 </s:Ellipse>
23.             </s:Group>
24.         </fx:Definition>
25.     </fx:Library>
26.    
27.     <fx:grupo x="100" y="100"/>
28.     <fx:grupo x="150" y="150" alpha="0.5"/>
29.        
30. </s:Application>



Conclusión

FXG es una especificación muy potente que ofrece a la plataforma Flash una herramienta a medida para intercambiar gráficos entre distintas aplicaciones. Además, a través de la implementación que Flex 4 lleva en el espacio de nom bres Spark, proporciona una versatilidad nunca vista antes ( bueno si.. ver Degrafa ) a la hora de declarar interfaces.
Gracias a FXG el workflow designer/developer nunca más va a ser un obstáculo para llevar la tecnología a los más altos niveles de perfección gráfica.

]]> http://www.madeinflex.com/2009/07/18/fx4-iii-fxg-10/feed/ 5 http://www.madeinflex.com/2009/06/29/flex-y-seo/ http://www.madeinflex.com/2009/06/29/flex-y-seo/#comments Mon, 29 Jun 2009 12:44:34 +0000 Carlos Rovira http://www.madeinflex.com/2009/06/29/flex-y-seo/ A continuación la presentación sobre Flex + SEO que Gonzalo Pezzi y yo dimos es la última reunión de MIF en Barcelona con motivo del Adobe Global Tour 2009. La presentación trata sobre como tener los mismos beneficios que ya disfrutábamos con webs HTML tradicionales aplicados a una web Flex. Es decir, que el contenido sea [...]]]>

A continuación la presentación sobre Flex + SEO que Gonzalo Pezzi y yo dimos es la última reunión de MIF en Barcelona con motivo del Adobe Global Tour 2009.

La presentación trata sobre como tener los mismos beneficios que ya disfrutábamos con webs HTML tradicionales aplicados a una web Flex. Es decir, que el contenido sea indexable por buscadores, enlaces de profundidad ha contenidos, que tengamos habilitados los botones del navegador para ir adelante o atrás por las páginas de la web Flex y otros temas adicionales como es el multidioma, por poner un ejemplo.

La presentación se basa en la nueva web de Codeoscopic donde se implementan todos estos conceptos y que todavía estamos terminando de completar pero que ya vuestra a nivel técnico todas estas posibilidades.

También y como se anunció al final de la charla, pretendemos hacer la base de esta plataforma Open Source de forma que Codeoscopic empiece a realizar aportes a la comunidad dentro del ámbito OS.


]]> http://www.madeinflex.com/2009/06/29/flex-y-seo/feed/ 2 http://www.madeinflex.com/2009/06/28/fx4-i-espacios-de-nombre/ http://www.madeinflex.com/2009/06/28/fx4-i-espacios-de-nombre/#comments Sun, 28 Jun 2009 14:13:24 +0000 Joan Garnet http://www.madeinflex.com/2009/06/28/fx4-i-espacios-de-nombre/ En esta cuarta versión de Flex se han producido cambios considerables en la arquitectura de componentes así como en el lenguaje MXML. Esto se ha hecho para potenciar varios aspectos como son la productividad, facilitar el workflow designer / developer o la integración con herramientas externas. En esta entrada se hará una introducción a los espacios [...]]]>

En esta cuarta versión de Flex se han producido cambios considerables en la arquitectura de componentes así como en el lenguaje MXML. Esto se ha hecho para potenciar varios aspectos como son la productividad, facilitar el workflow designer / developer o la integración con herramientas externas.
En esta entrada se hará una introducción a los espacios de nombres de Flex 4.

1. Espacios de nombre
2. Espacios de nombre en mxml
3. xmlns:fx: MXML 2009
4. xmlns:s: Spark
5. xmlns:mx: Halo
6. MXML 2006

Antes de empezar es interesante aclarar qué es exactamente Flex 4.
Flex 4 no es ni implica una nueva versión de ActionScript o del Flash Player, "simplemente" se ha mejorado la librería Flex y el compilador (y el debugger y el profiler y seguro que otras cosas que no menciono).
Cuando empecemos a trabajar con Flex 4 lo haremos con el mismo runtime; el Flash Player y lenguaje (AS3) que utilizamos en Flex 3. Eso si, mientras que en el caso de Flex 3 podemos optar por trabajar con Flash Player >= 9, con Flex 4 solo podemos trabajar con Flash Player >= 10. Esto es debido a que Flex 4 saca partido de forma generalizada de las nuevas características de Flash Player 10.

Espacios de nombre

Un espacio de nombre no es nada nuevo, muchos lenguajes sacan provecho de este concepto de distintas formas. Sin ir más lejos ActionScript 3 tiene dos formas de definir espacios de nombre, una mediante la palabra clave package y otra mediante la palabra clave namespace. Esta última es quizás la más obvia ya que la traducción literal es precisamente "espacio de nombre".
Entonces, ¿qué es un espacio de nombre? pues no es más que un mecanismo de organización que nos permite evitar colisiones entre identificadores. Es gracias a los espacios de nombre que podemos tener una clase llamada miEspacioDeNombre.String sin que colisione con la clase String nativa de ActionScript.

Espacios de nombre en mxml

MXML soporta espacios de nombre, de hecho es una característica que en versiones anteriores de Flex ya se utilizaba, aunque en la versión 4 su uso y comprensión son obligados ya que vamos a tener que utilizarlos concienzudamente desde el primer momento.

Cuando creamos un proyecto con Flash Builder 4, el archivo principal tiene este aspecto:

PLAIN TEXT
MXML:
1. <?xml version="1.0" encoding="utf-8"?>
2. <s:Application
3.     xmlns:fx="http://ns.adobe.com/mxml/2009"
4.     xmlns:s="library://ns.adobe.com/flex/spark"
5.     xmlns:mx="library://ns.adobe.com/flex/halo">
6.    
7. </s:Application>

Este código se diferencia del que se generaba en versiones anteriores en que por defecto utiliza tres declaraciones de espacios de nombre distintas:

• xmlns:fx="http://ns.adobe.com/mxml/2009"
• xmlns:s="library://ns.adobe.com/flex/spark"
• xmlns:mx="library://ns.adobe.com/flex/halo"

En la gran mayoría de proyectos Flex 4 vamos a utilizar estos tres espacios de nombre, es por eso que están los tres declarados desde los mismos templates de proyecto de Flash Builder.

xmlns:fx: MXML 2009

Este es un espacio de nombres de lenguaje con el que podremos instanciar tipos nativos del Flash Player como Date, String, Array, etc.. además de poder declarar tags específicos de MXML como Declarations, Metadata, Script, Binding, etc... En este espacio de nombres no encontraremos ningún componente.

xmlns:s: Spark

Spark es el nombre que se le ha dado al nuevo set de componentes de Flex 4. Spark implica un nuevo set de componentes pero también una nueva arquitectura que, entre otras cosas, es mucho más modular. En este espacio de nombres encontraremos todos los tipos correspondientes a los nuevos componentes como Button, Group, VerticalLayout, etc... Se debe tener en cuenta que no todos los componentes de Flex 3 se han migrado a Flex 4, este trabajo está en proceso todavía, pero como veremos más adelante si nos hace falta no es problema mezclar componentes Spark y componentes Halo (Flex < 4).

xmlns:mx: Halo

Si en Flex 4 queremos por ejemplo utilizar un DataGrid, tendremos que recurrir a este espacio de nombres, ya que el DataGrid es uno de los componentes que no se ha migrado todavía a la arquitectura Spark. La convivencia entre Halo y Spark es uno de los objetivos principales que se marcaron a la hora de plantear esta nueva versión de Flex.

MXML 2006

Si queremos trabajar en Flex 4 de la misma forma que lo hacíamos en Flex 3 podemos utilizar el espacio de nombres MXML 2006 ( xmlns:mx="http://www.adobe.com/2006/mxml" ), aunque en este caso no podemos mezclarlo con s (Spark) ni fx (MXML 2009).

Esto es todo lo referente a espacios de nombre que debemos saber en Flex 4.

]]> http://www.madeinflex.com/2009/06/28/fx4-i-espacios-de-nombre/feed/ 12 http://www.madeinflex.com/2009/06/10/code-behind-vs-mxml-script-block-vs-view-helper-conclusiones-de-los-patrones-de-presentacion/ http://www.madeinflex.com/2009/06/10/code-behind-vs-mxml-script-block-vs-view-helper-conclusiones-de-los-patrones-de-presentacion/#comments Wed, 10 Jun 2009 08:59:07 +0000 Sergi Dote Teixidor http://www.madeinflex.com/2009/06/10/code-behind-vs-mxml-script-block-vs-view-helper-conclusiones-de-los-patrones-de-presentacion/ Sobre la pregunta de donde colocar el código relacionado a un fichero MXML, seguramente, las tres soluciones más utilizadas en el mundo Flex son code behind, script blocks o view helper. Un script block es la parte de código ActionScript que se coloca entre los tags . Ya hemos visto la definición de view helper, pero para [...]]]>

Sobre la pregunta de donde colocar el código relacionado a un fichero MXML, seguramente, las tres soluciones más utilizadas en el mundo Flex son code behind, script blocks o view helper.

Un script block es la parte de código ActionScript que se coloca entre los tags .

Ya hemos visto la definición de view helper, pero para resumir podemos decir que es una clase ActionScript a la que un fichero MXML puede llamar y escuchar directamente. Normalmente contiene código relacionado con el fichero MXML y funcionalidades que si no estuviera esta clase irían en el fichero MXML en script blocks.

Code behind también lo hemos visto con anterioridad, pero para dar un resumen de este patrón, podemos decir que es una manera sencilla y rápida de organizar la funcionalidad. Si movemos el código de un script block a una clase code behind, estamos cambiando la localización de éste y ensuciando la sintaxis para acceder a este código.

Es adecuado poner el código en una clase ActionScript externa, cuando este código no contiene referencias a vistas.
Lo más adecuado es extraer el código a clases que tengan reglas OOP, así serán fáciles de testear y fáciles de acceder. Si cargamos las vistas de funcionalidades, estaremos sobrecargando estas vistas con responsabilidades que no le atañen, y seguramente duplicando código.

La meta es no cargar las vistas con código que no le pertenece o código excesivo.

 
CONCLUSIONES

Está comprobado que Flex es capaz de soportar la implementación de cualquiera de los seis patrones presentados. Dicho esto, algunos patrones usan mejor las características de Flex que otros. Tanto Presentation Model como Supervising Presenter combinan el refactoring de extracción de clase con un uso elegante de los bindings de MXML y los event handlers declarativos. Passive View y Code Behind sacrifican estas características en el beneficio de lograr una mayor separación entre ActionScript / MXML.

]]> http://www.madeinflex.com/2009/06/10/code-behind-vs-mxml-script-block-vs-view-helper-conclusiones-de-los-patrones-de-presentacion/feed/ 2