Voilà quelques temps que nous nous activions sans donner de nouvelles…, il est temps de corriger tout ça.
Aussi, pour démarrer cette nouvelle année du bon pied, La Fabrick vous propose une petite application de génération de code AS3 à partir d’un schéma XSD.

Ce petit outil nous a été utile pour pas mal de projets développés pour nos premiers clients, alors pourquoi ne pas vous en faire profiter ? Peut-être deviendrez-vous aussi MdaME-addict ?

Retrouvez toutes les infos sur http://mdame.lafabrick.comAutres articles sur le même sujet

• API de dessin en AS3
• Crée ton navigateur perso avec 5 lignes de code !
• Flex Builder 3 et le PHP ( PDT ) : installation
• Skiner un composant Flex 3 avec Fireworks CS3 [Tutoriel Vidéo]

Pour ceux qui utilisent l’API de logging de Flex, au sein d’une application AIR ont certainement remarque qu’il manquait cruellement une Target « fichier » pour tracer dans un fichier texte (même si le résultat de la fonction trace se retrouve enfoui quelque part dans les tréfonds du répertoire de données du Flash Player).

Pour ceux qui se sont posés cette question, vous êtes sans doute tombés (Ô joie) sur la FileTarget de notre ami Mike Chambers dans l’AS3 core lib.

Pour ceux qui se sont demandé s’il y avait un équivalent du RollingFileAppender de log4j en Flex (j’espère qu’il en reste, sinon restez, c’est bien quand même !), eh bien vous êtes certainement tombés sur l’ensemble vide.

N’y tenant plus, j’ai craqué sur une extension de la FileTarget pour créer le RollingFileTarget. Vous en voulez ?

Un rapide point sur l’API de logging

Et pourquoi pas un bon vieux trace("qui tâche") ?
Simplement parce que trace() trace tout, tout le temps, sans indication complémentaire sur le moment, ou la criticité de l’événement tracé. En clair, c’est très pratique pour en phase de test simple, lab ou autre, mais devient très vite inapproprié dès qu’on entre dans un développement structuré.

Comment faire de jolies traces bien propres Aïe

C’est très simple (cf. doc Flex) :

La target

/* Create a target. */
var logTarget:TraceTarget = new TraceTarget();

/* Log only messages for the classes in the mx.rpc.* and
mx.messaging packages. */
logTarget.filters=["mx.rpc.*","mx.messaging.*"];

/* Log all log levels. */
logTarget.level = LogEventLevel.ALL;

/* Add date, time, category, and log level to the output. */
logTarget.includeDate = true;
logTarget.includeTime = true;
logTarget.includeCategory = true;
logTarget.includeLevel = true;

/* Begin logging. */
Log.addTarget(logTarget);

Vous noterez l’usage de la TraceTarget qui va indiquer d’envoyer les traces vers la console et donc faire comme la fonction trace().
La target permet d’aller un peu plus loin en indiquant notamment :

• le niveau de log : toute trace d’une criticité inférieure au niveau défini sera donc ignorée
• des filtres sur les catégories de log : ces filtres vont permettre de n’envoyer sur la cible que les traces correspondantes

Le logger

Nous avons donc une cible, maintenant il faut tracer ! Pour cela, il suffit de créer un logger :

private static var _logger:ILogger = Log.getLogger("com.lafabrick.classes.UneClasse");

Il est en général recommandé de créer un logger par classe de façon statique pour limiter le nombre d’instances en mémoire.
Vous pouvez noter l’utilisation de la notation sous forme de packages permettant de faire le lien avec les filtres définis au niveau d’une target.
Pour utiliser le _logger, vous pouvez appeler les méthodes suivantes :

_logger.debug("Trace niveau debug");
_logger.info("Trace niveau info");
_logger.warn("Trace niveau warning");
_logger.error("Trace niveau error");
_logger.fatal("Trace niveau fatal");

Les appels provoqueront l’ajout de votre trace à tout target définie correspondant au paramétrage de votre logger (catégorie et niveau).

Faire sa target personnalisée

Il ne reste plus qu’à écrire une target personnalisée qui va écrire dans un fichier au lieu d’écrire dans la console.

Vous pouvez pour cela étendre la classe AbstractTarget ou LineFormattedTarget (cette dernière prendra en charge la mise en forme du message pour vous, donc bien pratique).

C’est ce qu’a fait Mike avec sa FileTarget que je vous laisserai consulter sur Github.

La RollingFileTarget

C’est sur ce modèle que j’ai développé la RollingFileTarget dont l’objectif est de pratiquer une rotation sur un fichier de log selon deux critères :

1. La date
   Objectif : un fichier de log par jour, par mois ou par an
2. Le poids
   Objectif : la taille d’un fichier de log ne doit pas excéder N octets

Utilisation

Il s’agit d’une target classique, utilisable comme la TraceTarget :

var fileTarget:RollingFileTarget = new RollingFileTarget(new File("app-storage:/logs/monappli.log"));
fileTarget.filters = ["*"];
fileTarget.includeDate = true;
fileTarget.level = LogEventLevel.ERROR;
fileTarget.includeTime = true;
fileTarget.includeCategory = true;
fileTarget.includeLevel = true;
fileTarget.rollingInterval = RollingFileTarget.DAY_INTERVAL; // Un fichier de log par jour
fileTarget.maxLogFileWeight = 0; // Pas de limite de taille de fichier
fileTarget.maxLogBackups = 7; // Une semaine de roulement sur les fichiers de log
Log.addTarget(fileTarget);

A noter les trois propriétés suivantes :

• rollingInterval : le mode de roulement par date. Vous avez le choix entre RollingFileTarget.DAY_INTERVAL, RollingFileTarget.MONTH_INTERVAL, RollingFileTarget.YEAR_INTERVAL, RollingFileTarget.NO_INTERVAL
  Je ne traduis pas, j’imagine que vous comprenez
• maxLogFileWeight : la taille maximale d’un fichier de log, en octets.
  Pour limiter la taille d’un fichier de log à 5Mo par exemple, vous pouvez indiquer maxLogFileWeight = 5000000. Une valeur à zéro désactive la rotation selon la taille du fichier.
• maxLogBackups : le nombre maximum de backups à conserver.
  Le principe réside en la conservation d’un nombre suffisant de logs pour retrouver les éléments importants ayant pu se passer. En général, une semaine de log suffit pour retrouver ses petits pour une application utilisée raisonnablement.

A savoir que ce motif est utilisé par la target pour détecter les backups existants dans le répertoire de stockage de votre fichier de log principal et gérer ainsi proprement les backups entre deux lancements de l’application (oui, c’est rare de laisser tourner son appli pendant 2 semaines sans l’arrêter…)

Je n’ai donc pas préféré laisser le choix sur le motif de renommage pour éviter les problématiques pouvant évidemment en découler. En même temps, on a affaire à des fichiers de logs…

Note importante : ces deux politiques sont combinables mais il est plus que conseillé de choisir entre un roulement sur le poids OU un roulement selon la date pour conserver des backup dans un ordre cohérent. En effet, si vous choisissez de combiner la rotation sur la taille ET sur le poids, vous aurez maxLogBackups fichiers de log suivant le motif AAAA-MM-JJ-nom.log et maxLogBackups fichiers de log suivant le motif nom.log.X.

J’envisage à terme que lors d’une rotation par date, l »ensemble des fichiers de backup par taille existants soient préfixés de la date du jour pour grouper correctement l’ensemble.

Téléchargement

Vous pouvez gracieusement télécharger, utiliser, modifier cette classe comme bon vous semble, La Fabrick déclinant toute responsabilité sur un quelconque dommage, problème ou perte d’information liée à son utilisation, de manière directe ou indirecte. Veillez également à respecter le copyright indiqué en entête du fichier, merci !

A noter bien entendu que cette classe utilise l’API d’accès au système de fichiers de AIR et ne peut donc être utilisée qu’au sein d’application compilées avec ce runtime.

Bons logs…Autres articles sur le même sujet

