RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
> Yeah, Adobe is so terribly unresponsive. Its too bad that their > engineers don't actually take time to respond on random forums or > anything. Why won't they just put out a new version that directly > addresses the community's reaction to the 1.0 product? Hmm... Yeah, like those unofficial fixes from Allen Bauer at Borland for BDS. Some engineer at Adobe should do the same ;-) -- 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/
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Yeah, Adobe is so terribly unresponsive. Its too bad that their engineers don't actually take time to respond on random forums or anything. Why won't they just put out a new version that directly addresses the community's reaction to the 1.0 product? Hmm... Thank you, drive through. -rg From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mykola PaliyenkoSent: Friday, April 14, 2006 6:25 AMTo: flexcoders@yahoogroups.comSubject: Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Ok,as a result we have a FlexCompiler servlet that has a memory leaks and kills application server periodically. It is absolutely a stop-ship bug but Adobe has not released new version of Flex 1.5 yet. As a result there is no stable version of Flex. Yeah I'm realizing that Flex is pretty far from being open source, I just cannot imagine how people can sell such poor product for the great price. About breaking code. It is absolutely not acceptable having releases once per year or even more like Flex does. Maybe I'm just from another world but I think being not open to the community like Adobe do is a way to produce the poor quality. Flex has great idea but no good expertise from the community. All the critics about Cairngorn, FlexUnit is just ignored however it is obvious that Flex need to have a strong community involved in development of the components and the architecture Look at Java community, great success stories of Spring, Jboss, Apache and tones of the other really HQ products. We get addicted to the good quality of the design, Not the 200+ UI classes extended from the IEventDispatcher. WBR, Mykola On 4/13/06, Weyert de Boer <[EMAIL PROTECTED]> wrote: Mykola Paliyenko wrote:>> I don't think you should change working code only because it's> doesn't> have the perfect design, but that might just me. Of course, you> can do> something refactoring. You can only break ;-)>>> LOL,> With such approach Flex will remain the same crap as it is no Well, I am not rewriting working code within a current release cycle. Of course, you can branch off a version of the code you gonna clean up, for version X.Y.Z. But I am not someone who will update framework code of a current version/release only because the code quality sucks. You can change such issues step-by-step without breaking current functionality. I should change the design of one of my components, I can tell you my clients wouldn't appreciate it, neither that you probably like breaking code because a partner changed the design of the code. --Flexcoders Mailing ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txtSearch Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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 . -- WBR, Mykola -- 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.
Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Ok,as a result we have a FlexCompiler servlet that has a memory leaks and kills application server periodically. It is absolutely a stop-ship bug but Adobe has not released new version of Flex 1.5 yet. As a result there is no stable version of Flex. Yeah I'm realizing that Flex is pretty far from being open source, I just cannot imagine how people can sell such poor product for the great price. About breaking code. It is absolutely not acceptable having releases once per year or even more like Flex does. Maybe I'm just from another world but I think being not open to the community like Adobe do is a way to produce the poor quality. Flex has great idea but no good expertise from the community. All the critics about Cairngorn, FlexUnit is just ignored however it is obvious that Flex need to have a strong community involved in development of the components and the architecture Look at Java community, great success stories of Spring, Jboss, Apache and tones of the other really HQ products. We get addicted to the good quality of the design, Not the 200+ UI classes extended from the IEventDispatcher. WBR, MykolaOn 4/13/06, Weyert de Boer <[EMAIL PROTECTED]> wrote: Mykola Paliyenko wrote: > > I don't think you should change working code only because it's > doesn't > have the perfect design, but that might just me. Of course, you > can do > something refactoring. You can only break ;-) > > > LOL, > With such approach Flex will remain the same crap as it is no Well, I am not rewriting working code within a current release cycle. Of course, you can branch off a version of the code you gonna clean up, for version X.Y.Z. But I am not someone who will update framework code of a current version/release only because the code quality sucks. You can change such issues step-by-step without breaking current functionality. I should change the design of one of my components, I can tell you my clients wouldn't appreciate it, neither that you probably like breaking code because a partner changed the design of the code. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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 . -- WBR, Mykola -- 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.
Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Mykola Paliyenko wrote: > > I don't think you should change working code only because it's > doesn't > have the perfect design, but that might just me. Of course, you > can do > something refactoring. You can only break ;-) > > > LOL, > With such approach Flex will remain the same crap as it is no Well, I am not rewriting working code within a current release cycle. Of course, you can branch off a version of the code you gonna clean up, for version X.Y.Z. But I am not someone who will update framework code of a current version/release only because the code quality sucks. You can change such issues step-by-step without breaking current functionality. I should change the design of one of my components, I can tell you my clients wouldn't appreciate it, neither that you probably like breaking code because a partner changed the design of the code. -- 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/
Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
I don't think you should change working code only because it's doesn't have the perfect design, but that might just me. Of course, you can do something refactoring. You can only break ;-)LOL, With such approach Flex will remain the same crap as it is now -- 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 . -- WBR, Mykola -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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.
Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
I don't think you should change working code only because it's doesn't have the perfect design, but that might just me. Of course, you can do something refactoring. You can only break ;-) -- 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/
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Max, I think I have been professional here and other would agree. I have listened to you, tried to understand, and posted code to help. Please keep Flexcoders professional, it is not personal. :) Flash/Flex is simple for a reason. As a platform, it was designed to create light and fast distributed applications. I think it accomplishes this design better than any technology to date and it will continue to improve. "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove." - Antoine de Saint-Exupery Cheers, Ted :) ps. Since my "code is bad", I am going to crawl into a hole and drink some beers given this profound realization that my code sucks. :) From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of maxym.hryniv Sent: Tuesday, April 11, 2006 10:02 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Ted, You've not understood me one more time. I don't have a problem with creating my own code with my own logic (btw your code is bad). But as a developer you don't have to be targeted to some concrete case but you have to operate with abstractions. And if in bubbled dispatching you see events dispatching through a tree of visual object, I see few abstractions that we can separate from each other. And if now it's not separated it's not so extensible as it can be. And the question was NOT "how to create some ... bla-bla-bla with bla-bla- bla" BUT "Why we have different abstractions hardcoded in one class and why Adobe doesn't provide better solution, cause it can be better even leaving current interface??? And looking back to flex 1.5 framework code I'm not wondered, cause it's created using copy&paste." Hope you will understand me this time. Max --- In flexcoders@yahoogroups.com, "Ted Patrick" <[EMAIL PROTECTED]> wrote: > > > 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] > r
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Let me just point out no one from Flex Engineering is paying attention to this thread anymore. If you guys want to fight offlist that's fine with me. Matt -- 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/
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
> OUT OF CONTEXT At least he wasn't shouting... Or keeping scores. Let's face it Max, you're rude and have been throughout this thread. Go read up on list etiquette before trying to revolutionize the programming world. Stefan -- 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/
Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Maxym, you're the best (in so many ways).This is such groundbreaking insight, do keep it coming.e k z___Ikezi KamanuAdobe Consulting On 4/11/06, maxym.hryniv <[EMAIL PROTECTED]> wrote: Ted, You've not understood me one more time. I don't have a problem with creating my own code with my own logic (btw your code is bad). But as a developer you don't have to be targeted to some concrete case but you have to operate with abstractions. And if in bubbled dispatching you see events dispatching through a tree of visual object, I see few abstractions that we can separate from each other. And if now it's not separated it's not so extensible as it can be. And the question was NOT "how to create some … bla-bla-bla with bla-bla- bla" BUT "Why we have different abstractions hardcoded in one class and why Adobe doesn't provide better solution, cause it can be better even leaving current interface??? And looking back to flex 1.5 framework code I'm not wondered, cause it's created using copy&paste." Hope you will understand me this time. Max -- 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.
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
> 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/
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
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 techn
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.? On Fri, 07 Apr 2006 15:06:32 +0300, Ted Patrick <[EMAIL PROTECTED]> wrote: I have more than looked at C#, I have written several Flash/Flex backends in it. It comes down to this simple undisputable fact: .NET 2.0 Runtime == 22.4 MB (20 times larger than Flash) Java 1.5 Runtime == 16.0 MB (14 times larger than Flash) Flash Player 8.5 Runtime == 1.12 MB Flash and Flex have always targeted a small, lean, no frills runtime so that the player is easily deployed to end users. It is this file size that enables the player to be distributed to 700 Million end users cross platform and cross device. Given the size constraints the teams are focused on providing the smallest footprint for player code with the largest impact for developers. Maxym, there is nothing stopping you from writing your own event system in Flex similar to C#. - FLEX IS FREE – Flex Framework and Compilers are Free HYPERLINK "http://labs.macromedia.com/technologies/flexframework2/"http://labs.macromedia.com/technologies/flexframework2/ - You can code your own event model into a class and have it work closer to what C# offers. Actually when you are done, post your source so that we can give it a fair and honest review! Regards, Cynergy Systems, Inc. Theodore Patrick Sr. Consultant HYPERLINK "mailto:[EMAIL PROTECTED]"[EMAIL PROTECTED] tel: 1.866.CYNERGY HYPERLINK "http://www.cynergysystems.com/"http://www.cynergysystems.com _ From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Maxym Sent: Friday, April 07, 2006 3:08 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality 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. If it’s hard for you just take a look at C#. From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] 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:flexcoders@yahoogr
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
I have more than looked at C#, I have written several Flash/Flex backends in it. :) It comes down to this simple undisputable fact: .NET 2.0 Runtime == 22.4 MB (20 times larger than Flash) Java 1.5 Runtime == 16.0 MB (14 times larger than Flash) Flash Player 8.5 Runtime == 1.12 MB Flash and Flex have always targeted a small, lean, no frills runtime so that the player is easily deployed to end users. It is this file size that enables the player to be distributed to 700 Million end users cross platform and cross device. Given the size constraints the teams are focused on providing the smallest footprint for player code with the largest impact for developers. Maxym, there is nothing stopping you from writing your own event system in Flex similar to C#. - FLEX IS FREE – Flex Framework and Compilers are Free http://labs.macromedia.com/technologies/flexframework2/ - You can code your own event model into a class and have it work closer to what C# offers. Actually when you are done, post your source so that we can give it a fair and honest review! Regards, Cynergy Systems, Inc. Theodore Patrick Sr. Consultant [EMAIL PROTECTED] tel: 1.866.CYNERGY http://www.cynergysystems.com From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Maxym Sent: Friday, April 07, 2006 3:08 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality 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. If it’s hard for you just take a look at C#. From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] 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:flexcoders@yahoogroups.com] 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 SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice YAHOO! GROUPS LINKS Visit your group "flexcoders" on
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
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. If it’s hard for you just take a look at C#. 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 SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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.
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Here's a diagram of a typical DisplayObject hierarchy for a Flex 2 app. - Gordon SystemManager instance | | -- | | | | | | | | Application popped up ToolTip custom instance Alert instanceinstance cursor | | -- || || DataGrid HBox instance instance | | -- || || Button Button instance instance -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 3:31 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Gordon, That makes things crystal clear! "Base Class" is Ted speak, nothing in the docs on that. It would be very handy to see a hierarchy of how a Flex app is internally organized. The development model and mxml generation shields us from knowing what is occurring but it is handy to know these details. Even if it was ASCII art it would be meaningful: + Player 8.5 + SystemManager Instance >> Technically should be >> this.stage.root as this is the root of the DisplayList + ManagerInstances... + Application.application Instance >>> MXML Application Instance inserted here! _ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith Sent: Thursday, April 06, 2006 5:13 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Ah, I see that you're using the phrase "base class" to mean "the class that a SWF automatically instantiates as the root of the DisplayObject hierarchy". (Do our docs call this the base class? They shouldn't.) I thought you meant base class in the sense of some superclass like UIComponent or Container that a component inherits from. In the case of a Flex 2 app, this special class is the SystemManager. The Application instance is created as a child of the SystemManager instance. Other things like popups, cursors, and tooltips are also children of the SystemManager rather than children of the Application. However, most Flex developers should never need to think about the SystemManager. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 1:53 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Gordon, I had my ASC hat on and was thinking the MXML generated AS was similar... With ActionScript projects, the base class is the root of the DisplayList. package{ class MyApp{ public function MyApp(){ this.addChild( new Box() ) } } } In Flex 2 is mx.core.Application.application the root of the DisplayList? Ways to get to root in Flex2 app: //from anywhere mx.core.Application.application //from any component myComponent.parentApplication //from any DisplayObject this.stage.root this.root //sometimes... Cheers, Cynergy Systems, Inc. Theodore Patrick Sr. Consultant [EMAIL PROTECTED] tel: 1.866.CYNERGY HYPERLINK "http://www.cynergysystems.com"http://www.cynergysystems.com From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith Sent: Thursday, April 06, 2006 4:04 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Thanks, Ted. You've done a great job of explaining the benefits of the new event system! I just want to correct one thing, though. You said "Events that utilize the DOM walk from the root of the DisplayList (your base class) to their target...". This seems to confuse the distinction between the visual hierarchy of DisplayObjects and the inheritance hierarchy of component classes and their superclasses. The root of the DisplayList is an instance of our SystemManager class. This is where the capture phase of event dispatching starts, and where the bubbling phase ends. But SystemManager isn't the base class for any of our components. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Gordon, That makes things crystal clear! “Base Class” is Ted speak, nothing in the docs on that. It would be very handy to see a hierarchy of how a Flex app is internally organized. The development model and mxml generation shields us from knowing what is occurring but it is handy to know these details. Even if it was ASCII art it would be meaningful: + Player 8.5 + SystemManager Instance >> Technically should be >> this.stage.root as this is the root of the DisplayList + ManagerInstances… + Application.application Instance >>> MXML Application Instance inserted here! _ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith Sent: Thursday, April 06, 2006 5:13 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Ah, I see that you're using the phrase "base class" to mean "the class that a SWF automatically instantiates as the root of the DisplayObject hierarchy". (Do our docs call this the base class? They shouldn't.) I thought you meant base class in the sense of some superclass like UIComponent or Container that a component inherits from. In the case of a Flex 2 app, this special class is the SystemManager. The Application instance is created as a child of the SystemManager instance. Other things like popups, cursors, and tooltips are also children of the SystemManager rather than children of the Application. However, most Flex developers should never need to think about the SystemManager. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 1:53 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Gordon, I had my ASC hat on and was thinking the MXML generated AS was similar... With ActionScript projects, the base class is the root of the DisplayList. package{ class MyApp{ public function MyApp(){ this.addChild( new Box() ) } } } In Flex 2 is mx.core.Application.application the root of the DisplayList? Ways to get to root in Flex2 app: //from anywhere mx.core.Application.application //from any component myComponent.parentApplication //from any DisplayObject this.stage.root this.root //sometimes... Cheers, Cynergy Systems, Inc. Theodore Patrick Sr. Consultant [EMAIL PROTECTED] tel: 1.866.CYNERGY HYPERLINK "http://www.cynergysystems.com"http://www.cynergysystems.com From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith Sent: Thursday, April 06, 2006 4:04 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Thanks, Ted. You've done a great job of explaining the benefits of the new event system! I just want to correct one thing, though. You said "Events that utilize the DOM walk from the root of the DisplayList (your base class) to their target...". This seems to confuse the distinction between the visual hierarchy of DisplayObjects and the inheritance hierarchy of component classes and their superclasses. The root of the DisplayList is an instance of our SystemManager class. This is where the capture phase of event dispatching starts, and where the bubbling phase ends. But SystemManager isn't the base class for any of our components. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 10:34 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality 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 u
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Ah, I see that you're using the phrase "base class" to mean "the class that a SWF automatically instantiates as the root of the DisplayObject hierarchy". (Do our docs call this the base class? They shouldn't.) I thought you meant base class in the sense of some superclass like UIComponent or Container that a component inherits from. In the case of a Flex 2 app, this special class is the SystemManager. The Application instance is created as a child of the SystemManager instance. Other things like popups, cursors, and tooltips are also children of the SystemManager rather than children of the Application. However, most Flex developers should never need to think about the SystemManager. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 1:53 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Gordon, I had my ASC hat on and was thinking the MXML generated AS was similar... With ActionScript projects, the base class is the root of the DisplayList. package{ class MyApp{ public function MyApp(){ this.addChild( new Box() ) } } } In Flex 2 is mx.core.Application.application the root of the DisplayList? Ways to get to root in Flex2 app: //from anywhere mx.core.Application.application //from any component myComponent.parentApplication //from any DisplayObject this.stage.root this.root //sometimes... 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 Gordon Smith Sent: Thursday, April 06, 2006 4:04 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Thanks, Ted. You've done a great job of explaining the benefits of the new event system! I just want to correct one thing, though. You said "Events that utilize the DOM walk from the root of the DisplayList (your base class) to their target...". This seems to confuse the distinction between the visual hierarchy of DisplayObjects and the inheritance hierarchy of component classes and their superclasses. The root of the DisplayList is an instance of our SystemManager class. This is where the capture phase of event dispatching starts, and where the bubbling phase ends. But SystemManager isn't the base class for any of our components. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 10:34 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality 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 (bu
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Gordon, I had my ASC hat on and was thinking the MXML generated AS was similar... With ActionScript projects, the base class is the root of the DisplayList. package{ class MyApp{ public function MyApp(){ this.addChild( new Box() ) } } } In Flex 2 is mx.core.Application.application the root of the DisplayList? Ways to get to root in Flex2 app: //from anywhere mx.core.Application.application //from any component myComponent.parentApplication //from any DisplayObject this.stage.root this.root //sometimes... 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 Gordon Smith Sent: Thursday, April 06, 2006 4:04 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality Thanks, Ted. You've done a great job of explaining the benefits of the new event system! I just want to correct one thing, though. You said "Events that utilize the DOM walk from the root of the DisplayList (your base class) to their target...". This seems to confuse the distinction between the visual hierarchy of DisplayObjects and the inheritance hierarchy of component classes and their superclasses. The root of the DisplayList is an instance of our SystemManager class. This is where the capture phase of event dispatching starts, and where the bubbling phase ends. But SystemManager isn't the base class for any of our components. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 10:34 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality 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
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Thanks, Ted. You've done a great job of explaining the benefits of the new event system! I just want to correct one thing, though. You said "Events that utilize the DOM walk from the root of the DisplayList (your base class) to their target...". This seems to confuse the distinction between the visual hierarchy of DisplayObjects and the inheritance hierarchy of component classes and their superclasses. The root of the DisplayList is an instance of our SystemManager class. This is where the capture phase of event dispatching starts, and where the bubbling phase ends. But SystemManager isn't the base class for any of our components. - Gordon -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, April 06, 2006 10:34 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality 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 extr
Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
ased 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: flexcoders@yahoogroups.com] 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. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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. -- 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.
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
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] ht
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
Hi, Maxym. I'm sorry that you're unhappy with the design of the event system in Flex. However, we believe that it's usable, high-performance, and follows a standard. I'm sure there are ways it could be better, but we won't be changing it -- at least for this release! -- as the product is already at Beta 2. - Gordon From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Maxym Sent: Thursday, April 06, 2006 8: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:flexcoders@yahoogroups.com] 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 SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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.
RE: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
TREE STRUCTURE. So can you explain me why Timer extends EventDispatcher. Can you imagine TREE STRUCTURE of > Timers??? You lost me. Timer uses EventDispatcher so that it can dispatch timer events. There is no implication of any structure. There are certainly features of EventDispatcher that are not used by Timer, but there is no cost, and I'd much prefer inheritance over a mixin. Adding dispatcher capabilities via composition would be more costly for both memory and performance. If you see only 2 solutions: inheritance and mixin it’s your problem. There are better solutions. EventDispatcher has spare functionality and it’s bad design. >.1. It's based on string identifiers. Because of this > a. It's slow Do you have any evidence to back that up? Strings are convenient for a number of reasons. In particular for debugging. I sad that I can describe better solution if you will be open for discussion. > b. You don't know for real types of events that object can dispatch. I agree with that. In my own code, I keep constants on the class that does the dispatching, rather than event class. However, it isn't always so straightforward - for example where events can bubble, the events that an object can dispatch are based on what children are added at runtime. 1-0 > c. You can't use code-inside in editor for access events. I don't know what you mean here... I mean that you can’t press ctrl+space and see events (in outline, like properties and functions) . Sure you can use Flex “Metadata” keywords do describe events dispatched by class and editor will understand them but it’s not a solution it’s a kind of crutches cause in AS3 we don’t have real metadata. (like metadata in C# or annotations in Java) Max Peter On 4/6/06, Maxym <[EMAIL PROTECTED]> wrote: 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: flexcoders@yahoogroups.com] 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. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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.
Re: [flexcoders] Re: Question to Adobe about Flex Framework 1.5 Code Quality
> TREE STRUCTURE. So can you explain me why Timer extends EventDispatcher. Can you imagine TREE STRUCTURE of > Timers??? You lost me. Timer uses EventDispatcher so that it can dispatch timer events. There is no implication of any structure. There are certainly features of EventDispatcher that are not used by Timer, but there is no cost, and I'd much prefer inheritance over a mixin. Adding dispatcher capabilities via composition would be more costly for both memory and performance. >.1. It's based on string identifiers. Because of this > a. It's slow Do you have any evidence to back that up? Strings are convenient for a number of reasons. In particular for debugging. > b. You don't know for real types of events that object can dispatch. I agree with that. In my own code, I keep constants on the class that does the dispatching, rather than event class. However, it isn't always so straightforward - for example where events can bubble, the events that an object can dispatch are based on what children are added at runtime. > c. You can't use code-inside in editor for access events. I don't know what you mean here... Peter On 4/6/06, Maxym <[EMAIL PROTECTED]> wrote: 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: flexcoders@yahoogroups.com] 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. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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.
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.
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 <*> 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/