Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Flex ActionScript – Stratégies pour la communication entre Composants Flex

Tous les développeurs Flex, débutants et expérimentés, doivent faire face à un défi commun: permettre la communication entre composants Flex de la manière la plus puissante et la plus rapide. Pour permettre la communication entre composants, chaque composant doit connaître l'existence de l'autre composant, pour pouvoir échanger des données. En tant que développeurs, nous voulons suivre les principes de la POO (Programmation Orientée Objet) qui nous disent que chaque composant doit être le plus autonome possible. C'est là que les développeurs doivent cogiter: Comment deux composants Flex peuvent échanger de la data, sans connaître l'existence de l'autre?

Il y a de nombreuses manières d'aborder ce problème, mais pour cet article, on va voir 3 approches différentes pour Adobe Flex, voir leur fonctionnement, les problèmes qu'ils résolvent, et quelles sont leurs limitations.

Tout est une question d'évènement (Events)

Une des réponses possibles à ce problème de POO est d'utiliser le modèle évènementiel de Flash pour permettre à chaque composant de réagir aux évènements des autres. Ce modèle évènementiel permet aux composants de propager (dispatch) des objets de type évènement qui contiennent des informations sur l'information qui les a crée, comme par exemple, le click sur un bouton, ou une modification dans une ComboBox. Le modèle évènementiel permet aussi aux composants d'écouter un type d'évènement spécifique, pour que lorsqu'un changement se produit dans le composant source, l'évènement est propagé et l'écouteur (listener) est informé.

Le problème avec ce modèle est que l'écouteur doit savoir quel composant écouter, pour qu'il puisse recevoir l'évènement lorsqu'il est propagé. Par exemple, dans une application, on a un composant List et un composant DataGrid. Quand l'utilisateur modifie sa sélection dans la List, on veut mettre à jour la DataGrid. Pour cela, on doit écrire un peu de code dans le fichier MXML qui va contenir nos 2 composants. Quand la List propage un évènement de type CHANGE, le code met à jour le dataProvider de la DataGrid. Pour cela, notre code doit accéder à la référence de la List, et à celle de la DataGrid pour pouvoir utiliser la méthode addEventListener() pour écouter les changements:

<mx:Script>
    <![CDATA[
        import mx.events.ListEvent;

        [Bindable] public var dataOne:Array;
[Bindable] public var dataTwo:Array;

        public function handleChangeEvent(event:ListEvent):void {
            myDataGrid.dataProvider = dataTwo;
        }
    ]]>
</mx:Script>
<mx:List id="myList" change=handleChangeEvent(event)" />
<mx:DataGrid id="myDataGrid" dataProvider="{dataOne}" />

Quand la List et la DataGrid sont situées dans le même fichier MXML, comme dans cet exemple, cette fonctionnalité est simple à créer. On écrit seulement un peu de code pour écouter le changement de sélection dans la List et on met ensuite à jour la DataGrid. Cela devient plus difficile quand un des deux composants n'est pas dans le même MXML ou quand l'emplacement du composant est modifié.

Par exemple, disons que notre List est dans une barre d'outil de notre application qui est toujours affichée, mais la DataGrid n'est disponible que dans un onglet spécifique. Comment votre code va-t-il connaître l'emplacement de la DataGrid et de la List? Une pratique possible (mais mauvaise) est de mettre du code dans le fichier MXML de la DataGrid, et de référencer le composant List en remontant dans la hiérarchie par la propriété "parent", comme ceci:

parent.parent.parent.myList.addEventListener()

Une autre solution (toute aussi mauvaise mais "moins pire") est de référencer l'application et ensuite, de descendre dans la hiérarchie:

Application.application.sidebar.myList.addEventListener()

Ce genre de solution marche sur le court terme, mais crée un code fragile, facile à casser avec le plus petit des changements. Que se passera-t-il si vous devez bouger la List ou la DataGrid et que le chemin n'est plus le même? Dans ce cas, le compilateur va lancer une erreur car le chemin n'est plus valide. Au moins, vous sauriez quelle partie du code dysfonctionne, mais ce n'est pas une solution si vous voulez continuer à monter votre application. C'est à ce moment-la que la plupart des développeurs commencent à chercher différentes manières de résoudre ce problème.

Monter jusqu'au sommet

La principale faille de cette première approche est le manque de point d'entrée commun pour faire transiter toute les communications. On veut continuer à utiliser le modèle évènementiel, mais on a besoin d'identifier un point de contact qui va permettre à donner  à notre application de modifier la disposition de nos composants sans affecter les voies de communication. Dans ce cas-là, le meilleur endroit où chercher est le haut de la Display List (liste d'affichage) d'Adobe Flash Player.

La Display List est une représentation hiérarchique de ce qui est affiché dans Flash Player. Tout en haut de la liste d'affichage se trouve la scène (stage),  et tous les composants visuels sont les descendants. Peut importe où les composants sont situés dans votre application, la scène peut être accédée par la propriété "stage". Le stage est un très bon point de départ si vous travaillez avec Adobe Flash Professional, ou dans un projet ActionScript, mais dans Flex, vous n'avez pas besoin de voyager si loin dans la Display List pour cibler l'objet application. L'objet Application est un enfant du stage et le plus haut pour le développement Flex. Tous les composants seront descendants de l'application. L'application peut être accédée par n'importe quel composant en utilisant la syntaxe suivante:

Application.application

Dans l'exemple suivant, notre composant écoute sur l'application, l'évènement ListEvent et met à jour la donnée de la DataGrid quand l'évènement est propagé à travers l'application.

<mx:Script>
    <![CDATA[
        import mx.events.ListEvent;

[Bindable] public var dataOne:Array;
[Bindable] public var dataTwo:Array;

        public function subscribeToListChange():void {
            Application.application.addEventListener(ListEvent.CHANGE, handleListChange);
        }

        public function handleListChange(event:ListEvent):void {
            myDataGrid.dataProvider = dataTwo;
        }
    ]]>
</mx:Script>
<mx:DataGrid id="myDataGrid" dataProvider="{dataOne}" />

La différence entre cette approche est celle utilisant l'évènement ListEvent.CHANGE par défaut est que l'on doit être sur que la propriété "bubbles" de l'évènement propagé est bien à "true" ou notre objet application ne va jamais recevoir l'évènement. Le "Bubbling" est le processus qui permet aux évènements de se diffuser dans la Display List. Par défaut, les évènements Flex sont seulement envoyés directement aux composants inscrits à cet évènement. Mais si on fixe la propriété "bubbles" à true, l'évènement sera diffusé à toute le chaîne jusqu'à ce qu'il atteigne le haut du Stage. En utilisant le "Bubbling", on peut aller dans notre Application.application pour écouter les évènements, en sachant que quand notre List va propager notre évènement "bubbled", il sera passé à l'application.