The event system in Flash Player 8.5 is designed to handle 2 concepts: 1. Broadcasting events from Classes.
2. Broadcasting events through the DisplayList Tree. The design choice was made to build this event based logic into the player for performance reasons. As events run within the player they are 100 times faster than the interpreted events in Flex 1.5 and are in context with the DisplayList. Events that utilize the DOM walk from the root of the DisplayList (your base class) to their target and then bubble back to the root (assuming event bubbling == true for the event). Think of the event model as a 2 lane road to the target, you can listen for events arriving on one lane, listen at the target, or listen on the return trip to the root. At any point the events or optionally cancelable. Use of strings is pretty bogus complaint. With a strongly typed JIT compilation, string comparison is lightning fast. Obviously uint might be faster but then all dependency code would need to use CONSTANTS and this would impose CONSTANT use on all developers. As is, using CONSTANTS is a best practice and not required. This is also very useful for code being ported over from Flex 1.5. As strings are supported, it makes for a very flexible model for extension too (more on that in a sec...or see attached). Actually it is hard to imagine that events could get much better than the current design. It is extensible, customizable, fast, easy to work with, and essentially lean and mean. There is an especially handy concept that everyone should learn, see attached. You can make any class dispatch a customized event easily! If you want your application dispatch a fooEvent through a VBox you can make that happen easily: import flash.events.* myVbox.dispatchEvent ( new Event( 'fooEvent' , true, true ) ); // another reason string are handy, no fooEvent constant exists, // yet I can make one. Any listener subscribed from root to myVbox and back (bubbles) can listen for a 'fooEvent'. In the attached example, the fooEvent is captured up and down the DisplayList tree. That is an incredibly powerful concept and allows for deep customization and extension of any class/component simply through this base event plumbing in the Flash Player 8.5. For example I extended an ArrayCollection recently. Using the base Events in that class, I was able to dispatch custom events to any view component using the custom collection as a dataProvider simply through the event API. Basically I added a bunch of data to a custom collection and dispatched one event to update a linked DataGrid or any list based control. Looking back, this was far simpler because everything uses common event plumbing in the player. Actually my extended class did little add a method for "addItems( data:Array )" and broadcast an event to update the view. Personally, DOM events might be one of the more hidden jewels in the Flex 2/Flash Player 8.5 release. My 2 Cents, Cynergy Systems, Inc. Theodore Patrick Sr. Consultant [EMAIL PROTECTED] tel: 1.866.CYNERGY http://www.cynergysystems.com ________________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Maxym Sent: Thursday, April 06, 2006 11:42 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Yeah, I can. DOM Specification: The first goal is the design of an event system which allows registration of event listeners and describes event flow through a tree structure. TREE STRUCTURE. So can you explain me why Timer extends EventDispatcher. Can you imagine TREE STRUCTURE of Timers??? For real there are many bad things in this event model: 1. It's based on string identifiers. Because of this a. It's slow b. You don't know for real types of events that object can dispatch. c. You can't use code-inside in editor for access events. 2. EventDispatcher and IEventDispatcher have too much extra functionality that will be used only for visual objects. 3. If you want to dispatch events and you can't extend EventDispatcher you have to duplicate (do you know some AOP concepts) it's logic (at least one time) and implement IEventDispatcher. 4. I can say more but I'm tired of typing... ________________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Darron J. Schall Sent: Thursday, April 06, 2006 5:46 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality maxym.hryniv wrote: > Looking at Flex 2 framework event model, and Flex 2 Framework UML > (Flex 2 api visual reference by Rocket Boots) I don't believe that > Flex 2 is better. Can you be more specific? The event model is fundamentally part of the player is an based on the DOM Level 3 Events specification [1]. -d [1] http://www.w3.org/TR/DOM-Level-3-Events/ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com ________________________________________ YAHOO! GROUPS LINKS * Visit your group "flexcoders" on the web. * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ________________________________________ -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
FooEvent.mxml
Description: FooEvent.mxml
