Variation de la gestion d’événements dans ActionScript 3.0 par rapport aux versions antérieures

Flash Player 9 et les versions ultérieures, Adobe AIR 1.0 et les versions ultérieures

En ce qui concerne la gestion des événements, la différence la plus évidente entre ActionScript 3.0 et les versions antérieures est qu’ActionScript 3.0 comprend un seul système de gestion des événements alors que les anciennes versions d’ActionScript en comptent plusieurs. Cette section commence par une présentation générale du fonctionnement de la gestion des événements dans les versions précédentes, puis étudie les nouveautés qu’apporte ActionScript 3.0 dans ce domaine.

Gestion des événements dans les versions précédentes d’ActionScript

Antérieurement à ActionScript 3.0, le langage ActionScript fournissait plusieurs méthodes de gestion des événements :

  • Les gestionnaires d’événement on(), qui peuvent se placer directement sur des occurrences Button et MovieClip

  • Les gestionnaires d’événement onClipEvent(), qui peuvent se placer directement sur des occurrences MovieClip

  • Des propriétés de fonction de rappel, telles que XML.onload et Camera.onActivity

  • Des écouteurs d’événement, que vous pouvez enregistrer à l’aide de la méthode addListener()

  • La classe UIEventDispatcher, qui implémentait partiellement le modèle d’événements DOM

Chacun de ces mécanismes présente des avantages et des inconvénients. Les gestionnaires on() et onClipEvent() sont simples d’utilisation, mais compliquent la maintenance des projets car il peut s’avérer difficile de localiser le code placé directement sur les boutons ou les clips. Les fonctions de rappel sont également faciles à implémenter, mais imposent une limite d’une seule fonction de rappel par événement. L’implémentation des écouteurs d’événement est plus complexe : ils nécessitent non seulement la création d’un objet et d’une fonction d’écouteur, mais aussi l’enregistrement de l’écouteur auprès de l’objet qui génère l’événement. Bien qu’elle accroisse le temps système nécessaire, cette solution vous permet de créer plusieurs objets écouteur et de tous les enregistrer pour le même événement.

Dans ActionScript 2.0, le développement des composants engendrait un modèle d’événements encore différent. Ce nouveau modèle, caractérisé par la classe UIEventDispatcher, reposait sur un sous-ensemble de la spécification d’événements DOM. Ainsi, pour les développeurs accoutumés à la gestion des événements de composant, le passage au nouveau modèle d’événements d’ActionScript 3.0 se fera sans trop de difficultés.

Malheureusement, si l’on constate des recoupements entre les divers modèles d’événements, il existe aussi des différences. Par exemple, dans ActionScript 2.0, certaines propriétés, telles que TextField.onChanged, peuvent s’utiliser soit comme fonction de rappel, soit comme écouteur d’événement. Toutefois, la syntaxe qui permet d’enregistrer les objets écouteurs varie selon que vous utilisez l’une des six classes qui prennent en charge les écouteurs ou la classe UIEventDispatcher. Pour les classes Key, Mouse, MovieClipLoader, Selection, Stage et TextField, vous utilisez la méthode addListener(), mais pour la gestion des événements de composant, vous utilisez une méthode appelée addEventListener().

La multiplicité des modèles de gestion d’événements a fait naître une autre complexité : l’étendue de la fonction de gestionnaire d’événement variait largement en fonction du mécanisme utilisé. En d’autres termes, la signification du mot-clé this n’était pas cohérente sur l’ensemble des systèmes de gestion d’événements.

Gestion d’événements dans ActionScript 3.0

ActionScript 3.0 utilise pour la première fois un modèle de gestion d’événements qui vient remplacer les nombreux mécanismes qui existaient dans les précédentes versions du langage. Le nouveau modèle d’événements repose sur la spécification d’événements de niveau 3 DOM (Document Object Model). Bien que le format de fichier SWF ne suive pas spécifiquement la norme DOM, il existe suffisamment de similitudes entre la liste d’affichage et la structure du DOM pour permettre l’implémentation de ce modèle d’événements. Un objet de la liste d’affichage est semblable à un noeud de la structure hiérarchique du DOM ; dans ce chapitre, les termes objet de liste d’affichage et noeud sont d’ailleurs utilisés de façon interchangeable.

