Source

Ayant eu l’honneur et l’avantage de participer au BarCamp Summer Lyon, je vous propose un petit retour d’expérience sur cette excellente initiative d’un ensemble d’assoc’ actives de la région lyonnaise :

• Mix-IT
• LyonRB
• Club Agile Rhône-Alpes de Lyon
• Flex/Flasheurs
• MUG Lyon
• Lyon Java User Group
• Développeurs PHP de Lyon

L’objectif : donner l’opportunité à chacun de présenter un sujet qu’il connaît ou sur lequel il souhaite échanger librement. Les choix de sujets étaient proposés sur une base de volontariat, les sujets retenus votés à la gommette comme au bon vieux temps (comme on aime quoi).

Le public était quasi-exclusivement technique (à l’évidence), issus de SSII / éditeurs, et composé d’architectes, développeurs web, coach agile, chefs de projets, entrepreneurs…

En résumé, un bon rythme, des sujets « en vogue » avec échanges constructifs sur les intérêts / risques de chaque techno ou méthodo.

Voici un rapide retour sur les thématiques auxquelles j’ai assisté, pour alimenter la discussion et inviter à poursuivre cette initiative !

DevOps

En tant que newbie du sujet, j’ai cerné DevOps comme consistant en un ensemble de pratiques et principes d’échanges pour une meilleure communication entre équipes infra / support et équipes de développement. Ces principes se déclinant en :

• organisation projet,
• modes de communication,
• outils.

Une forte composante de cette méthodologie réside dans les deux premiers points : comment briser les barrières entre équipes de support, administrateurs système et équipes de développement. Cette cassure visant à impliquer chacun dans le process projet et fluidifier les échanges.

Pour cela, la méthodologie intègre fortement les principes de l’agilité, suggère une fréquence élevée de livraisons etc. … Pour plus d’infos, je vous invite à consulter l’article DevOps sur Wikipedia (anglais).

Niveau outils, nous avons échangé sur les systèmes d’intégration continue et de déploiement automatisé (installation et configuration de machine en un clic).

Un retour a été donné sur les outils suivants :

• Puppet (Ruby) : assez simple à prendre en main, grosse communauté
• CFengine : performant mais peu de retours d’expérience et pas d’interface graphique
• chef (beaucoup plus complexe)

Une limite signalée à propos de ces outils touche principalement les entreprises « désossant » les paquets standards selon leur propre norme, ne laissant donc on ne peut plus utiliser les paquets standards. C’est toujours bon à savoir

Les avantages sont en revanche multiples :

• Le versionnement d’un script puppet rend extrêmement simple toute procédure de retour arrière (rollback) sur le serveur.
• La montée en volume d’un parc de machines hébergées en interne devient un jeu d’enfant
• On peut aller jusqu’à envisager les backups (machine, données, sources)

L’administrateur déporte donc son travail sur l’outil puppet plus que sur le serveur lui-même, transformant son métier plutôt que l’annihilant (et au passage le rendant plus intéressant ? On aime bien ne faire les choses qu’une fois en général ).

D’un point de vue humain, un principe intéressant consiste à intégrer les équipes de support et d’administration le plus tôt possible dans les phases de conception d’un projet pour intégrer au mieux leur contraintes, et simplifier les échanges ultérieurs. En résumé, comprendre les problèmes des autres permet souvent d’y apporter une solution simple à laquelle on n’aurait jamais pensé. Ca paraît évident à dire, moins à faire !

Nous avons enfin échangé sur des problématiques comme :

• Combien ça coûte ? Quelques tuyaux résident dans le chiffrage :
  • A priori : estimer le gain sur la maintenance (très difficile)
  • A posteriori : estimer le gain en comparaison avec un autre projet (techniquement plus simple, mais souvent négligé voire oublié selon la coutume « ce qui est fait est fait »)
• Décloisonner demande un état d’esprit ouvert : lorsque les tensions sont déjà fortes, il y a fort à parier que la mayonnaise ne prenne pas

Et vous, êtes-vous DevOps ?

TDD / BDD

Source

Sans revenir trop longtemps sur le Test Driven Development et sa clique (JUnit, DBUnit, NUnit, FlexUnit, PHPUnit…), nous avons abordé un nouvel acronyme pour moi : BDD (Behavior Driven Development), dont le principe est bien mieux expliqué sur Wikipedia que je ne saurais le faire.

