EKAMELEON - DevBlog ActionScript & ECMAScript

Voici la 4ème de notre second chapitre consacré aux différentes stratégies utilisées par la fabrique pour créer un objet avec une définition d'objet.

Pour ceux qui découvrent dans cet article le monde merveilleux du design pattern d'Inversion de contrôle avec VEGAS et qui n'ont pas eu encore le temps de consulter les articles précédents, voici une liste rapide des derniers articles sur ce blog que je vous conseille vivement de lire les articles suivant avant de passer à la suite :

• A - Design Pattern d'inversion de contrôle - Généralités
• B - Les définitions d'objets (Partie- 1/5)
• B - Les définitions d'objets (Partie - 2/5)
• B - Les définitions d'objets (Partie - 3/5)

Comme toujours je vous rappelle rapidement les liens importants pour installer VEGAS et poser des questions à propos des concepts définis dans mes articles :

Pour ceux qui débarquent dans l'aventure, et qui ne savent pas encore ce que représente VEGAS, comment l'installer etc.. Je vous propose d'aller faire un tour rapide sur le Google Code du projet :

• http://code.google.com/p/vegas/
• http://code.google.com/p/vegas/wiki/InstallVEGASwithSVN

Pour toutes vos questions sur VEGAS et ses extensions n'hésitez pas à vous inscrire sur le Google Groups du projet :

• VEGASoS : http://groups.google.com/group/vegasos

Remarque : En définissant convenablement votre abonnement sur le Google Groups vous pourrez recevoir régulièrement des mails à chaque fois qu'un membre intervient sur celui-ci, très pratique pour suivre les conversations sous forme de mailing-list.

Enfin pour suivre le projet au mieux je peux vous proposer de consulter la page officielle de VEGAS sur Ohloh qui sert un peu de point central pour tous les projets opensource sur lesquels je travaille actuellement :

• http://www.ohloh.net/projects/vegas
• http://www.ohloh.net/accounts/ekameleon

Vous pouvez à présent lire ce nouvel article tranquillement

Ce nouveau article va se concentrer tout particulièrement sur les attributs principaux d'une définition d'objet dans un conteneur IoC basé sur le moteur implémenté dans VEGAS.

Pour ceux qui découvrent dans cet article le monde merveilleux du design pattern d'Inversion de contrôle avec VEGAS et qui n'ont pas eu encore le temps de consulter les articles précédents, voici une liste rapide des derniers articles sur ce blog que je vous conseille vivement de lire avant de passer à la suite :

• A - Design Pattern d'inversion de contrôle - Généralités
• B - Les définitions d'objets (Introduction - 1/5)

Comme toujours je vous rappele rapidement les liens importants pour installer VEGAS et poser des questions à propos des concepts définis dans mes articles :

Pour ceux qui débarquent dans l'aventure, et qui ne savent pas encore ce que représente VEGAS, comment l'installer etc.. Je vous propose d'aller faire un tour rapide sur le Google Code du projet :

• http://code.google.com/p/vegas/
• http://code.google.com/p/vegas/wiki/InstallVEGASwithSVN

Pour toutes vos questions sur VEGAS et ses extensions n'hésitez pas à vous inscrire sur le Google Groups du projet :

• VEGASoS : http://groups.google.com/group/vegasos

Remarque : En définissant convenablement votre abonnement sur le Google Groups vous pourrez recevoir régulièrement des mails à chaque fois qu'un membre intervient sur celui-ci, très pratique pour suivre les conversations sous forme de mailing-list.

Enfin pour suivre le projet au mieux je peux vous proposer de consulter la page officielle de VEGAS sur Ohloh qui sert un peu de point central pour tous les projets opensource sur lesquels je travaille actuellement :

• http://www.ohloh.net/projects/vegas
• http://www.ohloh.net/accounts/ekameleon

Vous pouvez maintenant reprendre votre lecture !

