Suite à vos demandes, le thème de ce Cours ActionScript 3 porte sur l’utilisation et la personnalisation des Composants du Framework AS3 Facile.

Pour apprendre à créer des Composants visuels et votre propre Framework AS3, consultez l’ensemble des cours ActionScript 3 sur le Framework AS3 Facile.

Voici ce que vous allez apprendre dans ce Cours ActionScript :

• Créer le fichier fla contenant les graphismes des composants AS3 Facile.
• Comment personnaliser tous les composants AS3 Facile et les rendre conformes à vos applications flash.
• Créer un fichier swc contenant les graphismes et l’utiliser dans votre application flash.
• Un exemple d’utilisation et de personnalisation de chaque composants AS3 Facile.

Cette formation ActionScript 3 vous permettra d’utiliser, de modifier, d’ajouter et d’implémenter les Composants AS3 Facile dans vos applications flash.

Les Composants AS3 Facile

Version démonstration

Et voici notre application implémentant l’ensemble des composants du Framework AS3 Facile.

Télécharger le code source du cours AS3

Et voici le code source de l’exemple d’utilisation des composants du Framework AS3 Facile.

Télécharger la dernière version du Framework AS3 Facile.

Montrez moi vos applications flash qui utilisent les Composants AS3 Facile ?

Partagez votre personnalisations des graphismes des Composants AS3 Facile dans les commentaires ci-dessous.

Quelles sont les nouvelles fonctionnalités que vous avez ajoutés ? Quelles fonctionnalités souhaitez-vous dans le Framework AS3 Facile ?

Après avoir vu ensemble les différentes raisons (Chapitre 1 : Pourquoi créer des Composants Graphiques en AS3 ?), nous allons aborder le thème de leur conception.

La façon de concevoir des composants se doit d’être souple. Il est donc nécessaire d’adapter son processus de développement en fonction du type de projet sur lequel nous travaillons.

La méthode qui vous est décrite est basée sur l’expérience, un vécu de programmeur. Après la lecture de ce tutoriel, vous possèderez toutes les clés pour améliorer vos Composants AS3 selon vos besoins spécifiques. C’est un petit peu cela la magie du développement!

Si il n’y a qu’une seule et unique règle d’or à retenir c’est : « Soyez rigoureux, codez avec souplesse ! ».

I – Le Cahier Des Charges Fonctionnel

Ah le cahier des charges fonctionnel, aussi appelé CDCF, un vaste programme ô combien primordial ! Sachez que c’est l’une des étapes les plus importantes si ce n’est la plus importante de tout projet informatique.

Un CDCF correctement décrit et validé c’est des dizaines d’heures de code économisées.

Dans un monde idéal, tout projet informatique devrait démarrer avec un Cahier Des Charges Fonctionnel.

Concrètement, c’est quoi un CDCF ?

Un cahier des charges fonctionnel est un document qui décrit de la manière la plus exhaustive possible la liste des actions et fonctionnalités dont votre programme devra être dôté en fin de production.

Comprenez par là que toute personne, et surtout non versée dans le développement, sera à même de vous décrire le fonctionnement détaillé de votre future application sous réserve d’avoir lu ce fameux CDCF.

Pour vous donner un exemple plus concret, cela ressemble à un story-board au cinéma. Un story-board va vous décrire l’enchaînement des actions, de la scène, le placement, l’attitude des acteurs. Et bien un CDCF est un story-board informatique.

Imaginons un instant la scène suivante :

• Eh Tom !
• Oui chef ?
• Laisses tomber ce que tu fais et viens voir un peu là, on a nouveau projet à démarrer !
• Ah ? Très bien de quel genre de projet s’agit-il ?
• Il s’agit d’un site e-commerce.
• Mmmh ok, je t’écoute.

• Le client veut quelque chose de classe et sobre, une vitrine en somme, seulement les clients devront pouvoir acheter ses produits par le biais d’une boutique en ligne.Ah et j’oubliais de préciser il ne veut pas que son site soit développé en PHP et n’aime pas Flash ! Alors tu te sens d’attaque ?

• Mmmh j’aurais besoin d’un peu plus de précision, pourquoi ne veux-t-il pas de PHP sur son site ? Quelle plateforme de paiement désire-t-il utiliser ? Ce que je veux dire c’est qu’il me faudrait un peu plus de renseignements que ça.