Le retour d’expérience a été donné principalement sur JBehave qui propose de rédiger des exigences sous forme de fichiers au format texte comprenant trois mot-clés principaux : GIVEN (définir une situation) WHEN (définir un événement déclencheur) THEN (définir le résultat attendu). Les phrases pouvant être rédigées comme vous le souhaitez.

L’idée diabolique est donc d’obtenir ce fichier d’un interlocuteur fonctionnel, que vous pouvez utiliser sans transformation pour développer des routines correspondant à chaque exigence et ainsi valider que votre programme y répond.

Même si (à mon humble avis) cette méthodologie demande un interlocuteur métier motivé – pour ne pas dire un « consultant AMOA ultra au point » – et certainement d’éliminer quelques freins, le principe d’alléger vos spécifications et de retrouver (par un heureux effet de bord) vos exigences dans votre code source est clairement intéressant. Je m’interroge également sur le glissement vers « l’algorithmie masquée » que peuvent représenter les fameux fichiers textes… Vaste programme.

Amis flexeurs, quelques early-adopters ont déjà expérimenté le principe basé sur Cucumber (Ruby). Si ça vous dit… En attendant, si vous faites du FlexMock, FlexMonkey et FlexUnit, c’est déjà pas mal !

Un petit regret, la difficulté d’aborder la question du « où s’arrêter » en fonction du projet mené : est-ce toujours rentable d’avoir une couverture de tests à 100% si votre projet a une durée de vie limitée… Même si cette question est particulièrement sujette à l’appréciation de chacun sans réellement connaître de règle.

Des spaghettis, des marshmallows

Source

Le dernier atelier reprenait le concept du marshmallow challenge.

Le principe : 18 minutes pour construire la plus haute tour de spaghettis surmontée d’un marshmallow avec comme accessoires du scotch et un fil de couture.
L’objectif : souligner la façon dont nous travaillons en équipe, dont nous fonctionnons face à un problème… Les résultats sont intéressants, je vous invite à tenter le coup si vous en avez l’occasion.

Je n’ai pas la photo de notre oeuvre éphémère… Mais ne regrettez rien

Merci à tous les organisateurs donc, à quand le prochain ?Autres articles sur le même sujet

• Le 8ème jour ils créerent le Volume
• Vous avez dis Flex3 Beta2 ?
• L’université Lyon1 cherche (aussi) 2 stagiaires
• ORM, Hibernate et contrariétés…

J’pensais pas faire ça aujourd’hui…, mais bon… moultes skins Spark à tomber : j’ai décidé de me helper myself et de gagner de l’argent ( enfin du temps pour commencer ). Du coup est née la petite commande Fireworks copyMXMLSelectionToClipboard, qui comme son nom l’indique presque, permet de copier une sélection dans Fireworks directement en MXML dans le ClipBoard. Elle est pas belle la vie ?!

En gros :
1. tu dessines tes trucs dans Fireworks, tu fais tes jolies dégradés, tes reflets, tes subtils petits floutés…
2. tu sélectionnes ce que tu veux mettre dans ta skin
3. tu lances la commande ‘UIGFx/SelectionToMXMLClipboard »
4. t’ouvres ta skinClass et pi t’y colle

5. et pi… tu souris !

Cette 1ère version permet d’exporter les Rect, les Path et des Groups ( de Rect et de Paths ! ),
avec leur SolidColor / SolidColorStroke, LinearGradient ou RadialGradient,
et même quelques filtres : Blur / DropShadow / InnerShadow.

Les positions sont recalculées avec un sélection placée à l’origine xy.

Télécharger l’extension Fireworks (CS3 + )

Et c’est déjà çà de fait !

Edit : et je rappelle qu’on peut mapper des raccourcis pour n’importe quel élément de menu… #jdcjdrAutres articles sur le même sujet

• Digimix : un Air de musique…
• Skiner un composant Flex 3 avec Fireworks CS3 [Tutoriel Vidéo]
• Flex4 : skin et primitives
• uigfx project : Flex4 primitives library / Fireworks extension

Vous vous souvenez peut-être de

