Maxym,
My point was that in a runtime of 1.12Mb, we can't have everything we want in
the runtime. Flash/Flex bytecode is designed to extend the base player API
allowing for higher level features and functionality. Flex adds a framework
atop the AVM2 runtime allowing for creation of applications. Runtime size is
essential for wide distribution and adoption. I didn't mean it to seem childish
but this is the reality of writing apps on a widely distributed runtime.
Ok, so one issue with Events is that non-display objects seem to not support
bubbling and capture. Let's look at an example:
// Custom class listen for a DisplayObject event at a point in the DOM using
capture and bubble phases...
//Here is a custom class:
package {
import flash.util.trace;
import flash.events.*
public class FooClass {
public function FooClass(){}
public function doFoo( event:Event ){
flash.util.trace( "type:" + event.type + " phase:" +
event.eventPhase
+ " currentTarget:" + event.currentTarget );
}
}
}
//Create an instance:
myFoo = new FooClass();
//have myFoo listen on a VBox instance for 'fooEvent' on capture phase
vb0.addEventListener( 'fooEvent' , myFoo.doFoo , true );
//have myFoo listen on a VBox instance for 'fooEvent' on bubble phase
vb0.addEventListener( 'fooEvent' , myFoo.doFoo , false );
So custom classes can receive events via capture and bubble phases via the
DisplayList. The trick here is that I added 'myFoo.doFoo' as the method target.
AS3 supports method closure so the event was bound to the myFoo class instance
calling the doFoo method.
Your issue is more walking a tree of custom objects. :)
So how should we walk an object tree? Top to bottom? Left to Right? Big to
Small?
Should we walk all properties?
Should we only walk objects of a certain type?
How should we handle duplicate references?
How should we handle circular references?
How should we handle object identity?
Should we embed this logic into the player or make this customizable?
It makes sense for custom classes to define how their children are walked.
There are 1000 of ways to skin this problem. I think it was a good decision to
let developers define their own system for object to object event propagation.
Embedding logic here would have made a real big ugly nasty mess. That said when
extending classes, its handy to dispatch events to control subclass behavior.
In subclassing ArrayCollection, being able to dispatch my own events allowed me
to reuse all the logic in ArrayCollection without the pain or understanding its
model.
This issue also hits on the problem of handling circular references. If a
reference is added as a child of your custom object containing a reference to
the parent, if an event is fired, it could run endlessly and timeout the player
if event propagation was not well designed. With the DisplayList there are
strict rules about instances such that only 1 DisplayObject can exist in one
place on the DisplayList at one time. If you attempt to add a DisplayObject in
2 places on the DisplayList, the DisplayObject will reparent so that only 1
instance exists where the last addChild will be the location of your
DisplayObject. Imposing these type of instance rules on custom classes would
make a real big ugly mess.
I guess I have yet to see a case where DOM events are not "good enough" for
real world development. The new DOM event model is extensible, simple to use,
and easy to understand once you get the hand of it. You can have custom classes
listen for events through DisplayList objects and you can create custom event
handling for Object to Object events.
Again I will go on record as saying there isn't anything that I would change. :)
Cheers,
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: Monday, April 10, 2006 4:18 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code
Quality
I had no possibility to reply, cause it was weekend, sorry.
Your last post was child-like, but i'll try to take it seriously for a
moment, cause someone can read this and think that it makes sense.
1. When you will have a possibility to compile AS code into swf using AS,
when you will have AppDomains in AS, when you will have WMI (or smthn like
that) etc. etc. etc. etc. etc. , when you will have flex framework embeded
into flash player (22.4 M it's not only runtime) THAN YOU WILL COMPARE
WEIGHT OF FLASH PLAYER AND .NET FRAMEWORK. It's NOT about technologie it's
about event model. We don't need another .NET we have one allready.
2. We have allready untiped functors in flash. C# delegate it's only
strong-typed functor. If you think that embeding this kind of functors
into flash player takes a lot of weight you are wrong.
3. If you can't take things in general i'll show you small example why
current event model is bad designed.
Imagine that you have some tree of objects (non visual). you want to use
bubbling, capturing etc. in this tree( i can show you wide range of tasks
when it usefull in non visual objects). Now we have no possibility to do
that. But for such task some simple interface like
interface IChildDispatcher extends IEventDispatcher {
public function get parent() : IEventDispatcher;//or it can returns
IChildDispatcher if you like
}
is enough. Of course we can create such interface, then rewrite
EventDispatcher then use bubbling etc. but FOR WHAT??
What do you thin about this ex.?
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.0/306 - Release Date: 4/9/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/