• Un projet Java / Flex avec Maven 2
• AIR 2 : appeler un JAR exécutable via un NativeProcess
• Caresse-toi le flex : FlashPlayer 10.1 et Multi-toucher
• ZXPackager : application pour l’empaquetage ZXP d’extensions CS5

Fonctionnement et limites d’un NativeProcess

Packaging de l’application

Pour diverses raisons de sécurité, une application AIR utilisant un NativeProcess doit être packagée dans le format de la plateforme cible (exe pour Windows, dmg pour Mac, rpm / deb / … pour Linux). Fini donc dans ce cas le pratique fichier .air qui marche partout !
Vous devez également indiquer dans le descripteur de l’application qu’il s’agit d’une application au profil « extendedDesktop » lui conférant donc les capacités d’exécuter un NativeProcess.
Vous devez ouvrir le fichier monAppli-app.xml et modifier la balise <supportedProfiles>

<supportedProfiles>extendedDesktop</supportedProfiles>

A partir de là, si vous tentez d’exporter un fichier .air, vous aurez un joli message d’erreur vous invitant à changer de profil.

Considérations de sécurité

Si AIR sans native process dispose de limitations de sécurité, dès lors que vous utilisez un native process, vous ouvrez la porte… Il est donc bon d’anticiper et de faire un maximum de vérifications sur vos appels pour éviter un remplacement d’un exécutable par un autre, moins sympathique, par exemple…

Prêt ? On code

Paramétrage

Un native process a besoin d’un contexte d’exécution. Ce contexte est défini à l’aide de l’objet NativeProcessStartupInfo décrivant notamment les éléments suivants :

• workingDirectory : le répertoire d’exécution
• executableFile : l’exécutable à lancer
• arguments : la liste des arguments à passer à l’exécutable (Vector.<String> sous Flash Player 10, ou un bête Array sinon)

Vous pourrez alors instancier un objet NativeProcess et lui passer cet objet de paramétrage avant de le lancer.

Lancement & suivi de l’exécution

Le lancement d’un NativeProcess est asynchrone. Il propose donc un certain nombre d’événements vous permettant de suivre son exécution une fois lancé, notamment :

• ProgressEvent.STANDARD_OUTPUT_DATA : écriture sur la sortie standard
• ProgressEvent.STANDARD_ERROR_DATA : écriture sur la sortie d’erreur
• IOErrorEvent.STANDARD_OUTPUT_IO_ERROR : déclenché lorsqu’une erreur apparaît en tentant de lire la sortie standard
• IOErrorEvent.STANDARD_ERROR_IO_ERROR : déclenché lorsqu’une erreur apparaît en tentant de lire la sortie d’erreur
• NativeProcessExitEvent.EXIT : déclenché lors que l’exécution du process est terminée

Lecture de l’entrée / sortie standard

Bien que tout à fait possible, la lecture de la sortie standard ou d’erreur via le listener ProgressEvent.STANDARD_OUTPUT_DATA ou ProgressEvent.STANDARD_ERROR_DATA n’est pas fiable à 100% concernant le contenu retourné : la sortie étant « bufferisée », vous n’aurez donc pas systématiquement le même résultat selon la machine exécutant le programme, à chaque appel de votre listener… N’utilisez donc la lecture de sortie standard que pour afficher ce qui se passe, ou à la limite récupérer la totalité du contenu écrit une fois le process terminé…

Appeler un JAR

Rappels

Pour appeler un JAR en Java, il doit être exécutable (bah oui…), et appelé en ligne de commande de la manière suivante :

java -jar monJar.jar [-cp jars du classpath]

Nous sommes dans une appli AIR, donc évitons de surcharger la commande à appeler avec un classpath, aussi je vous suggère d’utiliser les fonctionnalités d’export complets d’un JAR (si les licences associées vous l’autorisent) intégrant au final l’ensemble des sources dans un groooos JAR contenant tout ce qu’il lui faut pour fonctionner.
Notes :

• Les utilisateurs de Maven peuvent utiliser le plugin qui va bien pour ça.
• L’export eclipse, c’est pas mal non plus, il suffit de cocher la « case qui va bien » au moment d’exporter

Depuis un NativeProcess

On voit mieux ce qui se dessine:

1. Définir l’exécutable java dans vos « startup infos »
2. Définir les arguments
   • -jar
   • /chemin/vers/monJar.jar
3. Ajouter les listeners permettant de savoir lorsque l’exécution est terminée
4. Lancer le native process

Restons multi plateforme

Java est multi plateforme, oui, mais l’exécutable dépend de la plateforme, aussi il vous faudra récupérer le chemin vers votre JAVA_HOME (contenant le répertoire bin avec l’exécutable Java).
Vous avez donc deux solutions maintenant:

1. La plus simple (pour le développeur) : demander à votre gentil utilisateur où est son JAVA_HOME. Ça peut le faire si c’est un geek velu qui a compris qu’on ne parlait pas de venir danser chez lui (aïe, elle est rude celle-ci)
2. La plus compliquée (mais pratique pour l’utilisateur) : utiliser un autre exécutable (voire NativeProcess) qui remonte cette information ou permette de pointer directement sur l’exécutable en question

La seconde solution bien que séduisante est un peu plus longue à implémenter.
Pour les développeurs sous Windows, j’ai noté l’utilisation par Serge Jespers d’un petit (mais pratique) exécutable « jexe.exe » lançant le java.exe présent dans le %JAVA_HOME%\bin de la machine. L’utiliser vous évitera la première solution, sans vous lancer dans un développement spécifiquement dédié à cela (merci Serge). En revanche, si votre application est diffusée à un public d’utilisateurs non avertis, ils sont tout à fait susceptibles de ne pas avoir de variable JAVA_HOME définie sur leur machine : pensez donc à déterminer précisément votre cible avant de choisir une solution.

J’ai également noté en relisant un extrait de la licence du JRE que la redistribution est autorisée sous certaines conditions. Si vous les remplissez, vous pourriez carrément embarquer le runtime java dans votre application AIR, au risque de la faire gonfler en taille…

Un exemple ! Un exemple !

Voici un petit exemple de code permettant de lancer un JAR exécutable depuis une application AIR :

package com.lafabrick.nativeprocess
{
import flash.desktop.NativeProcess;
import flash.desktop.NativeProcessStartupInfo;
import flash.events.EventDispatcher;
import flash.events.NativeProcessExitEvent;
import flash.events.ProgressEvent;
import flash.filesystem.File;
import flash.system.Capabilities;

public class JarExec
{
protected var _process:NativeProcess;

public function JarExec()
{
}

public function getDefaultJavaExecutable():File
{
if (Capabilities.os.toLowerCase().indexOf("win") > -1)
{
return File.applicationDirectory.resolvePath("native/jexe.exe");
}
if (Capabilities.os.toLowerCase().indexOf("mac") > -1)
{
// TODO: Changer avec un paramètre de configuration
return new File("/System/Library/Frameworks/JavaVM.framework/Commands/java");
}
throw new Error("Système non pris en charge");
return null;
}

public function testJava(executablePath:String = null):void
{
// Tester le lancement de l'exécutable 'java'
try
{
var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
nativeProcessStartupInfo.workingDirectory = File.applicationDirectory;
nativeProcessStartupInfo.executable = (executablePath == null ? getDefaultJavaExecutable() : new File(executablePath));

var args:Vector.<String> = new Vector.<String>();
args.push("-version");
nativeProcessStartupInfo.arguments = args;

_process = new NativeProcess();
_process.addEventListener(NativeProcessExitEvent.EXIT, onJavaTestExit);
_process.addEventListener(ProgressEvent.STANDARD_OUTPUT_DATA, onStandardOut);
_process.addEventListener(ProgressEvent.STANDARD_ERROR_DATA, onErrorOut);
_process.start(nativeProcessStartupInfo);

trace("-- Début d'exécution");
}
catch (e:Error)
{
trace("Impossible de lancer le process\n" + e.message + "\n" + e.getStackTrace());
}
}
protected function onStandardOut(e:ProgressEvent):void
{
trace("STDOUT: " + _process.standardOutput.readUTFBytes(_process.standardOutput.bytesAvailable));
}
protected function onErrorOut(e:ProgressEvent):void
{
trace("STDERR: " + _process.standardError.readUTFBytes(_process.standardError.bytesAvailable));
}
protected function onJavaTestExit(e:NativeProcessExitEvent):void
{
trace("-- Fin d'exécution");
}
}
}

