MadeInFlex » Componentes

Clear Toolkit framework

Joan Garnet — Sun, 08 Mar 2009 10:05:27 +0000

La gente de Farata Systems ha liberado su framework “Clear Toolkit framework” para desarrollo de enterprise RIAs con Flex y Java. El framework está disponible en sourceforge bajo licencia MIT.
Clear Toolkit framework dispone de varios componentes:

Clear Data Builder: plugin de Eclipse para generación de aplicaciones CRUD para BlazeDS o LCDS a partir de sentencias SQL o Java DTOs
DTO2Fx: generador de clases ActionScript a partir de sus homólogas en Java
Log4Fx: plugin de Eclipse para la API de logging de Flex. Automatiza y hace el proceso de logging más amigable
Fx2Ant: generador de ANT build scripts optimizados para proyectos de Flex Builder
clear.swc: Librería avanzada de componentes Flex situada en el paquete com.farata.components

Además de lo mencionado puedes ver el roadmap para la version 4 aquí.
Algunos enlaces relacionados:

Degrafa: Declarative Graphics Framework

MIF Team — Wed, 11 Jun 2008 18:48:42 +0000

Degrafa es una librería de creación de gráficos que saca buen partido a la potencia de mxml.
Con Degrafa podemos declarar fácilmente formas geométricas, skins, rellenos, formas compuestas por repetición, etc.. de la misma forma que lo hacemos al declarar contenedores o controles en Flex mediante tags MXML.

Un ejemplo:

Más información en http://www.degrafa.com

Tres puntos a recordar al crear una libreria

Xavi Beumala — Tue, 10 Jun 2008 22:56:37 +0000

Utilizando compc o bien, desde FlexBuilder, podemos crear librerías de código en ActionScript y/o mxml que luego podemos distribuir en formato .swc a terceros ya sea por comodidad, porque nos dedicamos a vender librerías de código, porque es una forma de paquetizar conocimiento, fomentar la reutilización o por cualquier otro motivo.

La cuestión es que para que la librería se vea lo mejor acabada y profesional posible deberíamos considerar siempre los siguientes puntos:

Desvincular la SDK de Flex

Es muy probable que en tu librería exista alguna referencia a cualquier clase de la SDK de Flex, ya sea debido a que alguno de tus componentes hereda de alguno de los base, porque utilizas alguno de sus managers o clases de utilidad o bien porque has paquetizado algun mxml en ella. En cualquier da estos casos, el linkador, detectará las dependencias directas de tus clases con las de la SDK. Este proceso será un proceso en cascada que detectará todas las interrelaciones incluso dentro de la misma SDK. Por ejemplo, si estas paquetizando una clase que no tiene nada, que simplemente herede de mx.controls.Button tu librería pesará entorno a los 200K debido a las dependencias que tiene Button con todo el resto del framework. Todas estas clases se añadirán pues a tu librería.

NOTA: Esto no es una forma de reducir el tamaño final de los swf’s

El concepto es correcto, pero el 99% de los usuarios que utilicen tus librerias no van a necesitar esas clases ya que cuando compilen sus proyectos con tu librería igualmente tendrán las clases de la SDK (resultando con el mismo tamaño final).

Por lo tanto podemos hacer que no se incluyan las dependencias de la SDK en la librería. A priori no notaremos una gran mejora en los tiempos de compilacion (aunque un poquito sí). Si estamos distribuyendo la libreria entonces sí que podemos ahorrar un poco de ancho de banda y mejorar los tiempos de descarga.

Para no añadir la SDK a la librería, en FlexBuilder, tenemos que ir a las propiedades del proyecto > “Flex Library Build Path” > “Library Path”. Ahi cambiamos la opcion “Link Type” de framework.swc para que sea “External”.

Crear un manifest.xml

Tomando como ejemplo los componentes paquetizados en la SDK de Flex, siempre que añadimos uno a un .mxml el componente se instancia con una sintaxis parecida a siendo el único namespace que se usa siempre mx. En cambio cuando hacemos nuestras propias librerias siempre se utiliza como namespace la última parte del package donde se encuentra el componente que estamos instanciando. De esta forma si tenemos componentes en paquetes distintos i.e: com.madeinflex.package1 y com.madeinflex.package2 se nos instanciaran los componentes de la forma o .

La verdad es que luego, el uso de la librería, es bastante molesto ya que se terminan declarando un sinfín de namespaces en el xml que ensucia bastante el código. Por otro lado no se puede saber con un simple vistazo a qué librería pertenece un componente concreto. Se tiene que ir a la definición del namespace, mirar cuál es su package y luego ponerle un poco de imaginación.