L’implémentation du modèle d’événements DOM dans Flash Player et AIR comprend un concept appelé « comportements par défaut ». Un comportement par défaut est une action que Flash Player ou AIR effectue comme conséquence normale de certains événements.

Comportements par défaut

Les développeurs se chargent normalement d’écrire le code qui permet de répondre aux événements. Dans certains cas, cependant, un comportement est si couramment associé à un événement que Flash Player ou AIR l’exécute automatiquement, sauf si le développeur ajoute du code pour annuler son exécution. Comme Flash Player ou AIR se livre automatiquement à cette opération, on parle de comportements par défaut.

Par exemple, lorsqu’un utilisateur entre du texte dans un objet TextField, il est si courant de voir s’afficher la saisie dans l’objet TextField en question que ce comportement est prédéfini dans Flash Player ou AIR. Si vous ne souhaitez pas conserver ce comportement par défaut, vous pouvez l’annuler à l’aide du système de gestion des événements. Lorsqu’un utilisateur entre du texte dans un objet TextField, Flash Player ou AIR crée une occurrence de la classe TextEvent afin de représenter cette saisie. Pour éviter que Flash Player ou AIR n’affiche le texte dans l’objet TextField, vous devez accéder à cette occurrence de TextEvent spécifique et appeler sa méthode preventDefault().

Certains comportements par défaut ne peuvent pas être évités. Par exemple, Flash Player et AIR génèrent un objet MouseEvent lorsque l’utilisateur double-clique sur un mot dans un objet TextField. Le comportement par défaut, qui ne peut être évité, consiste à mettre en évidence le mot situé sous le curseur.

De nombreux types d’objets événement ne sont associés à aucun comportement par défaut. Par exemple, l’objet événement Connect, que Flash Player distribue lorsqu’une connexion réseau est établie, n’est associé à aucun comportement par défaut. La documentation de l’API relative à la classe Event et ses sous-classes fait l’inventaire de chaque type d’événement, décrit le comportement par défaut qui lui est éventuellement associé et indique si ce dernier peut être évité.

Il est important de comprendre que les comportements par défaut sont uniquement associés à des objets événements distribués par Flash Player ou AIR ; il n’en existe aucun pour les objets événements distribués via ActionScript par programmation. Par exemple, vous pouvez utiliser les méthodes de la classe EventDispatcher pour distribuer un objet événement du type textInput, mais cet objet ne sera associé à aucun comportement par défaut. En d’autres termes, Flash Player et AIR n’affichent aucun caractère dans un objet TextField en réponse à un événement textInput que vous avez distribué par programmation.

Nouveautés des écouteurs d’événement dans ActionScript 3.0

Pour les développeurs qui connaissent bien la méthode ActionScript 2.0 addListener(), il peut être utile de souligner les différences entre le modèle d’écouteur d’événement d’ActionScript 2.0 et le modèle d’événements d’ActionScript 3.0. La liste ci-après décrit les principales différences entre ces deux modèles d’événements :

  • Pour ajouter des écouteurs d’événement dans ActionScript 2.0, vous utilisez, selon le cas, addListener() ou addEventListener(). Dans ActionScript 3.0, il faut utiliser addEventListener() dans tous les cas.

  • ActionScript 2.0 ne propose aucun flux d’événements dans ActionScript 2.0, ce qui signifie que la méthode addListener() peut uniquement être appelée sur l’objet qui émet l’événement. Dans ActionScript 3.0, la méthode addEventListener() peut être appelée sur tout objet faisant partie du flux d’événements.

  • Dans ActionScript 2.0, les écouteurs d’événement peuvent être des fonctions, des méthodes ou des objets, alors que dans ActionScript 3.0, seules les fonctions et les méthodes peuvent agir comme écouteurs d’événement.