Cet extrait donne un aperçu, mais vous pouvez vous lancer (soyons fous) à installer le package suivant :

Pour Mac

Pour Windows

Pensez au clic droit > View Source…

Packager l’application

Comme je le disais au début de ce post, il est nécessaire de packager votre application dans le format natif du système d’exploitation visé. Vous avez deux solutions pour cela :

1. Passer par la dernière version de Flash Builder 4 qui propose cette fonctionnalité
2. Utiliser l’application PackageAssistantPro proposée par Serge Jespers (re merci Serge)

Il s’agit d’une application AIR utilisant des NativeProcess (et packagée en ligne de commande vu que l’application n’existait pas avant… Remarquez, la version 2 et plus ont probablement été packagées avec la version 1… Mais je m’égare)

Quelques liens

• Un petit exemple d’application utilisant un NativeProcess : ZXPackager
• ASDoc de la classe NativeProcess [EN]
• Un bon article pour démarrer [EN]

Autres articles sur le même sujet

• Un projet Java / Flex avec Maven 2
• Arduino #2 : Flash, socket et Processing
• ZXPackager : application pour l’empaquetage ZXP d’extensions CS5
• RollingFileTarget pour AIR 2.0 : let’s roll !

Cette application propose un moyen simple de packager vos extensions CS5 développées avec le nouveau SDK Creative Suite.

Les extensions ZXP

Depuis la CS5, Adobe propose un nouveau SDK de développement et un format d’extension commun a toute la suite logicielle.
Ce SDK, disponible ici, vous permet de développer vos propres panneaux et autres menus CS5. Le premier format de sortie est le MXP, toujours disponible, vous permettant d’exporter votre extension pour un logiciel cible.
Maintenant, avec la CS5, vous disposez d’un format commun, le ZXP, qui rend compatible votre extension avec toutes la suites CS.

Un fichier ZXP est défini par un manifeste xml, définissant le fonctionnement de l’extension (type, portée logiciel, …), et contient le (les) SWF de l’extension (une extension est en fait une pseudo application AIR, basée sur le SDK CS). Un fichier ZXP est signé numériquement. Vous devez donc avoir un certificat (PKCS12, PKCS11, JKS). Vous pouvez bien entendu utiliser votre certificat auto-signé préalablement créé avec Flash/Flex Buider.

Pour plus d’informations :

• Creative Suite SDK
• le blog CSSDK

Un fichier ZXP doit (habituellement) être compilé en utilisant le packager Java UCF. Et c’est là l’idée de cette petite application : ne pas avoir a redéfinir vos certificats et autres options pour chaque package, et vous proposer une interface plus « user friendly » que le terminal.

Fonctionnement

Démarrage, et préférences

Au premier démarrage, l’application doit obtenir vos préférences de base.

• Java Home

  Vous devez indiquer le chemin vers votre JDK/JRE java, si celui-ci ne correspond pas à celui par défaut (l’application intègre le packager jar UCF, et elle doit connaître le répertoire racine de Java pour pouvoir le lancer). Les chemins racines par défaut sont:

  • Pour Windows : ‘C:\Program Files\Java\jdk1.6.0′
  • Pour Mac : ‘/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0′

• Certificat

  Vous devez préciser l’emplacement de votre certificat (généralement un fichier de type .p12 ou .p11), ainsi que votre mot de passe. Ces informations sont nécessaires pour la signature de l’extension.

  • Fichier cible

    Vous devez indiquer le fichier de destination. L’extension .zxp est ajoutée automatiquement.

  • Source de l’extension

  Les sources de l’extension, comme défini dans la nomenclature du SDK CS, doivent correspondre à ce schéma:

  
  Ce répertoire est construit préalablement par la tâche ant de compilation, dans votre projet (cf. en fin d’article, le téléchargement du projet test d’extension)
  Vous devez pointer sur le répertoire « bin ».

  • Démarrer un nouveau package;
  • Ouvrir et installer l’extension via Extension Manager (vous devez bien entendu avoir préalablement installé Extension Manager CS5)
  • Projet fxp
  • Archive zip du bin de test

Définition de votre extension

Un package ZXP a besoin de 2 informations : le nom et l’emplacement de votre extension cible, et l’endroit où se trouve le répertoire « bin » de votre extension.



Une fois le packaging démarré, un message d’attente s’affiche.



Finalisation

Une fois le package créé, l’application vous propose de :



Téléchargements

ZXPackager

Extension de test

Autres articles sur le même sujet

• [Flex 3 Beta] bug : Application File doesn’t exist
• Un projet Java / Flex avec Maven 2
• AIR 2 : appeler un JAR exécutable via un NativeProcess
• RollingFileTarget pour AIR 2.0 : let’s roll !

Explication…

Layouts

Sans faire un article complet sur les layout (ce qui serait tout à fait possible et intéressant), on peut tout de même rappeler que le Flex 4 se distingue de Flex 3 via Spark par une volonté de mieux séparer le fond de la forme, il amène donc une notion de layout pour, comme son nom le suggère, organiser les composants d’un conteneur (par exemple un <s:Group>).
Exit donc la VBox ou la HBox (même si le VGroup ou le HGroup permettent de faire une transition en douceur), et bienvenue au Group avec layout :

<mx:VBox>
</mx:VBox>

devient donc

<s:Group>
<s:layout>
<s:VerticalLayout />
</s:layout>
</s:Group>

Au premier abord on dit : c’est plus verbeux ! Oui mais… le layout a cette particularité, en tant que propriété du composant, d’être modifiable à la volée, contrairement à un composant imposant sa mise en forme. Concrètement, là où la VBox présentera toujours ses enfants verticalement (c’est son nom !), le Group pourra changer à volonté de layout, donc très facilement passer de HorizontalLayout à VerticalLayout par exemple… On comprend encore mieux l’intérêt quand on se met à écrire son propre layout pour faire des choses un peu plus poussées visuellement !

Créer son layout

Pour créer un layout, il faut étendre la classe LayoutBase et surcharger a minima la méthode updateDisplayList() et certainement la méthode measure(). Ces méthodes gardent le même rôle qu’en Flex 3, mais avec l’adaptation contextuelle au Layout :

• updateDisplayList : dispose les enfants du conteneur et définit leur taille
• measure : donne la taille globale du conteneur

Vous pouvez accéder à la propriété « target » du layout qui correspond au conteneur auquel est appliqué le layout et travailler sur les enfant via les méthodes getElementAt() ou getVirtualElementAt(). La seconde méthode sert dans le cas où le layout est dit « virtualisé ».

Apparté : virtualisation de layout

Flex 4 permet, pour des raison de performance, d’utiliser un layout en mode « virtualisé », c’est-à-dire ne calculant la disposition des seuls enfants à afficher et non l’ensemble des enfants. Ce mode de fonctionnement s’applique particulièrement bien aux composants comprenant une liste de beaucoup d’enfants, mais ne calculant l’affichage d’une poignée à la fois, le reste attendant un scroll ou une action similaire pour être éventuellement affiché.

Application : création d’un ViewStackLayout

Avec les layouts en tête, il est inutile de demander pourquoi le composant ViewStack n’existe pas dans Spark : il devrait en pratique être un layout applicable à n’importe quel conteneur ! Même si le très bon article sur la virtualisation mentionne un prometteur je cite « (Planned) StackLayout », rien ne nous empêche d’en faire un simple, adapté à l’architecture Spark, plutôt que d’attendre (oui on est impatients à la fabrick).