IoC ? Injection de dépendance ? Conteneur Léger ... depuis quelques temps maintenant nous entendons parler de ce Design Pattern très puissant qui révolutionne la construction des applications orientées objets. Ce Design Pattern est vraiment pour moi indispensable une fois bien maitrisé et permet d'aller loin, très loin !

Depuis plusieurs mois maintenant je me suis lancé dans la construction de ma propre implémentation de ce pattern en m'inspirant d'une part de ce qu'il se fait de mieux à l'heure actuelle dans ce domaine ( Spring, Parsley, etc..) mais surtout des problèmes et besoins que je peux rencontrer chaque jour dans mes productions. Je remercie d'ailleurs tous ceux qui ont pris le temps de me supporter et de prendre le temps de poser un oeil sur mon code et au final qui m'ont aidé à aller au bout d'une version 1 finale (ou presque.. je finiolle :D ) de VEGAS et ses extensions.

La version AS3 de VEGAS est composée de plusieurs extensions très solides et spécialisées. Mais AndromedAS avec ses outils d'IoC, etc. est devenu le noyau dure du framework pour créer avec facilité une RIA moderne et fonctionnelle aussi bien dans Flash, Flex, ou dans une application AIR.

Je commence donc ici par un premier chapitre de mon énorme article basé sur le Design Pattern IoC dans VEGAS qui va se découper en plusieurs parties ici sur ce blog et qui finira au bout du compte en livre opensource disponible très prochainement sur les pages officielles du projet et aussi sur Google Documents. J'ai encore pas mal de fonctionnalités à documenter car la bibliothèque IoC s'est énormément étoffée ces derniers mois (pour la bonne cause).

J'espère que cette introduction, vous permettra de vous faire une idée clair et précise des bases du pattern IoC mais surtout de l'orientation que j'ai pu prendre pour l'implémenter. Cet article reste ouvert à tous commentaires et s'accompagnera très bientôt d'une seconde partie qui précisera le DOM très complet des définitions d'objets utilisée par le conteneur léger IoC pour créer des objets dans une application.

Comme toujours, je suis toute personne pouvant m'aider à accélérer le processus de traduction de cet article en anglais.

Pour tout ceux qui sont pressés de savoir la suite, vous pouvez me contacter pour que je vous donne en attendant de la communiquer ouvertement sur ce blog, l'url des autres parties (en construction) de ce tutoriel assez imposant (80 pages pour le moment sur Google Documents)

A noter que vous trouverez les sources des exemples ci-dessous dans le repository SVN du projet :

• http://vegas.googlecode.com/svn/AS3/trunk/bin/test/andromeda/ioc/
• http://vegas.googlecode.com/svn/AS3/trunk/bin/test/asgard/net/ (3 exemples d'utilisation de la classe ECMAObjectLoader)

Pour ceux qui débarquent dans l'aventure, et qui ne savent pas encore ce que représente VEGAS, comment l'installer etc.. Je vous propose d'aller faire un tour rapide sur le Google Code du projet :

• http://code.google.com/p/vegas/
• http://code.google.com/p/vegas/wiki/InstallVEGASwithSVN

Pour toutes vos questions sur VEGAS et ses extensions n'hésitez pas à vous inscrire sur le Google Groups :

• VEGASoS : http://groups.google.com/group/vegasos

Enfin pour suivre le projet au mieux je peux vous proposer de consulter la page officielle de VEGAS sur Ohloh :

• http://www.ohloh.net/projects/vegas

Il est temps maintenant de démarrer cet article sur le Design Pattern d'IoC et je vous promets la suite de cet article d'ici peu de temps

J'ai beaucoup de travail en ce moment pour finaliser les outils permettant d'utiliser le design pattern d'Inversion de Contrôle avec VEGAS (mon framework opensource) et je suis en train d'écrire un gros article (50aines de pages !) sur le sujet qui arrivera d'ici peu sur ce blog et via une publication opensource basée sur des documents au format Google Documents

En attendant, voici un petit article très simple pour vous parler d'un mini "problème" découvert par des amis à moi il y a quelques semaines. Je devrais parler d'un "changement de comportement" plutôt que d'un problème...

