Documentación de Flash CS3 
Documentación de Flash CS3 |
|||
| Programación con ActionScript 3.0 > Gestión de eventos > Diferencias entre la gestión de eventos en ActionScript 3.0 y en las versiones anteriores | |||
|
|||
|
|||
|
|||
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.
Las versiones de ActionScript anteriores a la 3.0 ofrecen diversas formas de gestionar los eventos:
on() que se pueden colocar directamente en instancias de Button y MovieClip.onClipEvent() que se pueden colocar directamente en instancias de MovieClip.XML.onload y Camera.onActivity.addListener().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 sólo permiten una función callback por evento. La implementación de los detectores de eventos es más compleja, ya que no sólo 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 basa en un subconjunto de la especificación de eventos DOM. A los programadores familiarizados con la gestión de eventos de componentes, la transición al nuevo modelo de eventos de ActionScript 3.0 les 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.
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 del modelo de eventos DOM incluye un concepto denominado comportamientos predeterminados. Un comportamiento predeterminado es una acción que Flash Player ejecuta como consecuencia normal de determinados eventos.
Normalmente, los desarrolladores son los responsables de escribir el código que responderá a los eventos. No obstante, en algunos casos un comportamiento está asociado con tal frecuencia a un evento que Flash Player automáticamente ejecuta ese comportamiento a menos que el desarrollador incluya código para cancelarlo. Dado que Flash Player emplea comportamientos de este tipo de forma automática, 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. 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 crea una instancia de la clase TextEvent para representar esa entrada de usuario. Si no se desea que Flash Player muestre el texto en el objeto TextField, hay que acceder a esa instancia específica de TextEvent y llamar al método preventDefault() de la instancia.
No todos los comportamientos predeterminados se pueden impedir. Por ejemplo, Flash Player genera 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.
Existen muchos tipos de objetos de eventos que no tienen ningún comportamiento predeterminado asociado. 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. En la documentación de la API referente a la clase Event y sus subclases se enumeran todos los tipos de eventos, y se describen los comportamientos predeterminados asociados, además de indicar si dicho comportamiento se puede impedir.
Es importante entender que los comportamientos predeterminados sólo están asociados con objetos de eventos distribuidos por Flash Player 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. Dicho de otro modo, Flash Player no mostrará un carácter en un objeto TextField a consecuencia de un evento textInput que se haya distribuido mediante programación.
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:
addListener() en algunos casos y addEventListener() en otros, mientras que en ActionScript 3.0 siempre se utiliza addEventListener().addListener() sólo 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. Flash CS3
Enviarme un mensaje de correo electrónico cuando se añadan comentarios a esta página | Informe de comentarios
Página actual: http://livedocs.adobe.com/flash/9.0_es/main/00000136.html