Voici un exemple simple :

	import mx.core.IVisualElement;
	import spark.layouts.supportClasses.LayoutBase;

	public class ViewStackLayout extends LayoutBase {
		public function ViewStackLayout() {
			super();
		}

		protected var _index:uint;

		public function get index():Number {
			return _index;
		}

		public function set index(value:Number):void {
			if (_index != value && target != null && value >= 0 && value < target.numElements) {
				_index = value;
				target.invalidateSize();
				target.invalidateDisplayList();
			}
		}

		override public function updateDisplayList(width:Number, height:Number):void {
			var element:IVisualElement = useVirtualLayout ? target.getVirtualElementAt(index) : target.getElementAt(index);

			if (element) {
				element.setLayoutBoundsSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
				target.setActualSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
				target.setContentSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
			}
		}

		override public function measure():void {
			var count:int = target.numElements;

			for (var i:uint = 0; i < count; i++) {
				var element:IVisualElement = useVirtualLayout ? target.getVirtualElementAt(i) : target.getElementAt(i);

				if (i == index) {
					element.visible = true;
					element.includeInLayout = true;
					target.measuredWidth = element.getPreferredBoundsWidth();
					target.measuredHeight = element.getPreferredBoundsHeight();
				} else {
					element.visible = false;
					element.includeInLayout = false;
				}
			}
		}
	}

Vous noterez ici l’usage du getVirtualElementAt, en prévision de la gestion de la virtualisation.
Vous pouvez donc utiliser ce layout dans un DataGroup « piloté » par une tabbar par exemple comme ceci :

<s:TabBar id="tabEditors" />
<s:DataGroup id="editors">
<s:layout>
<mylayouts:ViewStackLayout index="{tabEditors.selectedIndex}" />
</s:layout>
<!-- Enfants... -->
</s:DataGroup>

De cette façon, le jour où vous voudrez présenter ces éléments sous forme de CoverFlow, en mode TimeMachine… vous n’aurez pas à modifier le code de votre composant, mais uniquement votre skin.

Alors, on n’est pas mieux habillé en Spark ?Autres articles sur le même sujet

• Reflex #1: une micro-architecture pour Flex… simple !
• Flex4 : composant personnalisé et skinning
• UIGFX practice : a CircularSlider component
• Proches de l’Ohio??? Les états esthètes de Flex4

The component

PieButton

I needed a button with 2 properties startAngle and angle, to be able to transmit these values to the skin:

package com.lafabrick.components
{
    import spark.components.Button;

    public class PieButton extends Button
    {
        public function PieButton()
        {
            super();
        }

        private var _angle : Number;
        private var _startAngle : Number;

        public function get angle():Number
        {
            return _angle;
        }
        [Bindable]public function set angle(value:Number):void
        {
            _angle = value;
            invalidateDisplayList();
        }

        public function get startAngle():Number
        {
            return _startAngle;
        }
        [Bindable]public function set startAngle(value:Number):void
        {
            _startAngle = value;
            invalidateDisplayList();
        }

    }
}

CircularSlider

This component could not extend directly SliderBase or TrackBase because the SkinPart thumb and track, as Button, are extending the TrackBase class.
I thus used the Range class, inserted the Slider architecture, and added specific geometric codes.
Check the component’s source code

Skin implementation

The design of the Skin is similar to a skin Slider standard, except that it uses a PieButton instead of a Button:

<?xml version="1.0" encoding="utf-8"?>
<s:SparkSkin xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark"
        xmlns:mx="library://ns.adobe.com/flex/mx"
        width="100%" height="100%"
        xmlns:components="com.lafabrick.components.*"
        >
    <!-- host component -->
    <fx:Metadata>
        [HostComponent("com.lafabrick.components.CircularSlider")]
    </fx:Metadata>

    <!-- states -->
    <s:states>
        <s:State name="normal" />
        <s:State name="disabled" />
        <s:State name="inactive" />
    </s:states>

    <!-- SkinParts
    name=track, type=com.lafabrick.uigfx.components.CircularButton
    name=thumb, type=com.lafabrick.uigfx.components.CircularButton
    -->

    <components:PieButton
        id="track"
        width="100%" height="100%"
        top="0" bottom="0" left="0" right="0"
        skinClass="skins.CircularTrackButtonSkin"/>

    <components:PieButton
        id="thumb"
        angle="20"
        width="100%" height="100%"
        top="0" bottom="0" left="0" right="0"
        skinClass="skins.CircularThumbButtonSkin"/>

</s:SparkSkin>

Under « thumb » and « track » Skin, the angular values are a mapped with the PieButton HostComponent. StartAngle and angle properties of the Pie primitive are directly extended from the host component.
Here follows a sample with Track Skin:

<?xml version="1.0" encoding="utf-8"?>
<s:SparkSkin xmlns:fx="http://ns.adobe.com/mxml/2009"
             xmlns:s="library://ns.adobe.com/flex/spark" 

             minWidth="21" minHeight="21"
             alpha.disabled="0.5"
             xmlns:uigfx="http://uigfx.lafabrick.com"
             xmlns:primitives="com.lafabrick.uigfx.primitives.*">

    <fx:Metadata>
        [HostComponent("com.lafabrick.components.PieButton")]
    </fx:Metadata>

    <s:states>
        <s:State name="up" />
        <s:State name="over" />
        <s:State name="down" />
        <s:State name="disabled" />
    </s:states>

    <primitives:Pie
        top="0" bottom="0" left="0" right="0"
        gap="2"
        innerOffset="-2"
        offset="-2"

        innerRadius="0.7"
        angle="{hostComponent.angle}"
        startAngle="{hostComponent.startAngle}"
        >

        <primitives:fill>
            <s:RadialGradient>
                <s:GradientEntry color="#006699" />
                <s:GradientEntry color="#009EE0" />
            </s:RadialGradient>
        </primitives:fill>

        <primitives:filters>
            <s:GlowFilter inner="true" color="#000000"
                blurX="10" blurY="10" alpha="0.4" />
        </primitives:filters>

    </primitives:Pie>

</s:SparkSkin>

Result

You can check these for more info: Link, and source code.

PS: Thanks to Hervé for review and corrections!Autres articles sur le même sujet

• Flex4 : composant personnalisé et skinning
• uigfx project : Flex4 primitives library / Fireworks extension
• Flex 4 et les layouts – Faire une ViewStack « pure » Spark
• Primitive DashedLine : une petite ligne bien utile

Vous le savez surement, la beta de Flash Player 10.1 nous permet maintenant à nous aussi, practiciens de la flash platform, d’entrer dans l’ère de l’expérience tactile. « Pretty exciting »! pourrait-on s’exclamer, mais puisque l’air du temps est plutôt à l’identitaire national, faisons un effort et parlons « franc » : le multi-toucher, çà envoie bien du cervelas en croûte !!!

Bon alors par contre pour profiter dès aujourd’hui du jouet, il est nécessaire de valider une des conditions suivantes :
- posséder un macbook (pro) récent sous snow leopard ( 10.6 ) (je sais pas trop si ca marche avec les magic mouse)
- posséder un pc sous windows 7… avec écran multitouch
- ou encore plus rare, faire partie des betatesteurs du prochain flash CS(x)… et d’une licence de dev iphone… et d’un iphone… ( d’ici quelques mois, les possesseurs de la plupart téléphones/tablettes tactiles et du prochain flash CS(x) pourront eux aussi jouer ).

Installation

Si tu as passé la 1ère épreuve, il te reste l’épreuve pratique : l’installation du SDK et du runtime AIR 2.0 ( beta1 ou beta2 )

Pour une installation « optimale » :
- Flash Builder Beta2 : http://labs.adobe.com/technologies/flashbuilder4/
- une version stable récente du SDK Flex : 4.0.0.13875 datée du 29.01.2010 http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4 ( pas mal de choses ont évoluées depuis la version 4.0.0.10485 distribuées avec Flash Builder beta 2 )
- placez le contenu du SDK téléchargé dans : Dossier Flash Builder Beta2/sdks/
- Installez le runtime et téléchargez le SDK AIR 2 beta 2 cf. guide d’installation du SDK
- Dans les préférences de FlashBuilder/Eclipse : Flash Builder / installed Flex SDKs / , ajoutez le SDK modifié pour AIR 2.

Et maintenant, la création du projet :
Nouveau projet Flex : Application Type : Desktop / AIR, SDK version : 4.0 ( celle avec mise à jour du SDK AIR 2 )

AS3 et le multi-toucher, comment çà marche ?