Voyons donc de plus prêt le comportement de la méthode MovieClip.play() en ActionScript 3.

Nature du problème

Pour tester et isoler le problème de la méthode MovieClip.play() en AS3, il suffit de suivre la méthodologie suivante :

1 - Ouvrir Flash CS3 et créer un nouveau document.

2 - Créer un MovieClip dans la bibliothèque du document ouvert et à l'intérieur créer une petite interpolation de forme ou de mouvement pour que le clip contienne une petite animation sur plusieurs images clés.

3 - Créer un calque de code dans le scénario (timeline) du clip et mettre un stop(); sur la première image clé du clip.

4 - Poser une occurrence du symbole sur la scène et lui donner un nom d'occurrence "mc" dans le panneau de propriété en ayant bien pris le temps de sélectionner le clip avant.

5 - Créer sur la scène principale un calque de code au dessus du calque qui contient l'occurrence et taper le code suivant :

mc.play() ;

Si nous essayons de compiler le swf (CTRL + ENTER) avec une publication au format AS1 ou AS2 (voir paramètre dans panneau des paramètres de publication du document), pas de problème l'animation du clip se lance sans problème.

Si par contre nous essayons de compiler avec un format AS3 avec une publication pour le FlashPlayer 9 alors le clip ne lance pas l'animation est reste figé sur sa première image clé.

Il est très important de pouvoir "localiser" (ou régionaliser) nos applications. Localiser une application permet de rendre dynamique son contenu (texte, sonore ou autres) en créant une interface utilisateur qui peut changer en fonction d'une langue en particulier. La localisation d'une application permet d'améliorer l'accessibilité pour différents utilisateurs et il est certain qu'avec toutes les difficultés que l'on peut avoir pour communiquer de façon général, il est tout de même sympathique de pouvoir le faire avec le plus grand nombre dans le monde entier.

Une bon moteur de localisation permet de changer à tout moment les traductions et éléments graphiques de l'application en fonction de données traduites dans plusieurs langues. Il est certain que le plus souvent la localisation d'un site passe par une page d'accueil simple qui permet de diriger l'utilisateur vers une version spécifique de l'application avec un contenu régionalisé. Pour ma part dans VEGAS j'ai préféré créer un moteur qui possède les caractéristiques suivantes :

