> And DOM model is designed for TREE of objects, but we cannot
> use it in non-visual tree, that because IT"S BAD DESIGNED.
---------------------------------------------------------------
WITH FLEX 2 YOU CAN SUPPORT THIS TODAY, YOU ARE NOT RESTRICTED.
---------------------------------------------------------------
I believe that adding this into the player or Flex by default would be a
mistake.
Here is my logic:
1. DOM Events exist to give context to user interaction on the DisplayList.
These events originate on the visual layer of the application where elements
are exposed to Mouse, Keyboard, DisplayObject events. Only objects that extend
DisplayObject can be added to the DisplayList, custom classes can listen
through a DisplayObject's events but they are not directly on the DisplayList.
2. Any object can listen for events at any node of the DisplayList tree. (I
posted an example of this) This allows custom classes to participate in events
from the DisplayList.
3. How events are processed within custom classes is the class's responsibility
(read: encapsulation). If your class needs events to walk its children, then
implement it.
Here is an example of event processing with custom classes using trees:
package {
import flash.util.trace;
import flash.events.*
public class FooClass extends EventDispatcher {
public var children:Array = [];
public function FooClass(){
this.addEventListener( 'resize' , processEvent )
}
public function processEvent( event:Event ){
for( var i:uint=0 ; i < children.length ; i++ ){
children[i].dispatchEvent( event );
}
}
public function addChild( child:Object ){
children.push( child );
}
}
}
// AS code within AS3/Flex application:
// Build a tree of custom classes
// create a root object
rootFoo = new FooClass();
// add child objects
rootFoo.addChild( new FooClass() )
rootFoo.addChild( new FooClass() )
rootFoo.addChild( new FooClass() )
// add more child objects
rootFoo.children[0].addChild( new FooClass() )
rootFoo.children[0].addChild( new FooClass() )
rootFoo.children[0].addChild( new FooClass() )
// add more more child objects
rootFoo.children[0].children[1].addChild( new FooClass() )
rootFoo.children[0].children[1].addChild( new FooClass() )
rootFoo.children[0].children[1].addChild( new FooClass() )
// dispatch an event to walk children
rootFoo.dispatchEvent( new Event('resize') );
In this case, at each level I am using an Array to hold children events would
be processed like so:
rootFoo.children[0].children[0]
rootFoo.children[0].children[1].children[0]
rootFoo.children[0].children[1].children[1]
rootFoo.children[0].children[1].children[2]
rootFoo.children[0].children[1]
rootFoo.children[0].children[2]
rootFoo.children[0]
rootFoo.children[1]
rootFoo.children[2]
rootFoo
In adding listeners in the constructor, this forces child objects to have event
precedence in the tree. At each level the events will process to the deepest
child and then handle events upward based on the order events were added into
each node.
If you wanted to see different pattern of event processing, simply change the
eventProcessor method or how listeners are added to fit your needs.
It really is wide open.
Hope this helps!
Cheers,
Cynergy Systems, Inc.
Theodore Patrick
Sr. Consultant
[EMAIL PROTECTED]
tel: 1.866.CYNERGY
http://www.cynergysystems.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.1/307 - Release Date: 4/10/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/