Premièrement, on trouve maintenant dans le package flash.ui une nouvelle classe Multitouch.
Elle permet de tester les compatibilités de l’environnement ( nombre de pressions/doigts gérés, combinaisons tactiles gérés… ) , et de définir le « mode tactile » : Gesture ou TouchPoint.
Ce dernier précise si l’on veut capter les « combinaisons tactiles » classiques : Rotation, Glisser, Zoom et « Grand coup » ( NDLR = Swipe, déplacement de trois pression/doigts ) ou le détail de chaque pression/doigts. Dans la beta actuelle, seul Windows 7 permet la gestion du mode « TouchPoint », les utilisateurs de OSX devront se « contenter » des combinaisons classiques.

trace( 'max touch : ' , Multitouch.maxTouchPoints );
trace( 'supportsGestureEvents : ' , Multitouch. supportsGestureEvents );
trace( 'supportsTouchEvents : ' , Multitouch. supportsTouchEvents );
trace( 'supportedGestures : ' , Multitouch. supportedGestures );
if( Multitouch. supportsTouchEvents )
     Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
// par défaut = MultitouchInputMode.GESTURE

Ensuite c’est l’autoroute :ajout des écouteurs d’événements qui vont bien, et c’est bon… tu peux caresser ton flex. Chaque transformGestureEvent contient, en fonction de son type, un offSetX/offSetY ( pan & swipe ), un scaleX/scaleY ( zoom ) ou une rotation.

// gestures prises en charge par OSX 10.6 avec FP 10.1 b2
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_PAN, onGesture );
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_SWIPE, onGesture );
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_ROTATE, onGesture );
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_ZOOM, onGesture );

public function onGesture( e:TransformGestureEvent ):void
{
     // phase = GesturePhase.BEGIN, GesturePhase.UPDATE ou GesturePhase.END
     trace( 'Gesture :', e.type, ' phase :', e.phase );

     // tu fais des trucs en fonctions du types de toucher
     switch( e.type )
     {
           case TransformGestureEvent.GESTURE_PAN:
                  interactiveObject.x += e.offsetX;
                  interactiveObject.y += e.offsetY;
           break;

           case TransformGestureEvent.GESTURE_SWIPE: // déplace de 50 pixels
                  interactiveObject.x += e.offsetX * 50;
                  interactiveObject.y += e.offsetY * 50;
           break;

           case TransformGestureEvent.GESTURE_ZOOM:
                  interactiveObject.scaleX +=  e.scaleX - 1 ;
                  interactiveObject.scaleY +=  e.scaleY - 1 ;
           break;

           case TransformGestureEvent.GESTURE_ROTATE:
                  interactiveObject.rotation += e.rotation;
           break;
     }
}

Plutôt simple, mais plein de potentiel…

Avec ces 4 gestures on peut quand même « gérer » 8 + 4 + 2 + 2 soit 16 combinaisons si on prend en compte les directions de chaque gesture. Exemple : SWIPE horizontal = 1 fonction, SWIPE vertical = 1 autre, PAN horizontal = 1 fonction…
L’exemple du magazine interactif pourrait par exemple parfaitement bénéficier de ces différentes combinaisons. À ce niveau tout un vocabulaire tactile reste à imaginer/compléter.

Bref, moi je suis bien content de pouvoir me caresser le flex !!!

GestureTracker

Par contre, en vrai novice de la programmation orientée caresse, mes premières touches furent, comment dire… hésitantes; du coup je me suis créé un petit assistant pour m’aider à la tâche, ou à la touche : le GestureTracker, un petit système de notification de gestures. Le but : calculer et visualiser les gestures en cours, leur valeurs et les transformations globales appliquées.

Pour le moment c’est pour les projets AIR 2 sous Flex 4, la version AS3 à suivre…

C’est tout pour le moment, v’là pour l’exemple air ( AIR Runtime 2.0 beta 2 est requis) , le swc du SparkGestureTracker et les sources.

Pour plus d’infos :
Un tuto sur le multitouch , une partie des réponses aux nombreuses interrogations sur les compatibilités actuelles et à venir.

Autres articles sur le même sujet

• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Interfaces tangibles : le futur du multitouch
• MAX 09 – Le multitouch
• RollingFileTarget pour AIR 2.0 : let’s roll !

uigfx library

ExclusionRect

Draw a rectangle with rounded corners (« radius » property), with a rounded rectangular punch optional.
The roundness of the inner rectangle is defined by « innerRadius » property.
Constraints of the inner rectangle are defined with « innerTop », « innerBottom, « innerLeft » and « innerRight » properties.
Sample :

<uigfx:ExclusionRect
    radius="10"
    innerRadius="30"
    top="0" left="0" right="0" bottom="0"
    innerTop="0" innerBottom="20" innerLeft="0" innerRight="20">

    <uigfx:fill>
        <s:LinearGradient rotation="90">
            <s:GradientEntry color="#212121" ratio="0" />
            <s:GradientEntry color="#313131" ratio="1"/>
        </s:LinearGradient>
    </uigfx:fill>

    <uigfx:filters>
        <s:DropShadowFilter color="#000000" inner="true"
            distance="1" blurX="4" blurY="4"
            quality="3" alpha="0.8" />
    </uigfx:filters>

</uigfx:ExclusionRect>

Result :

PointsPath

This primitive allows you to draw a path, based on a list of points(ConstraintPoint).
Additionally, you can set a roundness to your primitive using the « radius » property

A PointsPath can be defined as « not closed » : in this case you can use the « closedPath » property and set it to false :

<uigfx:PointsPath radius="60" closedPath="false">
   ...
</uigfx:PointsPath>

Using constraint point

The ConstraintPoint class defines a point with constraints values (left, horizontalCenter, right; and top, verticalCenter, bottom)

<uigfx:ConstraintPoint top="0" horizontalCenter="0" />

Every single value can be expressed as a percentage, setting « valuesInPercent » property to « true » (by default, all values are expressed in pixel) :

<uigfx:ConstraintPoint valuesInPercent="true" top="10" horizontalCenter="-25" />

Sample

Draw a five branch star, with a rounded contour (« radius » property), and constraints points vector :

<uigfx:PointsPath
    radius="60" width="100%" height="100%"
    horizontalCenter="0" verticalCenter="0">

    <uigfx:points>
        <uigfx:ConstraintPoint top="0" horizontalCenter="0" />
        <uigfx:ConstraintPoint horizontalCenter="25" verticalCenter="-25"/>
        <uigfx:ConstraintPoint right="0" verticalCenter="-25" />
        <uigfx:ConstraintPoint horizontalCenter="40" verticalCenter="25" />
        <uigfx:ConstraintPoint right="40" bottom="0" />
        <uigfx:ConstraintPoint horizontalCenter="0" verticalCenter="40" />
        <uigfx:ConstraintPoint left="40" bottom="0" />
        <uigfx:ConstraintPoint horizontalCenter="-40" verticalCenter="25" />
        <uigfx:ConstraintPoint left="0" verticalCenter="-25" />
        <uigfx:ConstraintPoint horizontalCenter="-25" verticalCenter="-25" />
    </uigfx:points>

    <uigfx:fill>
        <s:SolidColor color="#353535" />
    </uigfx:fill>

    <uigfx:filters>
        <s:DropShadowFilter color="#000000" inner="true" distance="1"
            blurX="4" blurY="4"
            quality="3" alpha="0.8" />
    </uigfx:filters>

</uigfx:PointsPath>

Result :

ComplexPointsPath

This primitive allows you to draw a path with one or more contours, defined by ComplexConstraintPoint points.

Define a complex point

The ComplexConstraintPoint class defines a vector with a constraint position, and the position of its bezier curves list.

<uigfx:ComplexConstraintPoint
    horizontalCenter="-48" verticalCenter="-59"
    nextAnchorOffsetX="-2" nextAnchorOffsetY="4"
    prevAnchorOffsetX="7" prevAnchorOffsetY="-6" />

Just like the ConstraintPoint, all values can be expressed in percentage :