Para solventar esto FlexBuilder y compc ponen a nuestra disposicion los manifest, asociados a un namespace. Un manifest no es mas que un fichero xml en el que se declaran, en la forma clave / valor, los componentes contenidos en una librería. Por ejemplo:

En FlexBuilder, para asociar un fichero de manifest a un namespace lo tenemos que hacer a través del panel de propiedades del proyecto. En el subapartado “Flex Library Compiler” definiremos el namespace y le vincularemos el fichero. Si declaramos que el nombre de espacios sea http://www.madeinflex.com/mif entonces podremos instanciar los componentes de la siguiente forma:

Destacar aquí que podemos definir el id de un componente con un nomre distinto al de su clase.

Otra cosa a considerar cuando paquetizamos una libreria es que muy probablemente no queramos que el programador que la utilice tenga acceso o pueda visualizar todas las clases que hemos paquetizdo. Puede haber clases de utilidades, superclases, clases de soporte, etc. que deberían ser transparentes y no mostrarse al integrador. Si declaramos un manifest para la librería y no declaramos en él estas clases el code autocomplete no se las mostrara aunque si que estarán en la librería y por lo tanto todo compilará correctamente.

Crear un design.xml

Puede que esta funcionalidad haya pasado desapercibida para muchos pero creo que es imprescindible para terminar de paquetizar bién una libreria y darle el toque final.

Al definir el namespace http://www.madeinflex.com/mif, por defecto FlexBuilder al instanciar un componente suyo lo hace de la forma , es decir utilizando madeinflex como prefijo para el namespace en vez de mif o cualquier otro. Al hacer esto parece que no podamos asignar a un mismo dominio distintos namespaces. Pero la SDK de flex si que lo hace no? xmlns:mx=”http://www.adobe.com/2006/mxml”.

Este es uno de los objetivos que tiene el fichero design.xml, poder definir el prefijo que FlexBuilder utilizará por defecto al instanciar un componente de la librería.

Otro aspecto que podemos pulir un poco más tiene que ver con la perspectiva de diseóo dentro de Flex Builder. Para los que la habéis utilizado habréis visto que en la vista “Components” aparece un árbol jerárquico con los distintos componentes que se pueden arrastrar al mxml. Por defecto todos los componentes o clases que se puedan instanciar visualmente dentro del proyecto aparecerán en la categoría Custom. Pues bién, a través del fichero design.xml podemos hacer que los distintos componentes paquetizados en una librería aparezcan jerarquizados como creamos más conveniente.

En este ejemplo estamos definendo que el prefijo para el namespace http://www.madeinflex.com/mif sea mif y tal como se ve en la figura, definimos dos categorias de componentes: MadeInFlex_1 y MadeInFlex_2 a las que asociamos respectivamente los componentes Component1 y Component2. Donde Component1 y Component2 son el atributo id del componente declarado en el manifest.xml.

Para que estos cambios surjan efecto tenemos que forzar al compilador a añadir el fichero desing.xml a la librería. Para ello abrimos el panel de propiedades del proyecto >> Flex Library Build Path >> Assets y ahi marcamos tanto el manifest.xml como el design.xml. Esto hará que, aunque no sean ficheros referenciados desde el código y a los que por lo tanto el linker jamás llegaría, los añada al swc final.

Para rizar el rizo, podemos terminar de paquetizar nuestros componentes personalizando el icono que se utiliza en el árbol jerárquico. Para ello lo único que tenemos que hacer es utilizar el siguiente tag de metadatos en la clase que define el componente [IconFile("icono.png")]. Donde icono.png hace referencia al fichero que queremos utilizar como icono. El fichero referenciado se toma con una ruta relativa respecto a la clase que lo incluye. Destacar tambien que para que el icono se cargue éste se tiene que haber añadido a la compilacion (igual que hemos hecho con design.xml). Si se cambia el icono de una librería se tiene que reiniciar eclipse para que los cambios se vean reflejados.

Te puedes descargar aqui los proyectos utilizados en los ejemplos.

Flex Component Kit: FLVPlayback desde Flex

David Serrano — Mon, 12 May 2008 20:39:09 +0000

ÃƒÅ¡ltimamente vemos, cada vez más, como el video se va introduciendo en la mayoría de los sites, llegando incluso a usarse como elemento principal del site: YouTube, Tele5 entre otras.

Flex nos aporta un componente de video para ello (VideoDisplay), pero quien lo haya utilzado, sabe que prácticamente no aporta nada. Por no traer, no trae ni la barra de progreso.