• Externalisation des traductions et documents.
• Utilisation de fichiers ou données externes encodées en UTF8.
• Moteur dynamique au "runtime". La localisation doit être totalement dynamique et doit intervenir après la compilation (plus léger et plus simple à maintenir)
• API simplifiée permettant de centraliser les mises à jours de l'interface utilisateur via un mapping utilisant plusieurs stratégies selon les besoins.
• Par défaut, utilisation du format de donnée eden (http://code.google.com/p/edenrr/) ou JSON (http://www.json.org) même si il est vrai que j'utilise très peu cette dernière notation. Malgré tout il est assez simple de créer un module de parsing basé sur une autre notation comme par exemple du XML.

Dans Flash et surtout dans le framework de base ActionScript nous trouvons la propriété flash.system.Capabilites.language qui permet à tout moment de renvoyer le code langue du système dans lequel l'application swf vient d'être lancée. L'ActionScript se base sur des noms des "codes langue" au format ISO 639-1, par exemple la propriété language aura pour valeur "fr" si le système par défaut est un système français.

Implémentation du moteur de localisation de VEGAS

Dans VEGAS le moteur de localisation se trouve dans le package andromeda.i18n en AS3 et reste pour le moment dans le package asgard.system en AS2.

Mise à jour (2008-08-02) : En AS3 le package asgard.system devient andromeda.i18n

1 - La classe andromeda.i18n.Lang

La première classe que nous allons étudier dans ce package est la classe andromeda.i18n.Lang qui permet d'énumérer les "codes langue" par défaut définis par la norme ISO 639-1 dans le FlashPlayer. Cette classe donne un outil simple pour valider dans vos applications les langues disponibles. Il est ainsi possible d'ajouter d'autres langues en cas de besoin dans la liste des langues par défaut du FlashPlayer mais bien entendu elle ne seront pas prises en compte automatiquement par la propriété System.capabilities.language(AS2) ou flash.system.Capabilities.language(AS3) du Flash Player.

Voici un exemple d'utilisation de cette classe :

Il n'y a pas de secret. Le code ne passe pas seulement par des interminables lignes de code mais surtout par d'interminables lignes de documentation (en général plus nombreuses). Un framework, une classe, un bout de code non documenté et c'est très rapidement l'anarchie.

Pour générer nos documentations en AS3 ou MXML, Adobe nous propose ASDoc une application en ligne de commande assez complexe mais qui a le mérite de générer une documentation HTML bien complète.

Je ne vais pas entrer dans mon article sur une explication super détaillée de toutes les options proposées par ASDoc ou encore sur la "meilleure manière" de générer sa documentation via une tache ANT ... Je préfère vous parler d'une fonctionnalité à mes yeux importante et pourtant non prévue dans ASDoc : la colorisation syntaxique du code contenu dans la documentation.

En effet, même si ASDoc propose via les balises code et listing une "solution" pour afficher une partie du texte contenu dans vos documentations avec un formatage "spécifique".. on peut pas dire que le résultat soit très explicite !

A côté de cela Google a sorti il y a un petit moment maintenant un petit module opensource écrit en JAVAScript qui permet de coloriser un code HTML efficacement via le script Google Code Prettify. L'intérêt de ce module réside dans le fait qu'il ne nécessite pas, comme GESHI (PHP) par exemple, d'un script serveur pour coloriser le code d'un texte HTML.

Google Code Prettify permet de coloriser un bon nombre de langages et fonctionne vraiment bien avec les langages basés sur une écriture C, Java, Python, Bash, SQL, HTML, XML, CSS et Javascript.

Pour faire simple Google Code Prettify permets de modifier dynamiquement dans une page HTML les balises pre et code possédant un attribut "class" avec la valeur "prettyprint" comme ceci :

<html>
 
    <header>
 
        <link href="prettify.css" type="text/css" rel="stylesheet" />
        <script type="text/javascript" src="prettify.js"></script>
 
    </header>
 
    <body onload="prettyPrint()">
 
    <p>
 
    <pre class=prettyprint>
    var s = "hello world" ;
 
    var sum = function( n1 , n2 )
    {
        return n1 + n2 ;
    }
 
    trace( 2 + 3 ) ;
    </pre>
 
    </p>
 
    <p>The previous script return <code class="prettyprint">5</p></p>
 
    </body>
 
</html>

Au final, nous avons d'un côté ASDoc un applicatif en ligne de commande qui permet de documenter nos classes via la notation JAVADOC et un texte au format HTML distribué officiellement par Adobe et de l'autre côté Google Code Prettify qui permet de formater un texte HTML si il contient des scripts. L'idée est de pouvoir utiliser les 2 pour créer nos documentations AS3

Généralités

Voici mon premier feedback technique sur Flash Media Interactive Server 3.... Sérieux... pourquoi Adobe donne un nom aussi compliqué à son serveur ? A chaque fois que je suis obligé de parler de FMS3 j'ai l'impression de discuter de la dernière version de Street Fighter 2 Turbo X fatal mega super tropdur alpha combo lol Donc je décide de faire simple et d'utiliser le terme FMS3 dans la suite de mes articles... (fin de cette petite note sur la nomenclature de mes articles traitant de FMS3 :D)

Comme je l'ai déjà dit, les enjeux majeurs de cette nouvelle version de FMS reste une amélioration des performances, une amélioration de la qualité des vidéos en live streaming (full HD avec H264) et pour finir une baisse des prix des licences et une simplification de celles ci en proposant seulement 2 types de serveurs (oui quand je parle de simplification, je ne parle pas du nom des serveurs... cf début de ce message ;))

Reste que pour ma part, même si après l'annonce officielle de la sortie de FMS3 je n'avais que très peu d'espoirs dans les nouveautés au niveau du code côté serveur (pas d'AS3 ou d'ES4 côté serveur), j'espérais que Adobe mettrait un peu plus d'efforts dans l'évolution de la nouvelle version de FMS en faisant une petite mise à jour du moteur Javascript SSAS de FMS. J'avais de gros espoirs là dessus en prenant en compte l'arrivée de l'E4X en AS3 et de la disponibilité de l'E4X depuis la version 1.6 du Javascript. Surtout qu'en regardant Flash CS3 de plus prêt on se rend rapidement compte que le moteur JSFL est bien en version 1.6 !

Ainsi, pendant l'installation du serveur j'ai rapidement ouvert le PDF flashmediaserver_SSLR.pdf contenu dans le répertoire de documentation du serveur et tout de suite j'ai était "choqué" en lisant une documentation pratiquement similaire à la version que l'on peut trouver dans l'installation de FMS2 avec dès le début le joli paragraphe :

Server-Side ActionScript is Adobe’s name for JavaScript 1.5. Flash Media Interactive Server has an embedded Java-Script engine that compiles and executes server-side scripts. This Server-Side ActionScript Language Reference documents the Flash Media Interactive Server host environment classes and functions. You can also use core Java-Script classes, functions, statements, and operators. For more information, see the Core JavaScript 1.5 Reference at http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference. For more information about JavaScript, see “About JavaScript” in the Mozilla Developer Center at http://developer.mozilla.org/en/docs/About_JavaScript.

Bref... je veux bien que l'on ne passe pas tout de suite à une version Javascript 2 ou AS3/4 du SSAS mais là c'est vraiment n'importe quoi ! Il faut à mon avis très peu de temps pour changer le JS engine de FMS pour les développeurs d'Adobe et il ne faut pas oublier qu'à l'heure actuelle Mozilla est en train de diffuser les bases du Javascript 1.8... Politique commerciale ou tout simplement simple suffisance des développeurs d'Adobe. Pour ma part je me demande sérieusement si Adobe utilise sérieusement son serveur.

Je passerai rapidement sinon sur la couche "script" des composants FMS mis à jour dans le répertoire scriptlib de l'installation du serveur avec un code tout juste remis à jour au niveau de la licence en entête des fichiers .asc.

Au final, j'ai beau chercher et je ne vois que très peu de nouvelles méthodes dans la documentation du serveur et encore pire ! La nouvelle documentation ne donne aucune information sur la compatibilité des méthodes côté serveurs compatibles avec FMS2 ou FCS 1.5 Il faut maintenant que je me penche un peu plus sur la documentation du PLUG-IN DEVELOPER GUIDE mais pour le reste une simple relecture rapide suffira je pense.

Alors oui ! C'est génial que le prix de la licence baisse ! C'est génial que la qualité des vidéos et la sécurité soient meilleures ! C'est génial d'avoir une version plus stable et performante du serveur ( peut être car à chaque fois que Adobe nous dit que le serveur est stable je me retrouve avec des soucis avec mes clients ... ) ! Mais sérieusement il y a un manque réel de suvi sur les besoins des développeurs SSAS. On est limite dans un flou artistique depuis le début avec FMS qui favorise l'utilisation des composants de Adobe (vraiment médiocres pour le moment) et commercialement annonce bien la sortie prochaine des projets Cocomo et Pacifica.

AMF3 avec FMS3

J'en reviens maintenant au sujet de mon article, avec l'utilisation du protocol AMF3 avec FMS3

Bonne nouvelle malgré tout ce que j'ai pu dire plus haut, FMS3_ apporte la possibilité d'utiliser des données transférées entre le serveur et les clients Flash via le protocol AMF3. Il est donc possible maintenant de diffuser des ByteArray et des instances de type XML(E4X) directement via les méthode NetConnection.call() (AS3) et Client.call()__ (SSAS).

Voici donc un petit exemple d'utilisation de l'AMF3 avec Flash CS3 et FMS3 :