<uigfx:ComplexConstraintPoint
    valuesInPercent="true"
    top="10" horizontalCenter="-25"
    nextAnchorOffsetX="-2" nextAnchorOffsetY="4"
    prevAnchorOffsetX="7" prevAnchorOffsetY="-6" />

Single contour

Draw a path with a complex contour :

<uigfx:ComplexPointsPath top="0" bottom="0" left="0" right="0" >
    <uigfx:points>
        <uigfx:ComplexConstraintPoint left="0" prevAnchorOffsetX="4.59" top="36" prevAnchorOffsetY="5.36" />
        <uigfx:ComplexConstraintPoint left="0" bottom="0" />
        <uigfx:ComplexConstraintPoint horizontalCenter="-35" bottom="0" />
        <uigfx:ComplexConstraintPoint horizontalCenter="-23" bottom="18" />
        <uigfx:ComplexConstraintPoint horizontalCenter="3" bottom="2" />
        <uigfx:ComplexConstraintPoint horizontalCenter="2" bottom="0" />
        <uigfx:ComplexConstraintPoint right="0" bottom="0" />
        <uigfx:ComplexConstraintPoint right="0" top="0" />
        <uigfx:ComplexConstraintPoint left="34" nextAnchorOffsetX="6.07" top="0" nextAnchorOffsetY="4.56" />
        <uigfx:ComplexConstraintPoint left="44" top="20" nextAnchorOffsetY="13.81" prevAnchorOffsetY="-8.18" />
        <uigfx:ComplexConstraintPoint left="19" nextAnchorOffsetX="-7.6" prevAnchorOffsetX="13.81" top="45" />
    </uigfx:points>

    <uigfx:stroke>
        <s:SolidColorStroke color="#ffffff" weight="1" />
    </uigfx:stroke>

    <uigfx:fill>
        <s:LinearGradient rotation="90">
            <s:GradientEntry color="#333333" ratio="0" alpha="1"/>
            <s:GradientEntry color="#212121" ratio="1" alpha="1"/>
        </s:LinearGradient>
    </uigfx:fill>

    <uigfx:filters>
        <s:GlowFilter color="#000000" blurX="12" blurY="12" alpha="0.65"/>
    </uigfx:filters>
</uigfx:ComplexPointsPath>

result :

Multiples contours

Draw a path with multiples contours.
Each Contour object defines a part of the path. Basically, it’s used to process pathfinding, such as union or exclusion.
Each contour is defined on a Contour object, through the « contours » collection property. Like PointsPath, a Contour can be defined as unclosed, using « closedContour » property :

<uigfx:ComplexPointsPath top="0" bottom="0" left="0" right="0" >
    <uigfx:contours>
        <uigfx:Contour closedContour="false">
            <uigfx:points>
            ...

Below a complete sample code :

<uigfx:ComplexPointsPath top="0" bottom="0" left="0" right="0" >
    <uigfx:contours>
        <uigfx:Contour>
            <uigfx:points>
                <uigfx:ComplexConstraintPoint left="0" prevAnchorOffsetX="4.59" top="36" prevAnchorOffsetY="5.36" />
                <uigfx:ComplexConstraintPoint left="0" bottom="0" />
                <uigfx:ComplexConstraintPoint horizontalCenter="-35" bottom="0" />
                <uigfx:ComplexConstraintPoint horizontalCenter="-23" bottom="18" />
                <uigfx:ComplexConstraintPoint horizontalCenter="3" bottom="2" />
                <uigfx:ComplexConstraintPoint horizontalCenter="2" bottom="0" />
                <uigfx:ComplexConstraintPoint right="0" bottom="0" />
                <uigfx:ComplexConstraintPoint right="0" top="0" />
                <uigfx:ComplexConstraintPoint left="34" nextAnchorOffsetX="6.07" top="0" nextAnchorOffsetY="4.56" />
                <uigfx:ComplexConstraintPoint left="44" top="20" nextAnchorOffsetY="13.81" prevAnchorOffsetY="-8.18" />
                <uigfx:ComplexConstraintPoint left="19" nextAnchorOffsetX="-7.6" prevAnchorOffsetX="13.81" top="45" />
            </uigfx:points>
        </uigfx:Contour>
        <uigfx:Contour>
            <uigfx:points>
                <uigfx:ComplexConstraintPoint right="96" top="18" />
                <uigfx:ComplexConstraintPoint right="68" top="9" />
                <uigfx:ComplexConstraintPoint right="59" top="37" />
                <uigfx:ComplexConstraintPoint right="87" top="46" />
            </uigfx:points>
        </uigfx:Contour>
        <uigfx:Contour>
            <uigfx:points>
                <uigfx:ComplexConstraintPoint right="49" bottom="28" nextAnchorOffsetY="-11.87" prevAnchorOffsetY="11.87" />
                <uigfx:ComplexConstraintPoint right="28" nextAnchorOffsetX="11.87" prevAnchorOffsetX="-11.87" bottom="49" />
                <uigfx:ComplexConstraintPoint right="6" bottom="28" nextAnchorOffsetY="11.87" prevAnchorOffsetY="-11.87" />
                <uigfx:ComplexConstraintPoint right="28" nextAnchorOffsetX="-11.87" prevAnchorOffsetX="11.87" bottom="6" />
            </uigfx:points>
        </uigfx:Contour>
    </uigfx:contours>

    <uigfx:stroke>
        <s:SolidColorStroke color="#ffffff" weight="2" />
    </uigfx:stroke>

    <uigfx:fill>
        <s:LinearGradient rotation="90">
            <s:GradientEntry color="#333333" ratio="0" alpha="1"/>
            <s:GradientEntry color="#212121" ratio="1" alpha="1"/>
        </s:LinearGradient>
    </uigfx:fill>

    <uigfx:filters>
       <s:GlowFilter color="#000000" blurX="12" blurY="12" alpha="0.65"/>
    </uigfx:filters>
</uigfx:ComplexPointsPath>

Result :

An Extension for Fireworks

This library would not be complete without an export tools for Fireworks. Have a complex primitive is good, but how to find all the points and bezier curves without a headache? It’s the goal of this extension!

At this moment the exporter is able to :

• exports all paths and rectangles
• exports strokes
• exports fills (solid color and gradient)
• exports filters (gaussian blur, glow, drop shadow)

But for now, this exporter can’t :

• exports text

Installation

Simply download the extension (uigfx.mxp), and double click on it to launch the Extension Manager. The installation is automatic. Now, open Fireworks, and open the primitives exporter panel in « Window > uigfx« .

How to use this extension

• Make your design
• Generate and place rules
  You’ill need 4 vertical rules and 4 horizontal rules to determine all constraints positions of each vector point. You can click on the « generate rules button », to put the rules around your selection (you need to select one or more objects). Move the rules, in order to have all vectors in the good area, like below :
  
• Export
  Click on the export button to export all selections. The exporter follows rules placement to determine vectors positions. If there’s no selection, all layers are exported. Of course, you will have to provide a name for the output file and a directory to save it in.
  Finally, an mxml file, containing a Spark Skin with all uigfx primitives, will be created. And voila !

This project is hosted on google code.Autres articles sur le même sujet

• Flex4 : skin et primitives
• Primitive DashedLine : une petite ligne bien utile
• UIGFX practice : a CircularSlider component
• Fireworks + Javascript = Spark Skin Pleasure !

Pourquoi utiliser une XSD?

Pour ma part, ces quelques raisons (et pour vous certainement plein d’autres raisons)

• Elle valide vos XML : parce que vous définissez en amont la structure de vos fichiers, une définition XSD permet de les valider;
• Parce que vous avez besoin de plusieurs écritures différentes d’un même jeu de donnés;
• Parce que, comme tout bon dèv, vous êtes fainéant…
• …et le fait que le programme valide tout et fait tout, tout seul, en suivant des règles normées ça vous va bien.
• Ca fait toujours bien d’avoir des fichiers XSD dans vos sources : ça envoie de la rosette, et vous pouvez vous la péter grave.
• …

Dans un usage Flex, l’objectif serait de pouvoir transformer nos objets AS en XML, et l’inverse, via les schémas de définitions. Ça tombe bien ! C’est ce qu’on va faire.

Où tu te caches XSD ?!