Gracias al Flex Component Kit for Flash CS3, ahora podemos utilizar el componente de video de Flash o FLVPlayback, dentro de nuestra aplicación Flex sin mucho esfuerzo.

Xavi y Carlos centraron su charla del Max en la interacción de las diferentes tecnologías de Adobe; así que vamos a poner un ejemplo práctico de esa integración: la utilización del FLVPlayback dentro de Flex.

En primer lugar es necesario descargarse el Flex Component kit

Una vez instalado y estando ya en Flash IDE, creamos un movieClip vacío,le llamamos player ,y dentro de él arrastramos el componente FLVPlayback.

Luego creamos un movieclip en una capa superior de nuestro movieclip player ,con la misma medida del componente. A este movieclip le llamaremos boundingBox.

Esto lo hacemos para poder ver el preview del componente dentro de Flex builder (dead preview) y sobretodo para definir la medida que tendrá el player y cualquiera de sus elementos internos. Esto es importante, ya que por ejemplo, la barra de progreso del player es mucho más larga y sin el boundingBox nos aparecería un scroll desagradable dentro de nuestro layout de Flex.

Una vez creados, vamos a convertir nuestro componente en UIComponent para poder exportarlo a Flex; para ello seleccionamos nuestro movieclip player en la biblioteca y seleccionamos del menú superior Commands -> Make Flex Component.

