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

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.

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.