MadeInFlex
Flex Hero: nuevos componentes para Desktop(II): Spark Form y Spark Formatters
Noviembre 26th, 2010 - [Enlace local]
En este post veremos dos de los nuevos componentes que nos trae esta release de Hero, Spark Form y Spark Formatters.
El Spark Form
Mantiene la funcionalidad del MX Form y añade mejoras para adaptarse a diseños más modernos, debido a que es totalmente customizable por ser un SkinnableContainer con estados visuals asociados. Su costumización se hace en la skin del componente.
La mejora más importante de este componente respecto a su predecesor es la madurez de su layout. El Spark Form usa restricciones basadas en un grid para posicionar cada FormItem. Además, el layout nos permite tratar las filas y columnas de forma más dinámica: las columnas y filas pueden incrementar o decrementar su amaño en tiempo de ejecución para adaptarse al contenido de la información y los errores de texto de ayuda o de validación, se pueden mostrar bajo demanda. Spark Form viene con dos layouts: por defecto el horizontal y también el llamado stacked, que distribuye los elementos verticalmente. En las imágenes vemos estos dos tipos de layout:


Clases relacionadas con el componente
Tenemos unas clases que se relacionan con el Spark Form y debemos tener en cuenta:
- Form – el componente SkinnableContainer que define el Form propiamente dicho
- FormItem – SkinnableContainer que define cada uno de los form items del form
- FormHeading – Sección de texto que nos denota el inicio de una sección en el formulario
- FormLayout – layout asociado al Form
- FormItemLayout – restricción basada en distribución tabular para posicionar cada FormItem
- FormSkin – la skin por defecto del Form
- FormItemSkin – la skin por defecto del FormItem con layout horizontal
- StackedFormItemSkin – la skin por defecto del FormItem con layout vertical
- FormHeadingSkin – la skin del FormHeading
Aspectos importantes de la clase FormItemLayout
FormItemLayout extiende a ConstraintLayout, una clase equivalente a las restricciones del mx Canvas. FormItemLayout usa los métodos internos getMeasuredColumnWidths y setLayoutColumnWidths para alinear las columnas de los FormItem. En este momento ConstraintLayout soporta las siguientes restricciones: left, right, top, bottom y baseline.
El comportamiento general de ConstraintLayout es el de un grid para definir el layout en regiones. Los elementos que constituyen el Layout se pueden alinear con las filas y columnas usando restricciones. También es possible hacer que los elementos del Layout se expandan a través de multiples filas y columnas para dar un major comportamiento y flexibilidad del posicionamiento.
ConstraintColumns y ConstraintRows
Las regiones dentro de un ConstraintLayout se definen con instancias de ConstraintColumn y ConstraintRow definidas dentro de dos propiedades de tipo vector, llamdas constraintColumns y constraintRows respectivamente. Cada ConstraintColumn y ConstraintRow puede tener o no un tamaño definido a nivel de píxel. Una columna de tamaño fijo no cambiará de tamaño aunque su contenido lo haga. Si un componente se expande a través de diferentes columnas, el espacio se distribuirá a través de las columnas. Se prevé que ConstraintColumn y ConstraintRow permitan determinar el tamaño porcentualmente en futuras releases.
Restricciones
Ya hemos comentado las restricciones que se pueden determinar. Cada elemento puede especificar restricciones respecto al contenedor principal, por ejemplo (left=”5″) , o respecto a una columna o fila, por ejemplo (left=”col1:5″).
Las restricciones left, right, top, and bottom, definen las fronteras del elemento respecto a la región o container. La restricción de baseline define el desplazamiento entre la línea de base definida por la fila que establece la restricción y la posición del elemento.
Estados del elemento FormItem
Los estados que nos define el elemento FormItem son: normal, disabled, required, requiredAndDisabled y requiredAndError.
El estado de error se da cuando el contenido del FormItem tiene valor INVALID (fallo de la validación). El estado required ocurre cuando el FormItem se especifica como requerido.
Error Handling en la validación
Un FormItem está pendiente de los eventos FlexEvent.VALID y FlexEvent.INVALID de los elementos que contiene. La propiedad elementErrorStrings contiene un Vector de errorStrings sobre los elementos del FormItem.
Para ver más:
Especificación
Video
Spark Formatters
Flash Player 10.1 lleva implícito un Nuevo conjunto de APIs para tratar la globalización de los datos, como el formateo de fechas, horas, números o monedas. Hero, usando estas APIs ha desarrollado los nuevos Spark Formatters. Estos formatean los datos basados en la configuración regional definida por el sistema operativo.
Esta versión de Hero nos proporciona 3 formatters para tartar la información correctamente: CurrencyFormatter, NumberFormatter y DateTimeFormatter:

Otro aspecto importante son las nuevas clases de Sort y SortField añadidas para tratar el comportamiento específico para ordenar los datos según la configuración regional. La nueva clase de Sort aprovecha el tratamiento de la configuración regional específica que trae Flash Player 10.1 para comparar strings, parsear números y monedas para ordenar debidamante.
Conceptos importantes
Para entender bien los nuevos formatters debemos tener en cuenta estos conceptos:
- flash.globalization: es el nuevo package añadido a Flash player 10 para acceder a las configuraciones locales que proporciona el SO en el que se está ejecutando el Flash player. Proporciona la siguiente funcionalidad:
- Formateo de fechas, horas, numeros y monedas según la configuración regional.
- Parseo de numeros y monedas según la configuración regional.
- Comparación de strings según la configuración regional.
- Conversion de strings a mayúsculas o minúsculas según la configuración regional.
- Proceso y parseo del Locale ID. - Locale data: los datos necesarios par poder tratar cada tipo de datos según las convenciones culturales de la región.
- Locale: se refiere al lenguaje, la escritura, y la región para los cuales el SO tiene un conjunto de reglas para tratar correctamente los datos.
- Locale ID: nos permite identificar el locale. Por ejemplo en_US o es_ES.
- Collation Order: Los datos se suelen ordenar alfabéticamente. Para ello ActionScript usa una comparación de los códigos Unicode. Otros idiomas utilizan otras maneras de ordenación. De aquí que se necesita otra forma de ordenacion.
Comparación entre MX formatters y Spark formatters
Una diferencia importante es el uso que hacen los Spark formatters del package flash.globalization para mejorar su funcionalidad. Los MX formatters usan el ResourceManager de Flex para acceder a la configuración regional y usar los datos adecuados.
Como consecuencia, los Spark formatters proporcionan un comportamiento adecuado al sistema operativo y tienen acceso a todas la localizaciones que este soporta, aunque este comportamiento puede variar según la plataforma en que se use. Por otro lado, los MX formatters tienen el mismo comportamiento en relación a los SO, pero limitados a los “locales” proporcionados por el developer.
Más información en: