La differenza più sostanziale tra la modalità di gestione degli eventi di ActionScript 3.0 e la modalità delle versioni precedenti dell'applicazione è rappresentata dal fatto che ActionScript 3.0 contiene un solo sistema di gestione degli eventi unificato, mentre le versioni precedenti di ActionScript comprendono modalità diverse. La presente sezione descrive a grandi linee come avviene la gestione degli eventi nelle versioni precedenti di ActionScript e quindi passa a descrivere la nuova modalità implementata in ActionScript 3.0.
Gestione degli eventi nelle versioni precedenti di ActionScript
Le versioni di ActionScript anteriori alla 3.0 mettono a disposizione dei programmatori varie modalità di gestione degli eventi:
-
gestori di eventi
on()
che vengono inseriti direttamente sulle istanze di Button e MovieClip;
-
gestori di eventi
onClipEvent()
che vengono inseriti direttamente sulle istanze di MovieClip;
-
proprietà della funzione Callback, come
XML.onload
e
Camera.onActivity
;
-
listener di eventi da registrare tramite il metodo
addListener()
;
-
la classe UIEventDispatcher che implementa parzialmente il modello eventi DOM.
Ognuno di questi meccanismi presenta dei vantaggi e dei limiti. I gestori di eventi
on()
e
onClipEvent()
, ad esempio, sono facili da usare, ma rendono complicata la gestione dei progetti completati perché il codice inserito direttamente sui pulsanti e clip filmati diventa difficile da reperire. Anche le funzioni callback sono di facile implementazione, ma ogni evento ne supporta solo una. I listener di eventi, d'altro canto, sono difficili da implementare perché non solo richiedono la creazione dell'oggetto listener e della relativa funzione, ma anche la registrazione del listener per l'oggetto che genera l'evento. A questo maggiore carico di lavoro corrisponde, però, la possibilità di creare vari oggetti listener e registrarli tutti per lo stesso evento.
Lo sviluppo di componenti per ActionScript 2.0 ha generato un ulteriore modello di eventi. Il nuovo modello, incorporato nella classe UIEventDispatcher, si ispira alla specifica di eventi DOM. Gli sviluppatori che hanno dimestichezza con la gestione degli eventi dei componenti troveranno il passaggio al nuovo modello ideato per ActionScript 3.0 relativamente indolore.
Sfortunatamente, la sintassi usata dai vari modelli di eventi è sovrapponibile per vari aspetti ma differisce in alcuni punti. In ActionScript 2.0, ad esempio, alcune proprietà, come
TextField.onChanged
, possono essere usate come funzione callback o listener di eventi. Tuttavia, la sintassi per registrare gli oggetti listener differisce a seconda che si usi una delle sei classi che supportano i listener o la classe UIEventDispatcher. Per le classi Key, Mouse, MovieClipLoader, Selection, Stage e TextField usare il metodo
addListener()
, ma per la gestione degli eventi dei componenti è necessario usare il metodo
addEventListener()
.
Un'ulteriore difficoltà introdotta dai vari modelli di gestione degli eventi è che l'area di validità della funzione di gestione differiva notevolmente a seconda del meccanismo utilizzato. In altre parole, il significato della parola chiave
this
non è costante nei vari sistemi di gestione degli eventi.
Gestione degli eventi in ActionScript 3.0
Con ActionScript 3.0 viene introdotto un unico modello di gestione degli eventi che sostituisce i vari meccanismi disponibili nelle versioni precedenti dell'applicazione. Il nuovo modello di gestione si basa sulla specifica DOM (Document Object Model) Level 3. Nonostante il formato dei file SWF non aderisca espressamente allo standard DOM, il livello di somiglianza tra l'elenco di visualizzazione e la struttura DOM è sufficiente per rendere possibile l'implementazione del modello DOM. Gli oggetti dell'elenco di visualizzazione sono analoghi ai nodi DOM nella struttura gerarchica e i termini
oggetto dell'elenco di visualizzazione
e
nodo
in questo documento sono interscambiabili.
L'implementazione in Flash Player e AIR del modello eventi DOM introduce un nuovo concetto: i comportamenti predefiniti. Un
comportamento predefinito
è un'azione che Flash Player o AIR eseguono come normale conseguenza di determinati eventi.
Comportamenti predefiniti
Generalmente è compito degli sviluppatori scrivere il codice che attiva la risposta agli eventi. In alcuni casi, tuttavia, un comportamento è così “naturalmente” associato a un evento che Flash Player o AIR attivano automaticamente il comportamento, a meno che lo sviluppatore non modifichi il codice in modo da annullarlo. In quanto attivati automaticamente da Flash Player o AIR, questi comportamenti sono detti predefiniti.
Quando, ad esempio, un utente inserisce un testo in un oggetto TextField, l'aspettativa che il testo venga visualizzato in quel particolare oggetto TextField è così alta che è sembrato appropriato impostare questo comportamento come predefinito in Flash Player ed AIR. Se desiderate disattivare un comportamento predefinito, è sufficiente annullarlo utilizzando il nuovo sistema di gestione degli eventi. Quando un utente inserisce un testo in un oggetto TextField, Flash Player o AIR creano un'istanza della classe TextEvent che rappresenta l'input dell'utente. Per impedire che Flash Player o AIR visualizzino il testo nel campo TextField, è necessario accedere a quella precisa istanza di TextEvent e chiamare il metodo
preventDefault()
dell'istanza.
Non tutti i comportamenti predefiniti possono essere disattivati. Quando, ad esempio, un utente fa doppio clic su una parola di un oggetto TextField, Flash Player e AIR generano un oggetto MouseEvent. Il comportamento predefinito che viene attivato, e che non può in alcun modo essere disattivato, prevede che la parola sotto il cursore sia evidenziata.
A molti tipi di oggetto evento non sono stati associati dei comportamenti predefiniti. Flash Player invia, ad esempio, un oggetto evento connect quando viene attivata una connessione di rete, ma a questo oggetto non è associato alcun comportamento predefinito. La documentazione API per la classe Event e le sue sottoclassi elenca tutti i tipi di eventi, descrive il comportamento predefinito associato a ognuno e indica se il comportamento può essere disattivato.
È importante capire che i comportamenti predefiniti sono associati solo a oggetti evento inviati da Flash Player o AIR mentre non esistono per oggetti evento inviati dal codice tramite ActionScript. È consentito, ad esempio, usare i metodi della classe EventDispatcher per inviare un oggetto evento del tipo
textInput
, ma a tale oggetto non viene associato un comportamento predefinito. In altre parole, Flash Player e AIR non visualizzano un carattere in un oggetto TextField come risultato di un evento
textInput
inviato a livello di codice.
Novità per i listener di eventi in ActionScript 3.0
Gli sviluppatori che hanno dimestichezza con l'impiego del metodo
addListener()
di ActionScript 2.0 possono trovare utili le informazioni seguenti, che sottolineano le differenze tra il modello listener di eventi di ActionScript 2.0 e il modello eventi di ActionScript 3.0. Ecco le principali differenze che esistono tra i due approcci:
-
Per aggiungere listener di eventi in ActionScript 2.0, è possibile utilizzare talvolta
addListener()
e in altri casi
addEventListener()
, mentre in ActionScript 3.0 si usa
addEventListener()
in tutte le situazioni.
-
In ActionScript 2.0 non esiste il flusso di eventi, il che significa che il metodo
addListener()
può essere chiamato soltanto sull'oggetto che trasmette l'evento mentre in ActionScript 3.0, il metodo
addEventListener()
può essere chiamato su qualsiasi oggetto che fa parte del flusso di eventi.
-
In ActionScript 2.0, i listener di eventi possono essere funzioni, metodi oppure oggetti mentre in ActionScript 3.0 possono essere listener di eventi solo funzioni o metodi.
|
|
|