Il y a quelques temps, suivant les travaux de Philippe Elsass (@elsassph) sur les algos de dessin, j’ai entrepris de nouveaux travaux sur le sujet. Dans une librairie de primitives pour Flex4 d’abord, avec UIGFX, et puis rapidement pour rendre plus… « fluides » mes skins d’application, façon Neave.

Attention : parcequ’il y a de nombreux exemples, et parceque ce billet est un voyage dans le monde merveilleux de la gelée; votre ordinateur peu subir quelques changements et râler un peu

Ceux qui me suivent sur Twitter auront peut-être vu passer quelques essais.

(Clic pour ouvrir)
Ces tests de skinning flex interactif proviennent d’une extension Fluide de la librairie UIGFX (extension que je n’ai pas encore diffusé, faute de temps…)

BIGA! Nicolas Barradeau (@nicoptere) nous lance une série d’articles impressionnante sur l’art génératif, qui ce termine par une lib d’outils géométrique : Biga. J’ai pas pu me retenir, et repris mes expérimentations.

Des points…

L’idée de l’interaction «fluide» est basé sur les algo de répulsion. Lorsque qu’un point de souris approche d’une zone d’interaction de point de vecteur, il faut calculer une «dispersion» du point.

J’utilise 2 facteurs distincts :

• La viscosité: un coefficient qui donne, comme son nom l’indique, la viscosité du point. En physique des fluides, la viscosité représente la capacité d’un liquide à s’écouler. Plus le coefficient est faible, plus l’écoulement du fluide est rapide (ex: l’eau). A l’inverse, plus le coefficient est élevé, plus le fluide à des contraintes physiques importantes qui réduisent sont écoulement (ex.: la confiture).
• le facteur de gelée: c’est mon coefficient «maison». Un indicateur qui permet de préciser le degré de déformation d’un fluide. Plus ce facteur est élevé, plus le taux de déformation, et donc le mouvement de la forme, sera important.

En AS3, on peut l’écrire comme ceci :

public function update(owner:DisplayObject):void
{
offsetx+=(xref - x) / jelly;
offsety+=(yref - y) / jelly;

var dx:Number=0;
var dy:Number=0;
if (owner.stage)
{
dx=x - owner.stage.mouseX;
dy=y - owner.stage.mouseY;
}

if (Math.sqrt((dx * dx) + (dy * dy)) <= approach * 1.1)
{
var divisor:Number=approach / 10;
var a:Number=Math.atan2(dy, dx);

offsetx+=(Math.cos(a) * approach - dx) / divisor;
offsety+=(Math.sin(a) * approach - dy) / divisor;
}

offsetx*=(1 - viscosity);
offsety*=(1 - viscosity);
if (Math.abs(offsetx) < .001)
{
offsetx=0;
}

if (Math.abs(offsety) < .001)
{
offsety=0;
}

x+=offsetx;
y+=offsety;
}

Visuellement :

…Des lignes…

2 points définissent une ligne… C’est la règle.

Projection

Pour obtenir une ligne «fluide», il faut avoir un point de vecteur intermédiaire sur la ligne.
Une méthode simple et efficace est de projeter le point de la souris sur la ligne. Les mathématiciens on depuis longtemps résolu le problème, et l’implémentation AS3 d’un algo de projection ressemble à ça :

public static function projection(p:Point, a:Point, b:Point):Point
{
var len:Number = length(a, b);
var r:Number = (((a.y - p.y) * (a.y - b.y)) - ((a.x - p.x) * (b.x - a.x))) / (len * len);

var px:Number = a.x + r * (b.x - a.x);
var py:Number = a.y + r * (b.y - a.y);

return new Point(px, py);
}

Avec les outis géométriques proposés par @nicoptere dans la lib Biga, le point de projection contraint dans la ligne, peut se calculer comme suit :

var mousePoint : Point = new Point(mouseX, mouseY);
var projection : Point = GeomUtils.project(mousePoint, point1, point2);
var constraintProjection : Point = GeomUtils.constrain( projection, point, point2);

La projection du point de souris sur notre ligne molle nous permet d’obtenir une interaction intéressante :

Si les points d’origine sont fixes, vous obtenez une espèce de corde de guitare. Rigolo.

…Et des formes

Avec encore plus de points on commence a avoir des formes, façon gateau anglais :