Dans la plupart des langages, nous avons la possibilité de discuter avec notre serveur en utilisant le protocole SOAP, basé sur XML. En utilisant ce protocole, nos objets sont “transformés” en XML, et transmis vers notre serveur. L’opération inverse existe lors de réception de données.
Mais pourquoi je vous parle de ça? Tout simplement parce que tout langage faisant du SOAP (ou du web service), à besoin de valider et de convertir de manière automatique les objets. Et je vous le donne en mille, ce sont les définitions XSD qui entrent en jeux (souvent ).

La mécanique XSD est utilisée, en interne dans Flex, pour l’encodage et le décodage d’objet SOAP ou WSDL. Ces classes, exclues du framework (vous n’y avez pas accès directement avec l’autocomplétion), se trouvent dans le package mx.rpc.xml.*.

Car vous allez le voir, il est relativement simple d’utiliser cette partie de Flex, pour un usage personnalisé du XML, en dehors du contexte RPC.

Des groupes, des geeks, des bidules

Donc c’est parti pour l’exemple. Je ne me casse pas la tête, et vous propose un biniou qui aura 3 éléments : des groupes, des gens (geek forcement), et des bidules… Je n’étais pas inspiré sur le 3ème éléments, mais il m’en fallait un….

XML et la définition XSD

Nous avons une infinité d’écriture XML possible, comme celle-ci :

<?xml version="1.0" encoding="UTF-8"?>
<groups>
    <group>
        <groupName>klingons</groupName>
        <geeks>
            <geek>
                <firstName>francis</firstName>
                <stuffs>
                    <stuff>
                        <name>mac</name>
                  </stuff>
                   <stuff>
                        <name>Flex</name>
                    </stuff>
                </stuffs>
            </geek>
        </geeks>
    </group>

    <group>
        ...
</groups>

Ou celle là :

<?xml version="1.0" encoding="UTF-8"?>
<groups>
    <group groupName="klingons">
        <geeks>
            <geek firstName="francis">
                <stuffs>
                    <stuff name="mac" />
                    <stuff name="Flex" />
                </stuffs>
            </geek>
            <geek firstName="roger">
                <stuffs>
                    <stuff name="pc" />
                    <stuff name="photoshop" />
                </stuffs>
            </geek>
        </geeks>
    </group>

    <group>
        ...
</groups>

Ou un mélange à votre sauce, vous faites bien comme vous voulez !

Nous allons donc écrire notre XSD, qui va définir le XML définit ci-dessus, celui qui utilise pleins d’attributs. Je prend celui là parce que la sortie XML est moins longue…. et mon article gagnera quelques lignes…. En ce moment mes articles sont un peu trop pépère… Ca doit être l’approche des fêtes.

Bref !

Le but est de réaliser une XSD la plus complète possible, ou toutes les parties sont typées (SimpleType ou ComplexeType). C’est important pour la suite, car chaque type sera “mappé” avec la classe ActionScript qui lui correspond.

Dans notre exemple, nous avons 3 collections (groups geeks, stuffs) et 3 éléments (group, geek, stuff)… D’accord je ne me suis pas foulé les doigts sur ce coup là !

Le schéma XSD n’est finalement qu’un fichier XML standard :

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="schemas/geeks"
    xmlns="schemas/geeks">

    <xsd:element name="groups" type="groupsCollectionType" />

</xsd:schema>

L’élément principale, le noeud “<groups>”, est la base de notre schéma. Le type correspondant va s’appeler groupsCollectionType.

La version actionScript de ce type groupsCollectionType serait un Array ou ArrayCollection (ou tout autre type de collection d’objet).
groupsCollectionType est une séquence, un réceptacle de 0 à n éléments de type group (le nombre d’instances minimum et maximun est défini par minOccurs et maxOccurs).

<xsd:complexType name="groupsCollectionType" mixed="true">
    <xsd:sequence>
        <xsd:element name="group" type="groupType"
            maxOccurs="unbounded" minOccurs="0" />
    </xsd:sequence>
</xsd:complexType>

Le type group est composé comme suit :

<xsd:complexType name="groupType" mixed="true">
    <xsd:sequence>
        <xsd:element name="geeks" type="geeksCollectionType"
            minOccurs="0" maxOccurs="1"  />
    </xsd:sequence>

    <xsd:attribute name="groupName" use="required" type="xsd:string" />

</xsd:complexType>

On retrouve le noeud geeks, unique, mais non obligatoire (minOccurs= »0″ maxOccurs= »1″), qui sera défini dans un type geeksCollectionType de la même manière que groupsCollectionType.
Les attributs du noeud sont placé à la suite de la séquence d’éléments. Ils peuvent être requis ou optionnel, définit par l’attribut use. On peut aussi le définir “prohibited” même si je ne vois pas vraiment l’intérêt…

Et on continue comme cela, en rentrant en profondeur dans nos différent objets. La syntaxe n’est pas compliquée, il suffit de se pencher un peu sur les spécifications de la W3C.

Vous trouverez ici la XSD complète de notre exemple.

Côté ActionScript

Nous avons besoin de 3 objets, qui correspondent aux 3 types d’éléments de notre XML : des groupes de Geek, des Geeks, des Stuffs.

Là, rien de plus basique.

• La classe GeekGroup : avec une propriété groupName, et une collection geeks (les geeks membres du groupe)
• La classe Geek : avec une propriété firstName, et une collection stuffs (les bidules du geek)
• La classe Stuff : avec une propriété name, le nom du bidule

Vous vous rendez compte, tout d’un coup, que je ne vous ai absolument rien appris dans ce paragraphe. Passons à la suite.

Les classes de gestion XSD

Nous avons une XSD et des objets AS prêts à être convertis. Regardons de plus près les classes exclues dont nous avons besoin:

• mx.rpc.xml.SchemaTypeRegistry : cette classe est une sorte de dictionnaire, ou l’on référence les différents types du schéma XSD, avec leurs classes actionScript associées.
• mx.rpc.xml.XMLDecoder : la classe qui permet de décoder une source XML, en suivant la XSD, vers un object typé actionScript.
• mx.rpc.xml.XMLEncoder : la classe qui permet d’encoder un objet AS en un fichier XML, en suivant la définition XSD.
• mx.rpc.xml.Schema : la classe contenant le schema XSD chargé.
• mx.rpc.xml.SchemaManager : point central du système, cette classe est utilisée par l’encodeur et le décodeur. Elle possède une référence au schéma (elle peut d’ailleurs contenir plusieurs schéma XSD), et utilise les références de classes et de type XSD enregistrés dans mx.rpc.xml.SchemaTypeRegistry.

Votre object en XML, via XSD

Dans un premier temps, il nous faut charger la définition XSD via un URLLoader :

var urlLoader : URLLoader = new URLLoader();
urlLoader.addEventListener( Event.COMPLETE, onLoadXsdComplete );
urlLoader.load( new URLRequest( "geek.xsd" ) );	

A la réception de la XSD, nous initialisons la classe Schema et le SchemaManager :

var _schema:Schema = new Schema();
var _schemaManager:SchemaManager = new SchemaManager();

_schema.xml = XML( urlLoader.data );
_schemaManager.addSchema( _schema );

Nous ajoutons la référence du manager de schéma dans nos objets d’encodage/décodage :

var _xmlDecoder:XMLDecoder = new XMLDecoder();
var _xmlEncoder:XMLEncoder = new XMLEncoder();

_xmlDecoder.schemaManager = _schemaManager;
_xmlEncoder.schemaManager = _schemaManager;

Ensuite, nous référençons les types contenus dans la XSD, avec les classes AS correspondantes :

var _schemaTypeRegistry : SchemaTypeRegistry;
_schemaTypeRegistry = SchemaTypeRegistry.getInstance();

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "groupsCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "groupType"), GeekGroup);

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "geeksCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "geekType"), Geek);

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "stuffCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "stuffType"), Stuff);

Enfin, nous récupérons notre XML tout bien valide, image de l’objet targetObject, via l’encodeur XML (il faut préciser le nom du noeud “root” de la XSD) :