Ahora ya tendríamos nuestro componente preparado para utilizarlo en Flex, pero necesitamos poder acceder a las propiedades de nuestro player desde Flex, es por ello que vamos a generar una clase que haga de Proxy entre Flex y nuestro componente para poder controlarlo desde Flex.
Así que nos vamos al linkage del componente (seleccionando el componente de la biblioteca y clickando botón derecho -> linkage y sustituimos la Base Class: mx.flash.UIMovieClip por Player.
Ahora creamos un nuevo archivo as y lo llamamos Player.as

Esa será la clase que conecte Flex con el componente FLVPlayback. Vamos a ello:

En primer lugar, nuestra clase tiene que extender de mx.flash.UIMovieClip para poder utilizarse en Flex. Luego generamos los métodos que necesitemos:

Ahora, ya podemos publicar la película y nos generará un archivo .swf y otro archivo .swc.
Ya podemos copiar nuestro archivo swc y pasarlo a nuestro proyecto de Flex.

Una vez vinculado o incluido dentro de la carpeta libs de nuestro proyecto Flex, simplemente necesitamos instanciarlo de la siguiente forma:

Este ejemplo se puede ampliar fácilmente creando nuevos métodos en nuestra clase Player, añadiendo una imagen anterior a la reproducción del video o añadiendo la funcionalidad fullScreen, o lanzando eventos desde el player hacia Flex,….

Bueno, en el próximo tutorial intentaremos crear un Player en as3 desde 0 para poderlo utilizar desde Flash o desde Flex indistintamente.

Descargar ficheros del ejemplo

RichHTMLTextEditor

Xavi Beumala — Wed, 09 Apr 2008 08:38:22 +0000

Aquellos que habéis tenido que usar el control RichTextEditor os habréis dado cuenta de lo pobre que es el soporte que da FlashPlayer al HTML y de lo difícil que se hace trabajar con html.

El componente que muestro a continuación sólo sirve para aplicaciones AIR y es una paquetización del editor FCKEditor con lo cual aporta todas sus funcionalidades y permite la edición rica de contenidos html. Aunque funcional, se trata sólo de una prueba de concepto para mostrar lo que se puede hacer.

La idea básica sobre la que reside el componente es crear una página html al vuelo cada vez que se le asigne un valor al campo html. La página html generada se renderiza en un control y cuando se quiere acceder al html que el usuario haya modificado se hace a través de DOM y de las funciones Javascript que FCKEditor expone.

Un ejemplo de uso sería:

Lo que faltaría implementar que dejo en vuestras manos sería:

Soporte para Bindings en la propiedad html
Soporte para las funcionalidades de ajuste de tamaño según las normas de UIComponent

Os podéis descargar el código de ejemplo así como el del componente de aquí.

XSLT en AiR

Xavi Beumala — Mon, 31 Mar 2008 21:24:20 +0000

Aunque no salga en la lista de prestaciones, AIR soporta de forma indirecta la transformación de XML’s a través de XSLT’s. El kit de la cuestión recae en el uso del componente HTML o mejor aún de HTMLLoader, teniendo en cuenta que el componente HTML es un wrapper de HTMLLoader en Flex.

El componente HTMLLoader lo que hace es delegar la interpretación y renderizado de código html en WebKit (el core de Safari). Y es este, WebKit, el que por sí mismo soporta XSLT de una forma muy sencilla.

A continuación muestro una pequeña prueba de concepto de cómo poder invocar xslt’s contra xml’s a través de una pequeña clase.

En el navegador, una forma de aplicar xslt a un xml directamente sería hacer lo siguiente:

Creamos el xml que queremos transformar (model.xml)
Creamos la xlst que queremos (transformacion.xsl)
Aplicamos la xlst al xml mediante una processing instruction del estilo

Si cargamos modelo.xml en un navegador, éste parseará el xml y le aplicará la xslt indicada en la processing instruction dando como resultado un html (que es el que visualizaremos en el navegador).

Una de las funcionalidades que no podemos olvidar de HTMLControl es que es operativo aunque no esté incluido en la displayList. Podemos crear una clase que, usando un HTMLLoader pero sin representarlo visualmente, intercepte el XML, le añada la processing instruction y que capture el html resultante.

Este sería el circuito normal. Mediante HTMLLoader.loadString podemos cargar en el componente un xhtml generado al vuelo (el que queramos concatenado con la processing instruction). El problema de esto es que por algún extraño motivo, loadString no carga la xsl de transformación. Pero sí que funciona utilizando html.load (). Para paliar este comportamiento anómalo la siguiente clase lo que hace es crear un fichero temporal (que después se elimina) y que es el que el HTMLLoader cargará.

A continuación se muestra la clase XSLTProcessor.as

Una forma de usarlo sería desde una aplicación AIR basada en Flex:

Aún y tratarse de una aplicación funcional la clase anterior es una prueba de concepto que casi no he probado. La xsl es un poco chorra, pero es la primera que he encontrado en google.

La verdad que se me ocurren bastantes circunstancias en las que una xsl puede simplificar mucho un desarrollo. No sólo tenemos que pensar en las xsls como una herramienta para la capa de presentación, también podemos usarlas para transformar, adaptar o preparar modelos de datos: por ejemplo ordenación de árboles xml, agrupación, etc.

FlexReport

Carlos Rovira — Fri, 25 Jan 2008 22:32:21 +0000

Un nuevo proyecto Open Source acaba de salir. Se trata de FlexReport. El proyecto trata de cubrir uno de los puntos más flojos de Flex en la actualidad. Se trata de un componente para generar reportes mediante el cual puedes generar, previsualizar e imprimir reportes en Flex. El proyecto usa, entre otras cosas, AlivePDF internamente.

Puedes leer más al respecto aquí. El código del proyecto está aquí y puedes colaborar para mejorarlo.

Sistema de ventanas

Raul Diaz — Thu, 03 Jan 2008 14:04:35 +0000

Os presento una pequeña librería para gestionar ventanas en Flex, aunque está en fase beta creo que a más de uno nos va a ser de gran utilidad.
Características principales:

Aspecto de las ventanas configurable, por defecto tiene implementados el estilo de Windows XP y OSX Tiger.
Implementa un sistema de alerts propio al estilo del OSX. Puede funcionar como un simple alert o embeber nuestra propia clase o MXML.
Implementa un sistema de cajas laterales al estilo del OSX en las que podemos incrustar clases o MXMLs propios.
Cerrado de ventanas con efecto programable fácilmente. Cada ventana puede tener su propio efecto.
Puede reproducir sonidos al cerrar, maximizar, restaurar y minimizar.
Cada ventana sólo puede tener una ventana hija, ésta otra ventana hija y así sucesivamente.
Fácil transferencia de datos entre ventanas.
…

Espero que os sea de utilidad y por supuesto se aceptan sugerencias.

ILOG Elixir para Flex 3

Joan Garnet — Sat, 17 Nov 2007 21:04:40 +0000

Ha salido un beta de Elixir, un nuevo set de componentes que Ilog está desarrollando para Adobe y que verá la luz en cuanto salga Flex 3 a principios del 2008.
Por lo que veo, mayoritariamente son componentes que ofrecen soluciones a funcionalidades muy concretas:

Planning and scheduling displays, such as Gantt charts
Organizational charts
Maps for creating interactive dashboards
entre otros…

http://www.ilog.com/products/elixir/

Arquitectura de Adobe Flex 2 (III)

Carlos Rovira — Thu, 13 Sep 2007 21:02:19 +0000

Continuamos con nuestro recorrido a través del framework de Flex. En el último capítulo de esta serie comentamos las interioridades del framework para ver como funcionan las cosas “detrás de las cámaras” en Flex. En esta nueva entrega veremos como extender UIComponent para realizar nuestros propios componentes. El motivo de extender UIComponent es crear una pieza que encaje a la perfección dentro del ciclo de vida de nuestra aplicación y se beneficie de la infraestructura que nos da el framework de Flex. De esta forma conseguiremos un rendimiento óptimo.

La creación de componentes para Flex es un arte en si mismo y solo la experiencia y el estudio de otros componentes nos llevará a conseguir soluciones realmente interesantes. A su vez, es muy normal que en el día a día, desarrollando con Flex necesitemos alguna funcionalidad inexistente en los componentes base de Flex. Es en ese momento cuando necesitaremos de nuestros conocimientos de la arquitectura de Flex para solventar estos problemas creando nuestras propias extensiones.

Creando componentes a partir de UIComponent

A continuación podemos ver el mínimo código necesario para crear un componente en Flex:

Como podéis ver es bastante sencillo. Ahora bien, de esta forma solo crearíamos un componente en blanco que no haría nada. Ni siquiera veríamos nada en la pantalla. En el constructor podemos añadir escuchadores de eventos que sean necesarios en el componente. Por ejemplo UIComponent aprovecha el constructor para añadir escuchadores para el teclado o el manejador del foco.

Añadiendo objetos

Para empezar a añadir contenido al componente podemos hacerlo sobreescribiendo el método createChildren(). Por ejemplo, en el siguiente ejemplo comenzamos llamando al método del componente padre y posteriormente añadimos un campo de texto si este todavía no ha sido creado con anterioridad por alguna super clase:

Este método será llamado por el framework de forma transparente al crear el componente. Es dentro de este método donde podemos crear cualquier sub componente o skin y añadirlo al displaylist del componente con addChild().

Tamaño de los componentes

Seguidamente, es tiempo de definir el método measure(), el cual se encargará de gestionar los tamaños del componente (tamaño mínimo, tamaño por defecto, …) y de los componentes hijos:

En el ejemplo indicamos que el tamaño base y mínimo deben ser de 50 pixeles tanto para el ancho como para el alto. Como vimos en el anterior artículo, siempre que queramos recalcular el tamaño del componente, llamaremos a invalidateSize(). NUNCA debemos de llamar directamente a este método. Otro método a tener en cuenta es setActualSize(), el cual se suele usar internamente para indicar el tamaño de los componentes hijos cuando se redibuja un componente.

Cambiando propiedades

El siguiente método es commitProperties(). Este se usa para modificar las propiedades de un componente. Gracias a este método nos aseguramos que los cambios en dichas propiedades se hacen en el orden y forma esperado por el programador. Lo normal es que cambiemos una propiedad dentro de un componente y, de paso, modifiquemos una variable flag de forma que en este método hagamos algún tipo de procesamiento necesario al cambiar la propiedad. El método de invalidación que debemos de usar para llamar a este método es invalidateProperties().

Los flags nos permiten optimizar el rendimiento de este método de forma que solo se ejecuten determinadas partes del mismo. Este método es llamado justo antes de calcular el tamaño del componente y el redibujado del mismo. También es el lugar más apropiado para crear y eliminar subcomponentes de acuerdo con cambios determinados en las propiedades.

Visualizando el componente

Ha llegado el momento de visualizar el componente. Este es el método que tiene toda la carga de trabajo a la hora de representar gráficamente el estado del componente. Como cabría de esperar, NO debemos de llamarlo directamente. Debemos de invocar invalidateDisplayList() de forma que marquemos el componente para su redibujado en el próximo frame.

Como podéis ver en el ejemplo, primero llamamos al mismo método de la super clase. A partir de esta linea podemos usar este método para dibujar lo que creamos conveniente (en el ejemplo dibujamos un rectángulo), redimendionar sub componentes, cambiar estilos y, en general, todo lo que trate de cambiar la apariencia visual del componente.

Conclusión

Ahora ya tenemos la información básica suficiente para crear un componente desde cero. Todavía quedan otros aspectos a tener en cuenta (estilos, skinning, manejo del foco y del teclado, etc…). Pero en estos momentos ya sabemos cuales son los métodos que el framework de flex utiliza internamente para hacer su magia y podemos empezar a crear componentes que actúen dentro del sistema como si de un componente del framework se tratara.

En el siguiente artículo pondremos todo lo visto en práctica a través de un ejemplo con un componente real extendiendo de otro ya existente para reutilizar su funcionalidad. De esta forma podremos demostrar las ventajas de conocer la arquitectura de componentes de Flex y reutilizar la funcionalidad ya creada por los ingenieros de Adobe.