|
La diferencia principal entre la gestión de eventos en ActionScript 3.0 y en las versiones anteriores radica en que en ActionScript 3.0 hay un único sistema para gestionar eventos, mientras que en las versiones anteriores de ActionScript existían varios. Esta sección comienza con una descripción general de la forma en la que funcionaba la gestión de eventos en las versiones anteriores de ActionScript y pasa luego a examinar el modo en que ha cambiado en ActionScript 3.0.
Gestión de eventos en versiones anteriores de ActionScript
Las versiones de ActionScript anteriores a la 3.0 ofrecen diversas formas de gestionar los eventos:
-
Controladores de eventos
on()
que se pueden colocar directamente en instancias de Button y MovieClip.
-
Controladores
onClipEvent()
que se pueden colocar directamente en instancias de MovieClip.
-
Propiedades de funciones callback, como
XML.onload
y
Camera.onActivity
.
-
Detectores de eventos que pueden registrarse con el método
addListener()
.
-
La clase UIEventDispatcher que implementaba parcialmente el modelo de eventos DOM.
Cada uno de estos mecanismos presenta sus propias ventajas y limitaciones. Los controladores
on()
y
onClipEvent()
son fáciles de usar, pero dificultan el mantenimiento posterior de los proyectos, ya que el código colocado directamente en los botones y clips de películas puede ser difícil de encontrar. Las funciones callback también son sencillas de implementar, pero solo permiten una función callback por evento. La implementación de los detectores de eventos es más compleja, ya que no solo es necesario crear un objeto y una función de detector, sino también registrar el detector en el objeto que genera el evento. No obstante, este trabajo adicional permite crear varios objetos detectores y registrarlos todos para el mismo evento.
El desarrollo de componentes para ActionScript 2.0 dio lugar a un nuevo modelo de eventos. Este nuevo modelo, representado por la clase UIEventDispatcher, se basaba en un subconjunto de la especificación de eventos DOM, de modo que, para los desarrolladores que conozcan la gestión de eventos de componentes, la transición al nuevo modelo de eventos de ActionScript 3.0 resultará relativamente sencilla.
Por desgracia, la sintaxis utilizada en los distintos modelos de eventos es igual en algunos casos y diferente en otros. Por ejemplo, en ActionScript 2.0, algunas propiedades, como
TextField.onChanged
, se pueden usar como función callback o como detector de eventos. Sin embargo, la sintaxis para registrar objetos detectores varía dependiendo de si se utiliza una de las seis clases que admiten detectores en la clase UIEventDispatcher. Para las clases Key, Mouse, MovieClipLoader, Selection, Stage y TextField se debe usar el método
addListener()
, mientras que para la gestión de eventos de componentes es necesario utilizar un método llamado
addEventListener()
.
Otra complicación introducida por los distintos modelos de gestión de eventos es que el ámbito de la función de controlador de eventos varía ampliamente dependiendo del mecanismo usado. Dicho de otro modo, el significado de la palabra clave
this
varía entre los distintos sistemas de gestión de eventos.
Gestión de eventos en ActionScript 3.0
ActionScript 3.0 presenta un único modelo de gestión de eventos que sustituye a todos los mecanismos que existían en las versiones anteriores del lenguaje. El nuevo modelo de eventos se basa en la especificación de eventos DOM (modelo de objetos de documento) de nivel 3. Si bien el formato de archivo SWF no cumple específicamente con el estándar DOM, existen suficientes similitudes entre la lista de visualización y la estructura de DOM como para posibilitar la implementación del modelo de eventos DOM. Los objetos de la lista de visualización son análogos a los nodos de la estructura jerárquica de DOM y los términos
objeto de la lista de visualización
y
nodo
se usan de forma indistinta en este texto.
La implementación de Flash Player y AIR del modelo de eventos DOM incluye un concepto denominado comportamientos predeterminados. Un
comportamiento predeterminado
es una acción que Flash Player o AIR ejecutan como consecuencia normal de determinados eventos.
Comportamientos predeterminados
Los desarrolladores suelen ser los responsables de escribir código que responda a eventos. No obstante, en algunos casos un comportamiento está asociado con tal frecuencia a un evento, que Flash Player o AIR ejecutan automáticamente ese comportamiento a no ser que el desarrollador incluya código para cancelarlo. Flash Player o AIR muestran comportamientos de este tipo de forma automática, por lo que reciben el nombre de comportamientos predeterminados.
Por ejemplo, cuando un usuario escribe texto en un objeto TextField, resulta tan frecuente esperar que el texto se muestre en el objeto TextField que ese comportamiento se incorpora en Flash Player y AIR. Si no se desea que se produzca este comportamiento predeterminado, es posible cancelarlo usando el nuevo sistema de gestión de eventos. Cuando se escribe texto en un objeto TextField, Flash Player o AIR crean una instancia de la clase TextEvent para representar esa entrada de usuario. Si no se desea que Flash Player o AIR muestren el texto en el objeto TextField, es necesario acceder a esa instancia específica de TextEvent y llamar al método
preventDefault()
de la instancia.
Hay algunos comportamientos predeterminados que no se pueden impedir. Por ejemplo, Flash Player y AIR generan un objeto MouseEvent cuando el usuario hace doble clic en una palabra de un objeto TextField. El comportamiento predeterminado, que no se puede impedir, es resaltar la palabra que hay bajo el cursor.
Hay varios tipos de objetos de evento que no tienen asociado ningún comportamiento predeterminado. Por ejemplo, Flash Player distribuye un objeto de evento connect cuando se establece una conexión de red, pero no hay ningún comportamiento predeterminado asociado a él. La documentación de la API para la clase Event y sus subclases relaciona cada tipo de evento y describe el comportamiento predeterminado que tiene asociado, e indica si es posible impedir dicho comportamiento.
Es importante comprender que los comportamientos predeterminados solo están asociados con objetos de eventos distribuidos por Flash Player o AIR y que no existen para objetos de eventos distribuidos mediante programación a través de ActionScript. Por ejemplo, se pueden usar los métodos de la clase EventDispatcher para distribuir un objeto de evento de tipo
textInput
, pero ese objeto de evento no tendrá ningún comportamiento predeterminado asociado. Es decir, Flash Player y AIR no mostrarán un carácter en un objeto TextField como resultado de un evento
textInput
que se haya distribuido mediante programación.
Novedades de los detectores de eventos de ActionScript 3.0
Para los desarrolladores con experiencia en el uso del método
addListener()
de ActionScript 2.0, puede resultar útil señalar las diferencias entre el modelo de detectores de eventos de ActionScript 2.0 y el de ActionScript 3.0. En la siguiente lista se muestran algunas de las diferencias principales entre los dos modelos de eventos:
-
Para añadir detectores de eventos en ActionScript 2.0, es necesario usar
addListener()
en algunos casos y
addEventListener()
en otros, mientras que en ActionScript 3.0 siempre se utiliza
addEventListener()
.
-
En ActionScript 2.0 no existe el flujo del evento, lo que quiere decir que el método
addListener()
solo se puede llamar en el objeto que difunde el evento, mientras que en ActionScript 3.0, el método
addEventListener()
se puede llamar en cualquier objeto que forme parte del flujo del evento.
-
En ActionScript 2.0, los detectores de eventos pueden ser funciones, métodos u objetos, mientras que en ActionScript 3.0 solo las funciones o los métodos pueden ser detectores de eventos.
|
|
|