Un autre exemple intéressant qui reprend la simulation de Philippe Elsass :
(Clic pour ajouter un point, Ctrl/Cmd + click pour supprimer un point)

Encore plus de gelée

Comme je le disais au début de cette article, nous travaillons depuis quelques temps sur une librairie de primitives pour Flex4 : UIGFX. L’idée est de proposer une suite de primitives bien utiles, qui n’existent en standard dans le SDK Flex4 (lignes pointillées, arc, camembert, ….).

Dans cette librairie, nous avons mis en place une primitive de représentation graphique de path SVG, qui, à la différence de la primitive Path standard du SDK Flex, permet de placer les vecteurs dans le modèle de contraintes top, left, bottom, right. Cette primitive permet aussi d’importer un chemin SVG, et de le convertir au format propre à cette primitive.

En modifiant un peu le parseur SVG de UIGFX, nous pouvons facilement parcourir un path SVG et extraire les points de vecteur clefs de la forme. L’idée, vous vous en doutez est de gélifier la forme

Sources et ressources

• Vous trouverez l’ensemble des sources dans ce zip
• Biga, geometric tools library
• La série d’articles de Nicolas Barradeau
• « Parametric path drawing » de Philippe Elsass
• Et bien sur le site web de Paul Neave, … et l’ancien

Have fluid’s fun !Autres articles sur le même sujet

• Dessine moi Final Fantaisy…
• La manette Wii sur mac / pc… enfin presque
• Librairie lafabrick : parce que je le vaut bien
• et le 9ème jour il créerent le volume … 2.0

Rappel : qu’est-ce qu’un ORM ?

Un ORM fonctionne sur la base d’ajout de méta-données décrivant une correspondances entre des tables et colonnes de base de données et des objets et leurs propriétés.

Concrètement, un utilisateur pourra être modélisé par une classe

public class User

{
private int id;
private String nom;
private String prenom;
// Getters et setters
}

Les méta-données pouvant ressembler globalement à ça :

<mapping>

<class name="User" table="USER_TABLE">

<property name="id" column="USER_ID" />

<property name="nom" column="USER_LASTNAME" />

<property name="prenom" column="USER_FIRSTNAME" />

</class>

</mapping>

Attention à ne pas considérer cet exemple comme fonctionnel il permet uniquement de se faire une idée du principe.

Une fois cette configuration effectuée, vous pouvez ensuite travailler avec un gestionnaire d’entité qui prendra automatiquement en charge la persistance de votre objet au sein de la base de données que vous utilisez.

Concrètement, ce gestionnaire d’entité travaille avec un pool d’objets, souvent appelé «cache de premier niveau», qui contient des objets récupérés de la base de données. Il propose pour cela des fonctions type :

• save
• queryForObject
• queryForList
• merge
• …

pour sauvegarder / récupérer des éléments dont le mapping a été défini, ou intégrer des objets au cache de premier niveau.

L’autre fonctionnalité très prisée d’un ORM concerne la modélisation des relations entre les objets et donc les tables. Vous pouvez effectivement indiquer que votre utilisateur dispose de profils et ce profil de rôles.

Vous aboutirez à un modèle de type :

Il est alors possible de modéliser ces relations dans les méta-données et déclarer des propriétés supplémentaires dans notre classe. Par exemple, la classe User se verra ajouter

private List<Profile> profiles;

avec ses getter / setter associés.

Grâce au mécanisme de l’ORM, l’appel au getter getProfiles() d’une instance de la classe user récupérée via le gestionnaire d’entité provoquera une requête SQL de type :

SELECT p.*

FROM PROFILE_TABLE p, USER_PROFILES up

WHERE up.PROFILE_CODE = p.PROFILE_CODE AND up.USER_ID = ?

le résultat de cette requête permettant de créer la liste d’objets Profile dont je vous laisse imaginer le code.

Les frameworks ORM

Le framework Java le plus connu sur ce sujet est Hibernate, qui a notamment introduit ce concept (ou l’a du moins fait connaître), repris ensuite officiellement par la communauté Java sous le doux nom de JPA (Java Persistence Annotations). JPA permet notamment de définir les méta-données par l’intermédiaire d’annotations Java de type @Column, @Table, etc. …