var xmlList : XMLList = _xmlEncoder.encode( targetObject,
    new QName( _schema.targetNamespace.uri, "groups") );

Super simple.

D’un XML vers un Object

C’est magique, c’est tout pareil ! au lieu d’utiliser XMLEncoder, on utilise XMLDecoder, et on change la référence de l’objet par notre XML :

var obj : ArrayCollection = _xmlDecoder.decode( myXml,
    new QName( _schema.targetNamespace.uri, "groups") ) as ArrayCollection;

Automatisation

Je vous propose un set de classes pour faire tout ça de manière automatique.

• XSDConverter : un convertisseur XML via XSD.
  2 méthodes :
  • importFromXml( xml : *, xsdUrl : String, schemaTypes : Vector. = null ) : void
  • exportToXml( target : Object, xsdUrl : String, schemaTypes : Vector. = null ) : void

  En paramètre de ces méthodes :

  • la source : Object pour l’exportation, une String, un XML ou un XMLList pour l’importation;
  • xsdUrl : l’url de la xsd a charger;
  • schemaType : une collection (Vector) d’objet de type XSDType, définissant le mapping entre les types XSD, et les classes référentes AS.
• XSDEvent : l’évènement diffusé par XSDConverter (importSuccess, exportSuccess et conversionError (en cas de problème de conversion ou de chargement de la XSD ) ).
• XSDType : définition d’un type XSD, avec la classe AS associée.

Un petit exemple est disponible là, avec les sources sous ce lien.

Et donc….

… vous pouvez vous dire que “Ahh ! Maintenant que mes données sont automatiquement transformées en XML, je me sens mieux. Et comme j’ai gagné plein de temps, ba du coup je peux lire des articles fort intéressants comme ceux concernant le skinning ou les primitives dans Flex4. De toutes façons y’a trop de monde à la Fnac pour finir mes cadeaux….”

Autres articles sur le même sujet

• Pti truc du jour : Les CollectionEvent
• Cairngorm pour les fainéants… Tour d’horizons des code generator
• Developing with AFCS a.k.a Cocomo – Introduction
• Reflex #2 : vous reprendrez bien un peu de IOC ?

Ah oui, au fait, juste avant de commencer : un mot sur les Awards. Nous avons eu droit à une présentation des MAX Awards par Mark Hamil juste avant la session Sneak Peeks. On ne reviens pas dessus tellement nous avons trouvé ça pauvre en information. Nous sommes certains que les projets choisis sont effectivement géniaux, mais nous n’avons vraiment pas eu l’occasion d’en voir suffisamment et d’en entendre parler leurs concepteurs pour se faire une quelconque idée de la chose.

Voici plutôt un aperçu de ces Sneak Peeks particulièrement intéressants sur les innovations en cours chez Adobe. Le principe est simple : prenez Mark Hamil (Luke Skywalker pour les intimes) comme présentateur qui ne comprend rien aux technologies montrées, déguisez les ingénieurs Adobe en chevaliers de l’empire, Chewbacca ou princesse Leïa et vous obtenez un show de geek vraiment sympa et impressionnant.

Principe

Chaque équipe passe présenter son projet et doit rivaliser d’idées innovantes pour obtenir les clameurs de la foule en folie. Ca va vite, ils font souvent des blagues et vont parfois jusqu’à scénariser la présentation. C’est vraiment excellent ! Les infos passent très bien, on ne s’ennuie pas… Voyons voir.

Mobile

L’équipe mobile nous a présenté un jeu multi-joueurs utilisable depuis différents terminaux mobiles (Palm, Google Android, Nokia…), une application AIR sur portable et en mode web sur PC. Le principe technique est que ce jeu s’exécute côté serveur et que les images du jeu sont envoyées en streaming sur les terminaux (un peu comme une vidéo YouTube). Chaque commande est également envoyée au serveur pour lui permettre de calculer le comportement attendu pour le joueur.

Même si la technicité est certainement élevée et innovante, la pauvre bande passante du Wi-Fi disponible a montré les lacunes de l’outil. L’intérêt reste à notre sens assez limité, bien que nous ne soyons pas des spécialistes du jeu en ligne. On salue quand même la performance (faut le faire non ?)

Flash

La démo Flash est assurée par Chewbacca en personne. Il nous montre comment la future version de Flash Professionnel permettra de générer des animations de formes à l’aide d’un moteur physique pour leur donner un aspect particulièrement réaliste. L’exemple ci-après est réalisé à partir de dessins de formes vectoriel et d’activation de quelques cases à cocher…

On vous laisse imaginer les possibilités offertes au designer pour réaliser des animations réalistes et relativement complexes en quelques clics, c’est vraiment intéressant pour le monde de la création.

Flex pour mobile

Cette fois, c’est princesse Leia qui procède à la présentation d’un développement en environnement Flex avec le framework mobile. Concrètement, il/elle utilise des composants liste et champ de recherche, compile et lance une application ressemblant plus que fortement à une application iPhone de recherche et affichage d’informations.

Le résultat, affiché sur un iPhone (forcément…), est particulièrement réussi, très réactif. C’est impressionnant, en tant que développeurs Flex de voir la simplicité du développement Flex apportée sur un environnement de ce type !

Photoshop

On ne sait plus à quoi s’attendre sur Photoshop. Le logiciel vit depuis un certain temps, et pourtant cette présentation nous a laissé sur le c… pardon, pantois.

Concrètement, l’équipe a travaillé sur une fonctionnalité de gommage intelligent (mathpatch), interprétant la globalité de l’image pour remplacer le contenu supprimé par un contenu particulièrement réaliste. Le résultat est absolument hallucinant. Vous pouvez supprimer le fameux fil électrique qui rature le beau bâtiment à présent.

Ce fonctionnement a carrément été appliqué à des parties d’images : la démonstration montre le conférencier supprimer une usine de la vue de la photos. 20% de l’image est recomposée automatiquement. On constate déjà un peu plus l’intervention de la machine, mais en faisant attention. Bluffant !

Fireworks

L’équipe Fireworks a présenté une fonctionnalité de retour arrière sur ses actions de manière ciblée. Concrètement, vous travaillez sur une partie de votre image, puis une seconde et ne voulez annuler que les changements effectués sur la première partie, mais pas sur la seconde, vous pouvez sélectionner ladite première partie et annuler uniquement ces changements : particulièrement pratique pour les designers habitués à ce genre d’outils !

Dreamweaver

Nous n’avons pas particulièrement l’utilisation de Dreamweaver habituellement, mais on retient cette démonstration, particulièrement intéressante pour l’utilisation de la nouvelle norme HTML 5.

En l’occurrence, une nouvelle spécification est sortie (HTML 5) intégrant notamment un notion de Canvas, des interactions et animations pouvant être définies pour ce canvas. Adobe montre une forte volonté de tirer partie de cette nouvelle solution en permettant un copier coller depuis Flash dans Dreamweaver d’une animation Flash, Dreamweaver la transformant en animation native Canvas.

L’intérêt ? Pas de Flash Player, des performances excellentes, et une adéquation parfaite aux standards. Une excellente initiative pour tenter de se rapprocher du standard plutôt que chercher à l’évincer.

AIR : Rome

Attention, énorme application. Le conférencier nous présente un outil à l’ergonomie particulièrement réfléchie et léchée regroupant en quelque sorte le principale de chaque outil d’Adobe. Vous pouvez dessiner en vectoriel (Illustrator / Fireworks), ajouter des animations (Flash), importer des calques Photoshop, ajouter des écrans et créer une interaction type navigation entre écrans (Flash Catalyst).

Enfin, vous pouvez exporter votre travail en SWF, AIR, SVG, image, page HTML, PDF… Tout cela étant, également fonctionnel en mode Internet : il y avait de la bave sur les sièges…

Pour nous, c’est le vainqueur. C’est absolument impressionnant à voir ! Ca montre notamment les capacités offertes par AIR et confirme son positionnement sur une application Internet mêlée à une application de bureau.

Autres articles sur le même sujet

• Du HTML dans mon Flex…
• Live from MAX Milan : hands on thermo…
• MAX 09 – Le multitouch
• MAX 09 – Ça annonce !