• Oui enfin bon, le truc c’est qu’il est assez pressé vois-tu, il a besoin d’une démo pour se décider, je compte sur toi pour faire au mieux et pour les précisions je te les donnerai au fur et à mesure, là tu as l’essentiel. Tu penses que la démo peut être prête pour demain midi afin que je lui soumette ?

• Je vais faire de mon mieux, seulement je ne peux pas te garantir que cela va lui plaire.
• N’oublies pas que je compte sur toi, t’es le meilleur !

Alors ? Un air de déjà vu ? Si non, ça ne saurait tarder ! En effet, il s’agit là d’un dialogue classique entre un développeur et un commercial / chef de projet.

Pauvre Tom… Il va être bien embêté pour réaliser sa démo. Eh oui, à aucun moment son chef ne lui a donné de direction précise vers laquelle s’orienter, comptant sur le seul talent de son employé.

Seulement voilà, Tom est développeur, pas magicien! Il ne peut deviner ce à quoi pense le client, il a donc 90% de chance de se planter!

Sa seule consolation, c’est qu’il y a peu de chance que ses concurrents possèdent plus d’informations.

Maintenant vous avez saisi l’importance de la rédaction d’un bon CDCF. Un Cahier Des Charges Fonctionnel contient la liste des fonctionnalités et des actions de votre programme.

Ensuite, nous passons à la rédaction du Cahier Des Charges Technique que nous abrègerons par CDCT.

II – Le Cahier Des Charges Technique

Le CDCT est un chantier aussi vaste que le CDCF, toutefois sa conception est nettement plus simple. En général il est réalisé par des programmeurs pour des programmeurs! C’est un avantage certain, en effet, tous les protagonistes « parlent » le même langage.

Le CDCT est un élément intermédiaire, à cheval entre le CDCF et la production. Il permet aux développeurs d’avoir une référence sur laquelle s’appuyer pour implémenter telle ou telle fonctionnalité.

Le Cahier Des Charges Technique existe pour décrire l’ensemble des librairies, frameworks, méthodes de développement qui seront employées en production. Il apporte également quelques précisions qui ne rentrent pas dans le cadre du Cahier Des Charges Fonctionnel ( par exemple le fait que le site devra être développé en Java et non en PHP ).

De plus le CDCT a également une autre utilité. Il permet de préparer le terrain pour l’élaboration du schéma architectural de l’application que nous verrons un peu plus loin.

Dans le cadre du développement d’un composant graphique, le Cahier Des Charges Technique servira à décrire la manière de développer les fonctionnalités que nous estimons génériques ou non.

Prenons un exemple tout simple et retrouvons notre ami Tom :

• Eh Tom ! Laisses-donc ce site e-commerce, de toute façon la démo n’a pas plus au client ! Viens voir un peu.
• Oui ?
• J’aimerais que tu développes une bibliothèque de composants graphiques génériques dont on pourra se resservir à loisir ! Le client est très exigeant et nous a fourni la liste des fonctionnalités qu’il souhaite trouver sur les différents éléments de cette bibliothèque.

• Très bien, dois-je coder de manière à pouvoir l’étendre facilement plus tard ? Pour les skins, est-ce que je fais un module à part ou directement dépendant de la bibliothèque ? Ai-je le droit d’utiliser des librairies externes comme des librairies de Tween ?

• Euuhhhh …. Fais comme tu le sens ! Au mieux !

• Disons qu’il est un peu difficile de dire ce qui est le mieux, tout dépend de ce que l’on souhaite en faire et de comment la bibliothèque est censée évoluer.
• Je te fais confiance, tu es le meilleur ! Et n’oublies pas que je compte sur toi !

Ahlala, décidément ce Tom a l’art de s’attirer des ennuis, ou peut être que sont-ce les aléas courants du métier, allez savoir…

Toujours est-il qu’il va être obligé de passer pas mal de temps à réfléchir à ce qui sera le mieux pour le futur de cette bibliothèque de composants. Et qui plus est, sans connaître les exigences particulières des équipes techniques du client.

Il est donc fort probable qu’à terme, il perde une bonne partie de son temps à redévelopper des fonctionnalités mais cette fois-ci, d’une manière qui convienne au client.