.NET a vu un portage d’Hibernate appelé NHibernate, lancé dans le cadre de la «dotnetification» des frameworks Java (log4j devient log4net, JUnit devient NUnit…). Pourtant la solution de DataSet .NET offrait déjà des fonctionnalités assez proches, et particulièrement bien intégrées à l’environnement de développement, mais j’imagine que cette opération a eu le mérite de permettre aux habitués du framework à transiter vers .NET de manière plus rapide et fluide. A noter, vu qu’on parle de .NET que depuis la version 3, on a vu apparaître le framework LINQ, avec notamment LINQ to SQL qui se place en concurrent officiel de NHibernate, avec un périmètre bien plus large, notamment sur sa capacité à travailler sur les collections en mémoire à l’aide de prédicats proches du SQL. Pour le coup, et malgré un plugin Hibernate Tools proposé par JBoss sur Java, la solution Microsoft se montre particulièrement bien pensée au niveau de son intégration à l’environnement de développement (ce qu’on comprend parfaitement quand on regarde le prix de Visual Studio en face d’un eclipse gracieusement mis à disposition).

Je passe les portages divers et variés ayant pu voir le jour sur d’autres plateformes, n’ayant pas le recul nécessaire, mais je suis certains qu’il en existe.

Le constat

Après avoir pris le temps de comprendre le fonctionnement d’un ORM en l’utilisant sur des projets existants ou en tentant de le mettre en place sur des projets partant d’un développement «from scratch», je me suis heurté aux problèmes liés à la persistance et à ce fameux cache de premier niveau. En effet, travailler avec deux versions d’un même objet, l’un existant dans le cache et l’autre non (créé par exemple à l’issue d’une soumission de formulaire, peut facilement poser des problèmes de cohérence, et demandent qu’on tienne compte des particularités du concept d’ORM pour que les exceptions StaleObjectException ou LazyInitializationException soient gérées correctement (ou peut-être devrais-je dire «tant bien que mal»).

Et c’est là que le bât blesse : l’ORM, bien que simplifiant la gestion des accès à une base de données peut très facilement être une source de problèmes de performances ou de stabilité d’une application s’il n’est pas utilisé à bon escient, ou par une personne non encadrée d’un expert du domaine.

Imaginez que l’on cherche à parcourir la liste des rôles d’un utilisateur récupéré au moyen d’un ORM dans notre exemple de tout à l’heure :

Iterator<Profile> profilesIter = user.getProfiles().iterator();

while (profilesIter.hasNext())

{

Profile currentProfile = profilesIter.next();

Iterator<Roles> rolesIter = currentProfile.getRoles().iterator();

while (rolesIter.hasNext())

{

Role currentRole = rolesIter.next();

// Faire quelque chose

}

}

En pratique, il est tout à fait probable que ce code, presque indolore sur des collections d’objets présents en mémoire, se traduise avec un ORM par une série de requêtes SQL. En considérant que ce code serve à contrôler qu’un utilisateur dispose d’un rôle donné au sein d’une application – étant donc appelé très souvent pour chaque utilisateur de l’application – on peut tout à fait imaginer les problèmes de performances posés.

« C’est un problème de paramétrage »

Effectivement, ces problèmes sont souvent liés à la méconnaissance du framework et à des problèmes de paramétrage. Je ne suis moi-même pas expert Hibernate mais le connais assez pour savoir qu’un bon paramétrage peut faire toute la différence et que le code d’une application doit également se conformer au paradigme d’ORM.

J’ai aussi tendance à considérer ce type de travail comme un luxe. En effet, à niveau équivalent, un développeur sera capable de produire une requête SQL relativement efficace alors qu’il restera incapable de proposer un paramétrage Hibernate adéquat.

En conclusion, bien manipulé, l’ORM peut être très intéressant et apporter en lisibilité de code. A l’inverse, mal utilisé, il pose plus de problèmes qu’il n’est sensé en résoudre (performances, «hacks» divers et variés…).

Les alternatives

Et si je ne veux pas d’ORM sur mon projet ? C’est une question à se poser : les problèmes posés par un ORM, selon l’organisation et l’expérience de l’équipe de développement, peuvent être un frein à la réussite d’un projet.

Vous pouvez globalement recourir à :

• Un «mappeur de requêtes SQL» permettant d’exécuter des requêtes rédigées par vos soins, et automatiquement «mappées» sur des objets selon la configuration mise en place. Un framework Java assez connu dans ce domaine est iBatis (repris récemment sous le nom MyBatis) qui donne des résultats tout à fait satisfaisants, notamment par rapport à sa facilité de mise en oeuvre et sa proximité de fonctionnement avec des appels standards JDBC.
• Des appels JDBC natifs «bruts» qui manquent de classes facilitant les appels et traitements des résultats. En le complétant du framework Spring et son JdbcTemplate, vous obtenez une solution très simple à mettre en place et aisément compréhensible par une équipe de développement peu expérimentée.

Que choisir ?

Aujourd’hui, selon le contexte de la société dans laquelle un projet donné est réalisé, deux grandes catégories d’équipe se distinguent :

1. Une équipe composée de profils similaires, évoluant ensemble sur les développements applicatifs de la société pour laquelle ils travaillent.
2. Une équipe encadrée par un senior et composée de profils juniors.

Dans le premier cas de figure, la capitalisation sur la technologie sera généralement pérenne, l’équipe restant stable et organisée autour d’un socle applicatif donné. Dans ce cadre, les problèmes liés à l’utilisation d’un ORM ne se posent finalement qu’au démarrage et sont gommés par la suite.

Dans la seconde configuration, le cadrage est fait par l’architecte de manière globale, mais souvent difficilement appliqué à tous les aspects du développement. Concrètement, l’expert interviendra à la demande d’un junior coincé sur un problème, et règlera le problème avec lui en tentant de lui apporter les connaissances manquantes. Dans ce schéma, à force, les juniors intégreront les concepts et deviendront seniors à leur tour, encadrant d’autres juniors et l’histoire se répètera.

Conclusions

Vous aurez compris que je ne suis personnellement pas friand d’ORM, lui préférant des solutions plus simples, ayant trop souvent eu à gérer des problèmes liés à l’incompréhension du framework, des tentatives de paramétrage a posteriori pour contrer les problèmes de performances… Mais tout dépend de votre configuration d’équipe, cela reste un choix très intéressant dès lorsque qu’il est partagé et que chaque membre de l’équipe maîtrise les tenants et aboutissants de cette technologie.

Et vous, vous êtes ORM ?Autres articles sur le même sujet

• Vous avez dis Flex3 Beta2 ?
• Quicksilver, non-action et Tao appliqués à MacOS X [@Google Talks]
• MAX 2009 – JPA, BlazeDS et LiveCycle DS
• AIR 2 : appeler un JAR exécutable via un NativeProcess

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 !

dashes contient un tableau (Array) de nombres. Les emplacements impaires du tableau définissent la taille (en pixel) des tirets. Les emplacements pair définissent la taille des espacement.

Dans le code :

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/mx"
    minWidth="200" minHeight="200"
    xmlns:uigfx="http://uigfx.lafabrick.com">

    <uigfx:DashedLine
        dashes="[80, 10, 10, 20, 40, 30]"
        left="100" verticalCenter="0" right="100">

        <uigfx:stroke>
            <s:SolidColorStroke color="#FFFFFF" weight="4" caps="round" />
        </uigfx:stroke>

        <uigfx:filters>
            <s:GlowFilter blurX="4" blurY="4" alpha=".8" color="#333333" />
        </uigfx:filters>

    </uigfx:DashedLine>

    <uigfx:DashedLine
        dashes="[80, 10, 10, 20, 40, 30]"
        left="101" verticalCenter="0" right="100">

        <uigfx:stroke>
            <s:LinearGradientStroke weight="2" pixelHinting="true" caps="square">
                <s:GradientEntry color="#009EE0" />
                <s:GradientEntry color="#FF9900" />
                <s:GradientEntry color="#009EE0" />
            </s:LinearGradientStroke>
        </uigfx:stroke>

    </uigfx:DashedLine>

</s:Application>

Résultat :

Disponible bien entendu sur le google code UIGFX.
Autres articles sur le même sujet

• uigfx project : Flex4 primitives library / Fireworks extension
• Flex 4 et les layouts – Faire une ViewStack « pure » Spark
• UIGFX practice : a CircularSlider component
• Proches de l’Ohio??? Les états esthètes de Flex4

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