D’où l’importance de la rédaction d’un Cahier Des Charges Technique qui permet au développeur de développer plutôt telle ou telle fonctionnalité et d’en laisser une autre de côté (car inutile pour le client).

Maintenant, nous allons découvrir la création du schéma architectural de l’application.

III – Le schéma architectural de l’application

Le schéma architectural d’une application est, disons, INDISPENSABLE.

En effet, lorsque nous abordons pour la première fois une nouvelle librairie, nous disposons en général d’une documentation. Cependant, celle-ci nous renseigne rarement sur la façon dont les différents éléments interagissent entre eux.

Il s’agit donc d’une représentation imagée de l’emboîtement des différentes briques fonctionnelles du projet. Ainsi, nous connaissons, par exemple, que telle ou telle classe à des dépendances avec telle ou telle autre. Et nous pouvons déterminer assez aisément que cette classe à droite hérite de celle qui se trouve juste au dessus.

Le but de cet article n’étant pas de faire un cours magistral sur les méthodes de conception de ces schémas, en voici une : UML.

Et je vous invite grandement à approfondir vos connaissances sur le sujet. La documentation sur internet est nombreuse et qualitative pour que je me permette de vous laisser choisir vos propres sources.

Voici à titre d’exemple, ce à quoi peut ressembler un schéma UML, il s’agit d’un exemple pris sur internet au hasard des couloirs…

Comme vous pouvez le constater, l’application semble complexe. Toutefois grâce à notre schéma, nous pouvons aisément dissocier certains éléments. Nous pouvons même comprendre, grâce au sens des flèches, comment s’effectue la communication entre les différents éléments.

IV – Conclusion

Dans ce chapitre, nous avons vu que pour entamer un développement de la manière la plus sereine possible, il nous fallait au préalable préparer le terrain avec la rédaction :

1. du Cahier Des Charges Fonctionnel (CDCF).
2. du Cahier Des Charges Technique (CDCT).
3. du Schéma Architectural.

Et cela, en étant le plus rigoureux possible afin de gagner du temps plus tard sur le développement.

Certes, au début tout cela peut vous paraître superflu voire franchement casse-pieds. Ces différentes méthodes ont fait leurs preuves maintes et maintes fois. Et elles continuent chaque jour, pour chaque application, de les faire.

Dans le prochain chapitre nous aborderons enfin la pratique avec le développement des fonctionnalités de base de notre bibliothèque de Composants AS3.

Et vous, comment effectuez-vous l’analyse de vos projets ActionScript ?

Avant le développement pur et dur, utilisez-vous des outils / logiciels spécifiques ?

Partagez votre expérience dans les commentaires ci-dessous.

Mais pourquoi donc prendre le temps de créer des Composants AS3 Graphiques ?

Après tout, ce qui est graphique est censé revenir de droit aux graphistes non ? Alors pourquoi un développeur irait s’ennuyer avec cela ?

Il existe une multitude de bonnes raisons de développer des Composants Graphiques génériques et réutilisables.

I – Réutilisation du code source

Commençons par la définition d’un Composant Graphique en ActionScript.

Un composant graphique est un morceau de code source qui va nous permettre d’offrir à l’utilisateur une information ou une interaction sous forme graphique. Cela peut aller de l’infobulle à la barre de défilement ( scrollbar ). Ce code source se veut réutilisable et en général skinnable, c’est à dire que l’on peut personnaliser son apparence et donc changer le côté graphique autant de fois qu’on le désire.

Maintenant que nous avons fixé les limites d’un composant graphique, nous allons nous intéresser à son utilité.

Pour cela nous allons nous figurer une scène classique de début de projet :

Tom est développeur, il doit mettre en place un formulaire permettant à ses utilisateurs de créer leur CV en ligne. Son chef de projet vient le voir et lui demande de commencer le développement de l’application tout de suite. Le problème c’est qu’aucune charte graphique n’a été fournie etque le code qui permet d’enregistrer les CV en base de données est déjà prêt. Il se demande donc à juste titre ce qu’il va pouvoir faire car il a pris l’habitude de reprendre les chartes des graphistes et développer ses fonctionnalités en mélangeant le fond et la forme.

Voilà un problème que rencontre tout programmeur débutant, en effet, il n’est pas naturel de dissocier les éléments graphiques du code. Cela demande une certaine pratique de raisonnement dans l’abstrait, or raisonner dans l’abstrait c’est comme tout, ça se travaille.

Voyons comment Tom peut se sortir de ce pétrin et avancer le développement sans charte graphique et ce, de manière intelligente.

Il a obtenu une liste des fonctionnalités de ce formulaire, il prend donc une feuille et un crayon et remarque qu’il va devoir coder au moins 3 ou 4 boutons, d’aspects différents certes, mais les fonctionnalités resteront les mêmes.

Il se rend compte également que toutes les informations doivent tenir sur une page mais que si l’on est un peu pointilleux, les champs de texte libre peuvent prendre énormément de place. Il va donc falloir masquer le contenu qui sort des limites et le faire défiler à l’aide d’une barre.

Tom va donc coder les fonctionnalités, comme le défilement et les différents états d’un bouton, toutefois son code ne devra dépendre d’aucun graphisme tout en laissant une possibilité de personnaliser l’apparence du composant. Ainsi, quelque soit la charte graphique qu’on lui fournira, il aura juste à l’intégrer sur chaque bouton et sur chaque scrollbar.

Voici donc le premier intérêt des composants graphiques, la possibilité de les réutiliser. Ils permettent de gagner du temps car une fois créés, il n’y a plus matière à revenir dessus. Cela demande du temps et de l’expérience pour créer des composants efficaces réutilisables partout.

En général, les composants sont efficaces lorsque vous arrivez à les utiliser sur 3 ou 4 projets différents sans aucune retouche à réaliser.

Nous allons maintenant aborder brièvement la deuxième bonne raison de créer des composants graphiques qui découle inévitablement de la première, la facilité de développement d’interfaces utilisateurs.

II – Le développement d’interfaces avec des Composants

Les interfaces utilisateur sont parmi les choses les plus pénibles à réaliser pour un développeur.

Et cela pour plusieurs raisons, les voici :

• En général il nous est souvent demandé de changer telle ou telle chose à la dernière minute et ce, de façon répétée.
• Le rendu fonctionnel, de manière générale, n’est pas aussi bon que ce à quoi l’on s’attendait ce qui entraîne des ajustements de bouts de chandelles. Nous avons tous vécu la scène du graphiste qui vient se poser à côté de vous « pour 5mn » et qui repart une heure après, tout content d’avoir bataillé sur chaque pixel. Notez cependant que cela ne l’empêchera pas de reprendre entièrement le concept visuel et ce, dès le lendemain.

• Il y a clairement un manque de défi technique dans les interfaces utilisateur, en général quand on en a fait deux ou trois on les a toutes faites et les suivantes nous paraissent insipides. Raison de plus pour y passer le moins de temps possible et occuper son esprit avec des choses plus motivantes.

Nous avons déjà vu qu’une fois correctement développés, les composants graphiques peuvent être réutilisés à l’infini et personnalisés à souhait. Ce qui résulte en un gain de temps considérable dans le développement d’une application.

Pour reprendre l’exemple de Tom, admettons qu’il ait déjà crée ses composants “scrollbar” et “boutons” lors d’un projet précédent, il pourra raisonnablement répondre à son responsable : « écoutes, j’ai déjà une liste de composants graphiques prêt à l’emploi, je vais plutôt passer du temps sur autre chose ».

Et voilà, Tom a gagné du temps, son responsable est content et lui aussi.

III – Conclusion

En conclusion, nous pouvons affirmer qu’il y a énormément d’avantages à créer des Composants Graphiques en ActionScript. Et ce, quel que soit le type de projet pour lequel nous sommes amenés à travailler.

Nous avons vu que les composants représentent une manière élégante et astucieuse de développer des interfaces utilisateur.

De par leur nature réutilisable, ils permettent de gagner un temps de développement considérable.

Dans les prochains tutoriels, nous verrons ensemble :

• Comment créer des Composants en AS3.
• Comment penser leur organisation, fonctionnalités.
• Et Comment les utiliser très simplement dans nos Applications Flash.
  

Et vous, utilisez vous des Composants AS3 réutilisables pour concevoir vos applications Flash ?

Avez-vous développé votre propre Framework de Composants AS3 ?

Si non, quel Framework de Composants Graphiques utilisez-vous ?